On Thu, Jan 17, 2002 at 05:16:56PM +0100, Adrian Bunk wrote: > Wit the scheme I describe every RC bugs has to be fixed within a maximum > amount of 2+2=4 weeks or the package will be removed. The possible removal > is visible to _all_ developers and NMUs are explicitely allowed one week > before the package might be removed - and there's a planned bug squashing > party that tries to fix most of the RC bugs. It's clear that similar to > the potato freeze there might be a handful RC bugs in packages we can't > remove (e.g. gcc or glibc) left after the two weeks if they are really > hard to fix, but after the first bug squashing cycle all other RC bugs > that were older than two weeks are resolved (by either fixing/downgrading > a bug or by removing the package). There's a subtle flaw with this proposal. Who will have to remove the packages for testing? The only people who can do this are the ftp masters. So the success of this proposal depends on the willingness of the ftp masters to pick up the slack for maintainers who aren't doing their job. If we need to be NMUing more aggressively to get RC bugs fixed, then let's arrange to do that. There's no reason why ftp masters need to be dragged into this to make it stick. The section in the developer's reference on source NMUs has remained virtually unchanged since the release of potato. What was considered best practice then does not seem to be working all that well this time around. If the presence of RC bugs is going to be allowed to delay the freeze, then we as a body need to start treating these packages as if they're already frozen and NMU appropriately. Of course, this does /always/ mean trying to coordinate with the maintainer first. I trust that many of the RC bugs left in base and standard are being worked on by the maintainers, and it would be foolish to spend hours trying to fix such a bug without checking with the maintainer first. But Our Priorities are Our Users and Free Software, to coin a phrase; and allowing developer autonomy to stand in the way of a release serves neither of these interests. > > So far we've been doing (3), with perhaps limited success. If you feel > > that (2) is more appropriate, you can get this effect by liaising with > > maintainers and bug submitters to downgrade bug severities in some > > suitable fashion. > The big problem is that it's hard for a single person to go through the > whole bug list and there are even bugs in base packages where I'm missing > the knowledge to fix them or where I can't do anything (e.g. AFAIR Ben is > waiting for the next upstream release of glibc to fix the security bug in > unstable). And currently I'm missing the motivation to go through the RC > bugs only to see that this doesn't result in a step forward the release of > woody - as already said in another mail I've already done much work both > on my packages and in bug squashing parties and also in partial going > through the lists of RC bugs only to see that the freeze still stalled. Certainly, some coordination efforts are in order. The base.debian.net and standard.debian.net pages are already somewhat useful in this regard. Perhaps some mods to these scripts that allow sorting by oldest-bug, and allow one to view bugs that have no comments from other developers, would make things easier. And you're right, there are some bugs that few developers are suited to work on; there's not much that can be done to help that. But for people who are interested enough in the freeze to put forth some effort on these RC bugs, there are ways to help. Steve Langasek postmodern programmer
Attachment:
pgpPHK7pf8euJ.pgp
Description: PGP signature