Re: "testing" improvements
#include <hallo.h>
* Jérôme Marant [Thu, Feb 27 2003, 05:02:12PM]:
> > And $developer will know these are unofficial backports by simply
> > taking a look the version-string. These are _proper_ backports with
> > decreased version number with an identifier (woody, bunk, ...) in it!
>
> Sure they are mixed systems. Backporting an unstable package
> to stable doesn't make it stable. Those backports not even come
> from testing.
This depends on how you define "mixture". The mess you described in OP
is caused by strong library dependenices (to, say, 80 percent), since
the software can be compiled and used fine in Woody environment, w/o
problems. IMHO with 2 releases per year, nobody would do this work and
create Stable backports, but it is just not suitable for many users to
wait two years for a new version. It is even not about
version-name-adicts, it is just because lots of hardware is not
supported of _important_ features needed for production use are not
available for TOO LONG time. Considering our freeze phase, we ship with
0.2-0.5 years old software when the "Stable" is released, so we
theoreticaly should freeze the unstable branch as after Stable release
and work with it if we want to keep the distro not completely outdated.
And for all this developers around that may ask what I am talking about,
ask yourself: do _you_ really use STABLE on your own machine? And would
you? If not, why not?
> I'd prefer to see testing updated more often when possible (as I
> said on architectures that make it possible to be updated) so
> that people use testing instead of backported unstable.
This is not possible today. Either you give up binary consistency of the
package combination in Unstable (where the are is 1.level-tested) using
Pinning, or you give up consistency in versioning scheme (what you
propose). The first is currently useable but bad since you get an
untested mixture with possibly bad side effects. The second way is bad
since it will cause problems when the Freeze comes. What should happen
at the day F when 500 packages are RC-buggy? Releasing with buggy
Testing versions is unthinkable, reverting to "stable" versions may be
dangerous and not possible because of version names.
Your plan _would_ work when we see Testing as a "pre-freeze" fork,
similar to that unstable-freeze branches in "good-old-times". That is
what I would also like to have - stop having "always-releaseable"
testing branch and re-introduce something without
this-days-sid-critical-bugs and beeing always ready to be frozen. But
not to be frozen as "Testing" but as "Unstable" fork, completely
detached since the last semi-transparent Freeze of Testing was not a
great success.
Gruss/Regards,
Eduard.
--
Treffen sich zwei Kurven im Unendlichen, sagt die eine: Ey hau ab aus
meinem Definitionsbereich sonst diffenzier ich Dich !! Darauf die
andere: Macht nix ich bin die e - Funktion.
Reply to: