Rogue autobuilders (was: Re: New ARM autobuilders)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Rogue autobuilders (was: Re: New ARM autobuilders)

Michael Banck
Hi,

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

On December 17th, 2006, Aurelien Jarno wrote on his blog:
> As [hidden email] 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... )


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rogue autobuilders (was: Re: New ARM autobuilders)

Aurelien Jarno
Michael Banck a écrit :
> 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

and packages never uploaded, packages never requeued, build daemons
fuckage...

> 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).

and send a mail to [hidden email] and wait forever...


--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   [hidden email]         | [hidden email]
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rogue autobuilders

Julien BLACHE
In reply to this post by Michael Banck
Michael Banck <[hidden email]> wrote:

Hi,

> 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

Running rogue autobuilders as you put it has saved a couple of
architectures and unstuck testing a few times already.

Please provide us with responsive ftp-masters, responsive buildd
maintainers and responsive DSA so we don't have to set up what you
call "rogue autobuilders".

Thanks in advance,

JB.

--
 Julien BLACHE - Debian & GNU/Linux Developer - <[hidden email]>
 
 Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Rogue autobuilders (was: Re: New ARM autobuilders)

Wesley J. Landaker
In reply to this post by Michael Banck
On Wednesday 20 December 2006 09:19, Michael Banck wrote:
> On December 17th, 2006, Aurelien Jarno wrote on his blog:
> > As [hidden email] 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; [...]

Right, the proper way is for the appropriate people (DPL, DSAs, buildd
infrastructure people, whoever can actually DO something about it) to
say, "awesome, Aurelien! Thanks for taking some initiative, setting this
up, and providing both your time and hardware to *vastly* expand the power
of the ARM buildds! Now, let's integrate that into the regular buildd
system by [doing some productive action ...]"

So, Mr. DPL -- if this is *not* happening because no one is communicating,
or whatever, can you please take some responsibility here? Help
communication, assign more delegates, or work this yourself?

--
Wesley J. Landaker <[hidden email]> <xmpp:[hidden email]>
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2

attachment0 (196 bytes) Download Attachment