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

Re: buildd administration

On Sun, Dec 11, 2005 at 03:46:12PM -0800, Thomas Bushnell BSG wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:

> > On Sat, Dec 10, 2005 at 03:51:36PM -0800, Thomas Bushnell BSG wrote:
> >> Anthony Towns <aj@azure.humbug.org.au> writes:
> >> >   (a) seeing if the FTBFS can be fixed immediately, and finding it can't
> >> >   (b) documenting (this is the transparent bit, so pay attention) that
> >> >       fact by not having s390 incorrectly listed as a supported arch in
> >> >       the source and ensuring it does not incorrectly indicate a known
> >> >       broken build is successful as it did in the past
> >> >   (c) informing ftpmaster that the build currently in the archive is
> >> >       broken by filing a bug requesting the broken build be removed
> >> >       (you know, communicating with people)
> >> >   (d) downgrading the bug so that it is not incorrectly listed as
> >> >       a RC issue that the RM and QA teams have to attend to
> >> >   (e) as maintainer, work with upstream and porters to fix the
> >> >       downgraded but still open bug we were just talking about
> >> I disagree with this.  

> > Then you're not maintaining your packages properly, and you're making
> > life more difficult for the rest of the project out of spite.

> You are incorrect.  I disagree with your approach to fixing this
> particular problem.  I think it is better to keep the package out of
> testing until the problem is resolved one way or the other.

> You have failed to detail any particular difficulty that this causes,

I'm pretty sure I saw him do this already, by noting that it increases the
number of packages that the release and QA teams have to keep track of.
It's great that you're concerned about the portability of the package, but
there are 500+ open RC bugs known to be relevant to the next release, and
1300+ RC bugs all up that affect packages in unstable.  Packages with bugs
in the first category add to the release team's workload of
downgrading bugs/NMUing/pestering maintainers/removing packages; packages
with bugs in the second category add to the QA team's workload of figuring
out if maintainers are MIA, whether packages should be removed from the
archive, and so on.  Bugs in both categories make it harder for would-be
bugsquashers to sift through the bug lists to find packages that they can
usefully NMU.

Also, after a certain point 1300 RC bugs * n binary packages per source
package * 12 architectures starts to look kinda wasteful on the mirrors.
There are 9450 source packages in unstable/main today; assuming
(optimistically?) that half of these RC bugs map uniquely to source packages
that we should consider removing, that's still about 6% mirror overhead from
packages we should be getting rid of, and as much as another 6% of packages
that complicate the process of figuring out which 6% ought to go...

> nor have you given any reason why the package should be added to
> testing in advance of my judgment that it's ready, nor have you given
> any explanation of why you think it's ready now.

If we suddenly decided to release etch next month, what would you do with
this package -- keep the RC bug open because you think s390 support is more
important, or ask for the removal of the old s390 binaries because the
package is worth something to users of other architectures?

How long is it reasonable to postpone taking this action, then, knowing that
such bugs clutter the various tracking lists to the point of making them
unusable for some purposes today?  How long is it reasonable if 50
maintainers are sitting on bugs like this?  If 100 maintainers are?

> You have not pointed at any documentation of maintainer policies that
> indicates that one must clear an RC bug as soon as possible, for
> unreleased packages, to push them into testing before the maintainer
> thinks they are ready.

Rather, it seems much more likely that we would want to push such packages
*out* of unstable.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: