Re: buildd stuff
Wouter Verhelst a écrit :
> On Thu, Jan 25, 2007 at 01:23:35AM +0000, James Troup wrote:
>> unilaterally make the decision that they are or are not OK. If it's
>> the consensus of the release managers and the architecture porting
>> team that they want to use emulated buildds and/or cross compiling, I
>> absolutely will not stop them from doing so.
> There's something slightly related here which, I think, needs
> discussion, too:
> Is it really optimal to have one buildd admin per architecture, and
> several architectures per buildd admin?
Well we've seen packages on some architectures not uploaded for a few
days and up to a week. Persons have the right to take holidays, but that
is currently a single point of failure, and we should have solutions to
fix that. Having one more than one buildd admin per architecture seems
to be a good solution.
After all, the release criteria impose to have at least two build
daemons to reduce the single point of failure (and we've seen those days
that it is a good criterion), but do not impose anything of the number
of buildd admins.
> I know your opinion on this matter is different from mine; but it has
> been nagging on me for a while, and I must get it off me. Note, though,
> that this is not meant as an attack; I want a sensible discussion about
> the topic, since I believe it's important.
> I do not believe it to be optimal that people who maintain buildd boxen
> for a given architecture are not in touch with the people who claim
> themselves to be the porters for the same architecture. I know for a
> fact that you're either not subscribed to the debian-arm mailinglist
> (since I am, and have never seen any post from you there); and If people
> like Wookey, who I consider to be one of the prime arm porters, say
> things like
> The buildd people do usually reschedule things when asked, I believe,
> but there is (almost) never any direct feedback so it's hard to know
> if people who ask questions here are getting the help they need.
> then I feel that there is something wrong. Building packages is done for
> a port; I think the porters -- those who actually care about the port --
> should be the first to know and be informed about stuff going on; the
> best way to do that is by involving them in the actual building process
> more than is now done for almost every port, except m68k.
Yes, I fully agree. I think this is also the case of amd64 and s390. The
porters are the one who best know an architecture, and they care for
this architecture. This is not the case of random admin.
> I have now been somewhat maintaining the unofficial armeb port by
> myself, partially also in order to be able to compare the differences
> between, on the one hand, maintaining a few buildd hosts as part of a
> larger team for one architecture, and maintaining a few buildd hosts as
> the only person doing so for a given port on the other. In my opinion,
If I am right the m68k buildd team is not very small. Having a small
team (2 or 3 persons) could have the benefit of both solutions you describe.
> the differences are not as huge as they are often claimed to be: staying
> on top of failures is required in both cases, whether you're the only
> one or part of a team. Obviously it takes more coordination and
> communication to do it that way, but that doesn't mean it's impossible,
> as the m68k port has proven for quite a while now (the recent issues had
> little to do with lack of proper buildd maintenance, but with other
> On the other hand, people often say on IRC that they find the m68k
> buildd team to be the most responsive of all; I do not believe this to
> be a coincidence.
> Don't you agree it would be wise to bring this topic up with porters of
> a given architecture, and let them choose whether they want to remain
> with the status quo or would rather prefer taking over buildd
> maintenance by themselves? I have the feeling (though I obviously can't
> be sure) that some porters and ports would actually prefer going ahead
> with maintaining buildd hosts by themselves.
I agree with that.
One first step would be to keep the current build daemons maintainers
(ie the person who signs the upload), and give and access to some
porters to the wanna-build database. This way they could reschedule
failed builds, add dep-wait, or do binNMU. If I am right Steve Langasek
already has access to the wanna-build database of all architectures, so
that should not be a technical problem.
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' email@example.com | firstname.lastname@example.org
`- people.debian.org/~aurel32 | www.aurel32.net
- Re: buildd stuff
- From: Goswin von Brederlow <email@example.com>