Re: A concrete proposal for rolling implementation
2011/5/5 Raphael Hertzog <email@example.com>:
> On Thu, 05 May 2011, Stefano Zacchiroli wrote:
>> Also, having the unstable-next suite you've mention would tight more the
>> deployment of rolling to other project mechanisms, while the rest of the
>> proposal enjoyed much more decoupling.
> There's no reason why this unstable-next would be a requirement to start
> rolling. It's just a suggestion of how to handle package updates during
> the freeze.
I've been disappointed at first to read that so many approve this
"rolling" implementation that in fact is just "c-u-t", constantly
usable testing ! Outside of the freeze period it doesn't really
matter and one can say rolling==cut.
However, some key points added later with 'unstable-next' really
completes the missing piece to call it "rolling"! During the freeze
"unstable" is in a de facto freeze, but packages not suited for the
next stable release in preparation could be uploaded to
'unstable-next'. The 'unstable-next' suite could be used for several
1) some packages could be picked from it for 'unstable' -> "testing"
2) all packages from "unstable-next" are a candidate for "rolling"
3) after the final stable release all packages could be moved directly
from 'unstable-next' to 'unstable'.
Although #3 might not be practical without other infrastructure
changes, but was the core of this discussion in debian-devel.
"rolling" has only derived from not freezing "unstable", but the
initial proposal was to be able to never freeze unstable. It is my
believe that by using the freeze time to upload packages as usual will
help to prepare the next release by extending the pre-freeze
development from 1.5 years to 2 years.
To conclude, "unstable-next" suite (or some other name ) is a
requirement for "rolling" .
 although the CUT team might have a different view for 'cut', I
don't know what's the current direction
 but not "experimental"
 I agree with Raphael that is not a requirement to *start* "rolling"