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

Re: "testing" improvements



En réponse à Eduard Bloch <edi@gmx.de>:

> > 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

This is true.

> 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.

I agree.

> 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 think asking such question doesn't apply to developers, who have
to use stable anyway.

> > 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

They would not be RC-buggy in testing I think.

> Testing versions is unthinkable, reverting to "stable" versions may be
> dangerous and not possible because of version names.

Isn't testing consistante in regard of dependencies between packages?

> 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.

I agree.

--
Jérôme Marant <jerome@marant.org>
              <jerome.marant@free.fr>

http://marant.org



Reply to: