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

Re: unstable/testing/[pending/frozen/]stable

On Tue, 21 Sep 2010 20:52:09 -0400
Yaroslav Halchenko <debian@onerussian.com> wrote:

> Hi All,
> CUT discussions at debconf10 and recent news of the birth of Linux
> Mint Debian Edition (LMDE) [1] show how valuable and unique  Debian's
> rolling distribution (testing) is.  But every freeze in the
> preparation to upcoming stable release in effect, eliminates
> 'testing' (and actually unstable... 

I don't see what that is meant to mean. Testing and unstable are
constantly present and functional during a freeze. What happens is that
the pace of new (disruptive) uploads and migrations is manually
limited. i.e. the stability and functionality of testing and unstable
*rise* during a release freeze simply because new transitions are not
started - in unstable or testing.

Unstable needs to be managed during a freeze because it is the
destination of uploads which fix RC bugs in testing. If there was a new
migration/transition in unstable affecting this package, the new upload
cannot migrate (and cannot fix the bug). Testing-proposed-updates isn't
an excuse for making a mess of unstable during a freeze.

> since experimental is not a
> complete distribution and we can't force users to use something with
> that name ;) ) until new stable sees the world. I wondered, why don't
> we have
> [experimental/]unstable(sid)/testing(e.g squeeze)/stable
> *constantly* present and functioning all the time the same way.

So when and where are library transitions meant to occur? Transitions
are always disruptive, always cause some packages to be non-functional
or non-installable. There has to be somewhere (unstable) where libfoo2
can be uploaded with libfoo2-dev so that all packages which depend on
libfoo1 can start the migration to the new API. As the migration
starts, there is a period (which in the case of GTK1->2 took several
years) where many packages in unstable are uninstallable or FTBFS or
just horribly buggy.

> Then upon freeze we just copy the state of
>   unstable -> pending
>   testing(squeeze) -> frozen(squeeze, e.g together with a codename)
> and link new codename (e.g. wheezy) against testing.

unstable is not compatible with *-proposed-updates - nor is having
*-proposed-updates an excuse for starting new transitions in unstable
during a freeze.

> Then unstable/testing would roll further as usual

How does a major, disruptive, transition get done?

>, and pending->frozen
> according to the freeze schedule.  This would enable CUTs, fulfill
> the ideas behind LMDE to have something rolling without hickups, and
> users of 'testing' (and unstable) would enjoy testing/unstable the way
> they usually do.
> I understand that it would require more work, but I think benefits
> would overweight the burden.
> But I cannot be first thinking about that, and I bet there were good
> reasons why such approach was not taken -- could anyone
> enlighten/point me to the shortcomings?

In a word, transitions.


Neil Williams

Attachment: pgpiBKMRqEAZC.pgp
Description: PGP signature

Reply to: