[cut-team] Ideas for the rolling release

[Anthony Towns]

On Sun, Aug 15, 2010 at 16:34, Raphael Hertzog <hertzog at debian.org> wrote:
> while reading the backlog I had few ideas/suggestions. First for the poll,
> I want to see both "rolling" and the snapshots.

As far as I can see the only comment on snapshots was:

>  - I agree with Lucas, the snapshot should be date-based: maybe the year
>   and then an increment: CUT 10.1, CUT 10.2. Or CUT 2010/1, CUT 2010/2.
>   Or something like this.

I tend to agree with date based versioning (I prefer four digit years
and months with a leading zero, personally); but I could see an
argument for merging with the stable versioning, so it goes something
like:

    6.0.0 squeeze release
    6.0.1 first squeeze point release
    6.0.2 second squeeze point release
    6.1 first post-squeeze CUT release
    6.2 second post-squeeze CUT release
    7.0.0 shark release [0]
    etc...

Of course, maybe that just means stable versioning should be date
based too (maybe without the month, so CUT releases are 2011-01,
2011-04, 2011-07, 2011-10, and squeeze is just "Debian 2011"). I also
think we should paint CUT releases blue.

As far as "rolling" goes, it's not clear to me what you're trying to
achieve. What is "rolling" meant to be better at than "testing"?

(If you've got some metric by which testing is lacking, it would be
very interesting to (a) monitor it, and (b) talk to the release team
about getting britney to automatically consider it when doing updates.
But obviously, that only works if it's a measurable problem, not just
an anecdotal one)

> Idea: support only a limited set of architectures in rolling

ie, it wouldn't support additional (non-release) architectures.

> Idea: allow targetted sid backports in rolling during freeze

ie, it wouldn't be less effort for maintainers than testing is.

>  - those backports could help disentangle transitions and make it more
>   likely to be able to push updates without breaking other packages

Note that that's true in theory, but not so much in practice. The
problem with transitions has tended to be actually fixing show-stopper
bugs, rather than something that can be glossed over by just choosing
a better combination of package versions to target. (In particular,
t-p-u is already available for this purpose, with autobuilder support)

> Comments:
>  - I want a usable rolling release but I'm uneasy with the fact that it's
>   not testing... the people using rolling should really implicitly
>   contribute on improving our next stable release. Ideally, testing
>   should be a branch of rolling that starts at freeze time.

At that point you're impacting the release team very heavily -- you're
changing their entire workflow; which might be a good idea (or might
not), but in either event is a pretty big challenge. I don't think the
potential benefits of a new "rolling" release have been made anywhere
near clear enough for that to have any chance of succeeding.

>   So we should really consider that rolling starts separate because it's
>   an experiment but at some point it should replace testing most of time
>   except during freeze. Hence it's important to have release managers
>   involved...

Replacing testing with a suite that doesn't include most of the target
release architectures would make life pretty hard, I think.

For some context, here's how (I think) those suggestions might look if
they were implemented by the release team on testing as it stands
today without the addition of a new rolling suite:

> Idea: support only a limited set of architectures in rolling

  - more aggressive (or continuous) use of the "break architecture"
options in britney for the non-special architectures, letting them get
out of sync in versions or have more dependency problems. This would
exacerbate the main "weather report" problem that currently exists
(non-x86 uninstallability), make transitions a little easier (porting
problems and buildd delays wouldn't block them), and make "CUT" a
misnomer for the non-special architectures. Non-special architectures
would probably have a very difficult job getting their port
release-ready when the freeze is declared, because at least the
release team will have allowed all the architecture specific problems
to pile up.

> Idea: allow targetted sid backports in rolling during freeze

  - do backports via testing-proposed-updates. For instance, if a new
libfoo and libbar have both been uploaded to unstable, and are tied
together because baz-utils depends on both, but the transition is
blocked because libbar (or some dependency) has new RC bugs, do libfoo
early by doing a build of baz-utils against the new libfoo and the old
libbar and upload it to t-p-u.

> Ideally, testing should be a branch of rolling that starts at freeze time.
>
> So we should really consider that rolling starts separate because it's
> an experiment but at some point it should replace testing most of time
> except during freeze.

  - at freeze time, branch testing into a "-1 point release", then
treat updates during the freeze like updates to stable, rather than
updates to testing. Once all the freeze updates have been accepted
into codename-proposed-updates, increment the point release number
from -1 to 0, and you've got your new official stable release. (That
potentially implies two things: the release team get less fancy tools
to help them during the freeze, and freeze updates will only be
accepted if they're minimal changes to fix RC bugs, not trying to
finish off new upstream releases or complete transitions, etc)

Hypothetically, I think some of those might even be good ideas; but in
practice the liklihood that it just confuses developers and makes the
release team's job harder still seems to outweigh the benefits to me
(adding a suite or changing testing are both likely to be confusing,
in different ways).

But maybe there's a clearer explanation of what "rolling" is meant to
achieve that would completely make sense of everything for me.

Cheers,
aj

[0] If there's not already a rumour that's what squeeze+1 is called,
I'm hereby starting it. Hi Maulkin!

-- 
Anthony Towns <aj at erisian.com.au>