Hi, below are some subjective opservations and opinions regarding the progress towards Debian 3.1 .
Please read it, and make your own opinions on where I'm right and where I'm wrong, even if you might not agree with my opinions on other issues or if you don't agree with everything below. This is not meant as a personal offence against anyone. E.g. I'm taking KDE as an example below, but this shouldn't imply anything about the quality of KDE or the packaging of KDE. The reason why I write this mail is that I often can't tell someone who asks me "Which distribution should I use?" to use Debian since: - Debian 3.0 doesn't support much of the hardware curently available - the old 2.4.18 kernel on the boot floppies doesn't even boot on many new computers (some Promise IDE chipsets require a more recent 2.4 kernel), and much hardware from nearly all currently abailable graphics cards to scanners is not or not appropriate supported - testing, unstable or Debian 3.0 with backports aren't suitable for production systems My impression is that many Debian developers don't use a Debian 3.0 (without backports), and that they therefore don't know how outdated it is. Backports are only a workaround, not a solution for this problem. Mixing half a dozen backport sources of various quality is in my experience not more stable than using unstable. Today, it's only 17 days until the officially announced "aggressive goal" for the release of Debian 3.1 [1]. That's a date many users know about, but I don't see any real progress towards Debian 3.1 during the last months. Let me start with some observaions regarding testing: testing has some advantages: - it's usually partially consistent in the sense that usually all depedencies are fulfilled - testing detects some problems that might be unnoticed otherwise (e.g. build errors on one architecture) - testing forces maintainers to care more about their packages if they want to get them into testing testing has some disadvantages: - testing doesn't itself ensure a releaseable state (e.g. it contained for some time a mixture of GNOME 1 and GNOME 2) - often you can't build testing within itself, since the testing scripts ignore build dependencies - testing needs much manual interaction, e.g. it's practically imposible for a package like Mozilla, where two dozen packages have to depend on the exact version of Mozilla, to ever enter testing without a massive manual interaction 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]. 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 . Debian 3.0 contains 7 CDs with binaries and Debian 3.1 might contain 10 or more CDs. How do you explain to a user why there are 10 CDs, but this popular package is not included, and that package he needs is not included? Saying "The maintainer didn't care enough about the package you need." only sounds like a good reason to switch to RedHat... :-( The Debian Social Contract says "Our Priorities are Our Users and Free Software" - if your users are a priority, dropping packages from a release shouldn't occur when it isn't badly needed. Let's go back to some observations regarding what's needed to come nearer to Debian 3.1: You can't freeze testing at any time - getting fixes that might be in the packages in unstable for a long time from unstable into testing to get testing into a releasable state might take more time than starting from unstable. Currently, many new upstream versions flood into unstable every day. Trying to get this or that package into testing is a Sysyphos task, since once this or that problem with moving packages into testing is solved, the next one pups up. 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. 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 . Thanks for reading this mail. Yours Adrian BTW: Reply-To set to debian-release. [1] http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200308/msg00010.html [2] both numbers +-50 [3] http://www.debian.gr.jp/~kitame/maint.rhtml [4] As a sidenote: It would be good, if the Debian Technical Committee would be more active, and would make decisions in controversal cases where a discussion on debian-devel didn't lead to a result (e.g. the GCC Steering Committee is much better in this respect). -- "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
