I'm glad to see that at least one person in the whole Debian project
defends the interests of the end-user, by reminding everyone that the
end-user is the most important person, as stated in the Debian project
goals. Thanks Adrian!
This being said, back to the the proposed improvements:
Someone was recommending the creation of a pre-testing stage, where
packages would be built and verified as "ready to transit down to
testing". Unless I misunderstood, this stage already exists and that
would be the current Unstable branch.
The core of the problem, IMHO, is how unstable has become a playground
that really belongs to Experimental.
One example of this is, while Gnome 2.2 has made it to testing, most
GTK2/Gnome2 killer apps, like Evolution, are still stuck in Unstable.
Why? Two reasons:
1) Ximian cranks out more releases than the Debian maintainer can keep
up with, in addition to having to fix bugs reported by Debian users.
2) New Debian builds of whichever release are built against whatever
libs are in unstable.
Point 1 is easy to fix: don't try to keep up, we are still at the
Testing stage, at this point, so no need to be on the bleeding edge
and, most of all, no need to force users to run Unstable just to get
access to packages that every other distro out there has included for a
few months already.
* In relation to this, Mozilla 1.3 (IMHO, the last rock-solid built
we've had on Debian) was good enough for Testing and should have been
allowed to trickle down, instead of being constantly replaced by
progressively buggier 1.4 and 1.5 releases. While the novelty factor of
1.4 and 1.5 might be fun to some, replacing packages that are just
about ready to reach their 14 days without RC and go into Testing, by a
newer version, is pretty much amounting to mental cruelty. I mean, did
anyone even look at what Mozilla version is currently in Testing? That
would be 2:1.0.0-0.woody.1, a package that should not even belong to
Testing since it was built for Stable.
Point 2 is more complicated to fix, because Evolution's dependencies,
if we look at them recursively, always turn out to depend upon a lower
level package that keeps on seeing more uploads, which means that this
particular dependency never reaches Testing without divine
intervention.
Let's say (hypothetically - I haven't looked at Evo's dependencies)
that Evolution depends upon GNU TLS, which is built against whatever
version of glibc that is in Unstable. An RC bug is found in glibc, so
another upload is made, which means that GNU TLS and then other
dependencies must be rebuilt against the purportedly fixed version of
glbic... until another series of RC bugs are found and fixed, which
results in yet another upload. It never ends.
My solution to this is as follow:
1) Only build packages against dependencies that already are in
Testing, always. If a new package (e.g. a new Evolution from upstream)
depends upon libraries or a version thereof not yet in testing, build
the said library against the glibc and other dependencies in Testing,
then build Evolution against that, then uploaded them both to Unstable
for their 14-day processing. This should guarantee that Testing always
is in a releasable state, since everything in it is only built against
the libraries it offers.
2) As a result, developers of glibc, XFree or any other major package
only try their new tricks in Experimental. If and only if it looks like
a given version has reached a point where it's ready to use, attempt an
upload to Unstable, then move on to debugging and packaging the next
upstream release, within the realms of Experimental.
In other words, I propose that the scope of the current 4 branches be
refocused as follow:
1) experimental
The hacker playground. Dodgy uploads allowed. No guarantees to anyone
on the sanity of anything there.
2) unstable
* Whatever was thoroughly tested by developpers in experimental and is
considered ready for the masses, is cautiously uploaded here. New glibc
versions that have been thoroughly debugged would fit this category.
* Trusted packages entering Debian for the first time and which were
built against Testing dependencies also enter the release chain here.
New releases of Evolution based upon GTK2 would fit into this category.
Architectures don't have to be in sync, although an attempt is made to
build on all of Debian's supported architectures, as a first exercise
in QA on the package; RC bugs are fixed and a new build is uploaded,
until the package has passed the usual 14-day rule and finally builds
on all architectures, at which point it trickles down to Testing.
3) testing
Whatever passed the 14-day rule AND builds on all architectures (and no
exception allowed - we don't want another gblic 2.3.2-9 going in sans
hppa, thank you) trickles down to here. By doing this, Testing is
ALWAYS in a releasable state.
4) stable
Remains as conservative as before. Only receives uploads that fix RC
bugs on its existing packages.
Hopefully, the above made sense.
