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? > 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? (FWIW, I've never heard of packages being removed from testing on the grounds of maintainer inactivity -- only on the grounds of package bugginess.) > 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. > Another problem for the release is the Debian installer. The vast > majority of Debian installations is i386. If the new installer isn't > ready on all architectures it might be an option to ship some > architectures without installer in 3.1r0, and add the installer for > these architectures in 3.1r1 or 3.1r2. This way Debian 3.1 might be > released more early, and even for the affected architectures it's > better, since additionally to the status quo (installing and using > Debian 3.0), they can upgrade to Debian 3.1 . The new installer isn't ready on even i386 yet. But based on the progress d-i has made over the past two months, it looks like the installer has a good chance of being ready -- even on all architectures -- before the rest of the archive is ready to go. There have definitely been some mistakes to learn from in the time since the woody release, in terms of letting experimental changes loose in unstable; but sarge is definitely not standing still at this point -- even though the RC bug count doesn't seem to be going down, a lot of necessary work has been done both on the installer and on clearing the various blockages in testing. All things considered, we do seem to be much closer to a release now than we were 3 months ago. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature