[cut-team] Ideas for the rolling release

[Raphael Hertzog]

Hi,

On Sun, 15 Aug 2010, Anthony Towns wrote:
> 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"?

It's meant to be usable by users.

I am one of those that believe that testing is mostly usable but we have a
bunch of DD who thinks the opposite and who regularly tell users that
testing is not usable. I think "rolling" is trying to fix some of the
perceived problems that lead those developers to make those claim.

I agree in general though that the rolling release should be testing and
that if possible it's best to improve testing. That said, it's good
sometimes to think out of the box and discuss how we would solve the
problems if we were free to implement whatever we think is best and then
maybe try to see what those ideas mean in the context of testing (just
what you did).

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

AFAIK the release team is not working much on improving britney (and I
don't blame them, I guess it's not an easy task). I doubt that coming up
with ideas is enough, working code is probably better and for that
a suite where we can experiment is probably worth it in the start.

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

Why is t-p-u not used much?

- It's a lot of work to prepare those uploads and you're not sure of the
  resulting dependencies without manual inspection.
  => what about auto-building sid in testing (when versions differ) and
     have the resulting suite available to britney?

- those packages have not been tested in sid
  => encourage some testing users to run with the sid-built-in-testing
     activated and consider those packages only after a delay (somewhat
     longer than the usual unstable delay to favor the binaries from
     unstable first)

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

Hence a little bit of experimentation is welcome IMO. OTOH, the rules for
rolling/testing impact what developers would upload to sid and if they do
not match, it might create somewhat of a mess for the release team.

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

That's what I thought too. I wanted to write it down but ended up not
doing it because in the end it's worth to think about why the freeze would
not be the perfect time for the ports to catch up...

We're slowed down by various ports and we have rules to evaluate whether a
port is good enough to not slow us too much. Why don't we go to the next
step and say that most ports are not allowed to slow us down. They keep
up as good as they can during development. They are supposed to catch up
during the freeze. It would also mean that the "arch qualification"
process can happen during the freeze instead of during the development
cycle. And it judges the result rather than the perceived capacity.

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

It would be much more like the stable release update policy. Note that
this one has "bring back architecture in sync" as one of the reasons to
allow updates:
http://penta.debconf.org/dc10_schedule/attachments/167_dc10_srm.pdf

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

Huh. Wasn't testing confusing when we introduced it?

This is a rather poor justification for not doing anything.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)