Some observations regardig the progress towards Debian 3.1
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
Reply to: