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

Rogue autobuilders (was: Re: New ARM autobuilders)



Hi,

(not really directed at Aurelien personally, but rather talking in
general)

On December 17th, 2006, Aurelien Jarno wrote on his blog:
> As arm@buildd.debian.org is everything but responsive (well if you can
> assign a level of responsiveness to /dev/null), I have decided to act. I
> have installed QEMU on an 8-way Opteron machine, and created 8 emulated
> ARM machines, which 256MB of RAM and 10GB of disk for each, all running
> buildd + sbuild. Altogether those 8 emulated ARM machines should be
> faster than all the Debian ARM build daemons. I have setup a wanna-build
> database on my server. During the day it has built around 100 packages.

I don't think this is the proper way; people should not operate buildds
(and then upload binaries) unless this is coordinated with the
respective arch buildd admins.  In this case (mass uploads of arm .debs
built on emulated machines), this was clearly not coordinated.  If your
coordination effort is met with silence, that means it failed and you
don't get to upload your autobuilt .debs, as sad as that might be.

While I believe Debian Developers have the right to upload .debs, they
don't have the right to upload any .deb.  In particular, they have the
right to upload their own packages, NEW packages, sponsor packages and
do NMUs accordings to the current NMU guidelines.  If they are porters
for a particular architecture, they have the right to do porter uploads
(though with the new central binNMU scheme, this should be needed much
less often, and can probably be restricted to packages which need manual
bootstrapping due to cyclic Build-Depends etc.) of specific packages.
But even if you are a porter, you should not mass upload packages and
circumvent the (very valuable) central wanna-build data-base and the
buildd admins.  

Running rogue autobuilders does not help Debian in the long term, and
will only lead to useless tension.  The best way to help a lagging port
is to identify arch-specific build failures which need real porting (and
are not just dep-waits) and tackle those, IMHO (I don't know whether the
arm port has any pending issues to that end right now).


cheers,

Michael

-- 
<vorlon> also, is there anyone alive who understands && doesn't hate
        mesa's debian/rules?
 * ejka . o O ( you can write fortran program in any language... )



Reply to: