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

Re: The unofficial buildd effort and its shutdown - my POV

Steve Langasek <vorlon@debian.org> writes:

> On Sun, Sep 05, 2004 at 10:18:04AM +0200, Goswin von Brederlow wrote:
>> Thomas Bushnell BSG <tb@becket.net> writes:
>> > Ingo Juergensmann <ij@2004.bluespice.org> writes:
>> >> True, there's no formal process for people like me, although I proposed some
>> >> ideas for something like that some time ago, but that was put down as any
>> >> other idea, most likely by the same people that are now yelling loudly about
>> >> trust. It was put down for reasons like "That's nonsense! That can't be
>> >> done. Shut up, moron! If you want, become a DD!"
>> > So... I'm a little confused.  What do you mean "there's no formal
>> > process for people like me"?  The NM process certainly allows for
>> > things other than package maintenance.  What about you is not covered
>> > by the existing process?
>> How about nothing? The NM process realy doesn't apply to someone
>> willing to contribute resources (like a system so that a DD can run a
>> buildd):
>> - He doesn't need to know the Social Contract or DFSG.
> I think this claim epitomizes the disagreement between those who think
> buildd admins should be DDs, and those who think it doesn't matter.  The
> Social Contract is the core expression of Debian's value.  What message
> does it send if we don't expect people responsible for core parts of our
> infrastructure to uphold these values?  Or, what message does it send if
> our ports can't be sustained by people who are committed to these
> values?

The buildd admin must be a DD since he is maintaining the software
(needs the packaging skills) and uploads packages (needs a gpg key to

IMHO the question is: Does the hoster need to be a DD? Would you
require IBM to sign the SC before they can offer Debian an S390 to run
a buildd on? Does Ingo haveto become a DD just because he is a trusted
(by other DDs) individuum instead of a big scary unknown cooperation?

Think about it from that side for a moment.

>> - He doesn't need to know about packagin or about running Debian at
>>   all. The host sytem doesn't even have to be debian.
> Heh.
>> All a buildd host admin needs is trust from Debian not to screw Debian.
> Part of "trusting" people is trusting that they'll act in the interests
> of the Debian community, which means agreeing to the SC.

Again, does IBM agree with the SC? Does HP?

It certainly doesn't harm if the buildd hoster does. But if you
compare giving Debian CPU time with giving Debian bandwith or money
requiring the NM procedures sounds a bit silly.

IMHO it is enough to not object to the SC which can be a different
thing. The buildd hoster doesn't act in the interests of the Debian
community since he does no work at all (apart from keeping the
_hardware_ running).

>> > It sounds like you stopped the buildd's because you chose to, not
>> > because you were told to.  You seemed to me to take a few people's
>> > discussion as determinative.  I have no particular opinion about the
>> > substance of the matter, but your action seemed premature to me.
>> No, two quite influencial people said to stop it. Read the thread to
>> find out who. The discussions on irc were even more hostile but from
>> less important people.
> I'm afraid I didn't see anyone telling you to stop, even upon rereading
> the thread; only people expressing concerns.  What I did notice was you
> curiously overstating the impact of these unofficial builds, to wit:

Collin Watson: "I would simply like this practice to stop immediately."

I interpret that as a polite way of telling me to stop.

>  - The most recent blocking issue on arm is a Qt FTBFS, which could
>    hardly be addressed by adding buildds, so taking credit for other
>    architectures not being in the same state is inaccurate.

So you are saying that the ~800 packages backlog (counting needs-build
and build but unhandled) on arm was all caused by one single package?
That adding a second build wouldn't help process those packages faster
once the Qt FTBFS is(was) fixed?

>  - The alpha architecture has a fast new buildd that's been operational
>    for some time now, so while a certain amount of spot-building was
>    helpful in keeping testing moving until goedel was brought on-line,
>    it's disingenuous to suggest this architecture would have trouble
>    keeping up today without extra help.

It did have trouble and the temporary buildd did bring down the
backlog. That alpha then recovered due to the new official buildd
coming online doesn't change the work being done. Alpha could not keep
up and relieve was provided.

Alpha touched one of the main problems with the official buildds. If
it takes 3 weeks to get the OK and wanna-build access from James just
to run a buildd for 4 days while the normal one gets fixed that makes
it pointless.

It would be nice to have some preapproved people that can jump in on a
moments notice and setup a buildd for a few days. A fast acting
disater relieve team. And by that I mean are allowed to jump in. 

>  - A number of the "home-built" binaries that have been uploaded
>    recently have not been sanity-checked -- including at least one
>    broken binutils package and one broken gcc-3.3 package.  It is
>    questionable whether broken uploads *ever* advance the goals of
>    the release compared with having to wait for the autobuilders to pick
>    them up.

Buildd uploads are not sanity checked. Personally I spot check some
packages before uploading, such as binutils, glibc, gcc. But the
normal mode of operation of a build (official or not) is to just sign
packages and let the buildd upload. Sometimes that means broken
packages get uploaded, that is how it is.

Unless you claim incompetence on the side of one of the buildd admins
the quality of the unofficial buildds equals the official ones.

Actually the reverse was starting to become true. The mipsel buildd
was running the extra code from multibuild that does some post build
checks I've been working on. That includes upgrading the packages from
their previous version, removing them, purging them, installing them
from scratch. I was about to add some post build testsuites for
packages too, like building hello_world.c for gcc.

> This is not to suggest that unofficial binary builds are never helpful,
> but they are most definitely a *workaround*, not a solution; and there
> are certainly valid reasons to be concerned about who has root access to
> machines that are being used for building Debian packages.

Concerned yes. I think the only remaining question is who is qualified
to address those concerns and make a decision? Only James Troup or any
long-time buildd admin or any DD?

> -- 
> Steve Langasek
> postmodern programmer


Reply to: