[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Some observations regardig the progress towards Debian 3.1

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.

Reply to: