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