[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Explications needed...

Le jeudi 28 décembre 2006 à 16:45 -0800, Steve Langasek a écrit :
> So first of all, neither the debian-arm list, nor the #debian-arm channel,
> nor his blog are a communication medium that's guaranteed to reach the arm
> buildd maintainer *or* the buildd local admins.  For the former, you want
> $port@buildd.debian.org; for the latter, there is no list of contacts other
> than the buildd maintainer, since these may change semi-frequently and most
> buildd changes need to be coordinated with the buildd maintainer anyway.

An arm buildd maintainer not reading debian-arm@l.d.o is simply not
doing his job as buildd maintainer. You can't pretend to be the one
handling builds for the whole archive while not following discussions
around problems specific to this architecture. Would you trust a release
manager who wouldn't be reading debian-release?

> If he only uploads packages that haven't been built by the autobuilders, or
> failed to build on the autobuilders, we still have the problem that there is
> no single party who can account for the configuration of all the buildds
> that were used for uploading packages, because there has been no
> coordination -- so building these packages on rogue autobuilders is a poor
> predictor of whether the autobuilders will be able to build them again later
> when a security update is needed.  Indeed, in the case of Aurelien's
> buildds, we have the additional variable of using emulated arm systems -- I
> don't know what ARM instruction set qemu emulates, and I don't know who else
> among the ARM porters knows, maybe it's been discussed and maybe it hasn't,
> but it's definitely another variable that contributes to these buildds being
> a poor predictor for the official autobuilders.

Please, let's be consistent. How is it any different to the sourceful
upload case? In fact, I trust Aurélien's buildd much more than my own
sourceful uploads; last month I have broken an amd64 package by not
building it within the right chroot, while this cannot happen with his
buildd using the same software setup as the official buildd network.

> Uploading packages like this is an expedient fix that does nothing to help,
> and possibly quite a bit to hinder, long-term support for etch.  We want to
> fix autobuilder problems, not cover them up.

Then let's fix them, now. For example, by making Aurélien an arm buildd
maintainer. Unless you want etch to be delayed for 6 months because of
missing buildd infrastructure, but things like that could never happen,
could they?

: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

Attachment: signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Reply to: