On Sat, Nov 15, 2003 at 03:42:26PM -0600, Steve Langasek wrote: > On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote: > > > During the last months, the number of RC bugs of packages in unstable > > was constant at 700 bugs including 500 RC bugs in packages that are in > > testing [2]. > > > Yes, there's the common argument "Don't talk, fix bugs.". Unfortunately > > this doesn't work: Debian is too big. I might e.g. be able to fix 50 > > easy to fix RC bugs in unstable, but this would be lost in the noise, > > and wouldn't result in real progress. > > > Debian with over 1200 maintainers and over 13000 packages [3] is too big > > to work in the relatively unstructured way it is currently. Announcing > > 0-day NMUs isn't sufficient to get a significant number of bugs fixed, > > it's at least required to organize many bug squashing parties and to > > work hard to get many people involved in them [4]. > > Are you planning to organize a bug squashing party, then?
I'm willing to organize bug squashing parties (one is for sure not enough), but this has to be part of a release plan that seems doable and that is enforced. The latest published release plan is quite obsolete. > > It's often suggested to remove packages (at least from testing) if the > > maintainer is inactice. > > > If a maintainer is MIA, his packages should be orphaned and he should be > > kicked out of Debian as soon as possible. > > > But for a user, it doesn't matter why a package isn't in Debian stable. > > E.g. I've heard questions why gnuchess isn't in Debian 3.0 . > > Do you feel there are reasons why > <http://bugs.debian.org/release-critical> and the various scripts > floating around to provide daily RC reports fail to ensure that packages > people care about are taken care of in spite of the maintainer? What > methods would you propose to better balance between providing the > software users need and not distributing packages that are > embarrassingly buggy? - frequent bug squashing parties - faster orphaning of packages of MIA maintainers > (FWIW, I've never heard of packages being removed from testing on the > grounds of maintainer inactivity -- only on the grounds of package > bugginess.) A MIA maintainer doesn't fix bugs in his packages, and this can lead to the removal of a package. It's perhaps nitpicking whom of us is right in this case. ;-) > > For testing to work good, it's required to have unstable in a good > > state. Often new so-versions of libraries enter unstable, and e.g. KDE > > 3.2 might soon go into unstable. If testing should be frozen, it's > > needed to _freeze unstable_ (IOW: require RM approval for every upload > > to unstable). This doesn't need to be under a "no new upstream code" > > policy at the beginning, but at least beta versions, new so-names and > > major upstream releases (e.g. avoid KDE 3.2, but 3.1.5 is OK) should > > be avoided. > > Yes, I've actually been pondering whether it wouldn't make sense to try > to serialize major transitions (such as soname changes), to improve our > chances of keeping testing both releasable and reasonably up-to-date at > all times. I've also tried to encourage mini-freezes in cases where > groups of packages were almost-but-not-quite ready for testing. >... After nearly three years of testing, my impression is that the hopes that testing would be always releasable were never fulfilled. woody was the first release that started from testing, and there was much more than half a year between the beginning of the freeze and the actual release. Your work of trying to get packages into testing through mini-freezes is what I called a "Sysyphos task" in my initial mail: As long as the flood of new upstream versions into unstable isn't stopped, there are always new problems poping up once the current ones are solved. You need a freeze at one point (unstable or testing) to get a base where you can start to fix the remaining problems without new bugs from new upstream versions. The choices are: - freeze testing and start then to backport all the bug fixes and security fixes from unstable - freeze unstable and try to get as many packages as possible from unstable into testing (exactly the work you are currently doing, but based on a more stable basis) - freeze unstable and use unstable as a basis All three choices are doable. I'd say the first one is most work of the three choices, but these are only my personal feelings. > Steve Langasek cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
