On Wed, Nov 19, 2003 at 05:34:53PM +0200, Martin-Éric Racine wrote:
>...
> 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.
That's wrong.
The latest upstream release of Evolution is two months old, and it was
uploaded to unstable less than 10 days after it's release.
>...
> 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
You know that what you call "bleeding edge" are upstream releases that
contain mostly bug fixes and translation updates?
> 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
How do you back your statement that 1.4 and 1.5 are "progressively
buggier" than 1.3?
> 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
>...
Which "14 days"?
Testing has a 2/5/10 days rule.
>...
> 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.
Don't make hypothetically examples.
If you want to improve testing, start with understanding exactly how
testing works, and come back with real examples (it's pretty easy to
find the problems preventing Evolution from entering testing when you
read update_excuses).
> 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
As said above, there is no "14-day processing"...
> is in a releasable state, since everything in it is only built against
> the libraries it offers.
Besides other problems, one RC bugs in the chain of packages will cause
your proposal to fail.
> 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.
unstable is unstable.
Even if you start in experimental, many problems (recent examples are
e.g. the NPTL problems with programs wrongly using errno, or the binary
incompatibility in Perl 5.8.1) don't show up until the package gets a
wider testing in unstable.
>...
> 2) unstable
>...
> * 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.
The way testing works, this might effectively make it impossible for new
so-version of libraries to ever enter testing...
>...
> 4) stable
>
> Remains as conservative as before. Only receives uploads that fix RC
> bugs on its existing packages.
That's wrong.
The rules for stable are stricter than "fix RC bugs". Except selected
exceptions, only security fixes are allowed.
> Hopefully, the above made sense.
No.
cu
Adrian
--
"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
