[cut-team] Ideas for the rolling release

[Reinhard Tartler]

Hi folks,

In the cut talk, I've been totally convinced that something like cut
would be very beneficial for Debian. However, reading the backlog of
this mailing list, I'm becoming more and more concerned how cut will
impact our current 'testing' process. I think we should really consider
this for the design of cut as well.

AFAIUI we have two approaches: 'snapshotting testing' and 'rolling',
while the implementation of the latter is not entirely clear to me.

On Sun, Aug 15, 2010 at 23:34:40 (CEST), Raphael Hertzog wrote:

> Hello,
>
> while reading the backlog I had few ideas/suggestions. First for the poll,
> I want to see both "rolling" and the snapshots.
>
> Idea: support only a limited set of architectures in rolling
>  - users that want bleeding edge and that can't cope with testing or
>    unstable are mainly desktop users and desktop users mainly use
>    i386/amd64

I agree to limiting to Intel, and maybe powerpc and arm because they are
the most important architecture from a user base POV. I hope that this
group is most likely to produce 'good' feedback in terms of bug-reports,
etc.

Moreover, as Daniel points out, we have Debian Live 'ready' for these
architectures. So 'cut' releases could feature both 'traditional' d-i
based CD-sets and Live-CD based installers.

>  - it also means simplified management of migrations when rolling get
>    updates directly from sid during the freeze

This depends on the implementation. If we want to snapshot testing
(which I am actually in favor for), then packages would first need to
migrate to testing anyway. But that would also mean no transition
fast-tracking.

I fear that if we allow packages to fast-track transitions, maintainers
are less likely to care for 'testing' and focus only on cuts.

> Idea: allow targetted sid backports in rolling during freeze
>  - those backports could help disentangle transitions and make it more
>    likely to be able to push updates without breaking other packages
>  - lucas mentionned this possibility but only for updates requested by
>    users, I think it's important for the reason above.

Again, I fear that will seduce maintainers to upload crack-of-the-day
packages to unstable, disturbing the 'regular' unstable migration
espc. during freezes. This again is very likely to make the work of the
release team more difficult.

Idea: have both 'cut' and 'cut-rolling' suites

  - the 'cut' suite is strictly following testing, similar to how
    testing follows unstable. This means that normally, cuts are kept in
    sync with testing, but during freezes, migrations from 'testing' to
    'cut' are kept manually. This way we ensure that the current RT
    does most of the work for 'cut' during their regular work on 'testing'.

  - the 'cut-rolling' suite contains (semi- ?) automated backports from
    *experimental* (not testing). Direct uploads to 'cut-rolling' are not
    permitted. This should encourage people that care for 'cuts' to care
    for testing at the same time, even if that only means to not disturb
    the 'regular' testing migration. QA for 'cut-rolling' is therefore
    ensured on two levels:

     1. since it is based on 'cuts', we get the our well-known testing QA
        that has proven to work pretty well
     2. for add-on packages, the cut team reviews backports nominations
        by individual package maintainers.

I imagine that cut-rolling has most relevance when we freeze for a
release, like right now.  During regular development with mostly
unsupervised transitions, cut-rolling is likely to ship less backports.

Good "current" candidates for 'cut-rolling':

 - xulrunner 1.9.2
 - ffmpeg 0.6
 - KDE
 - Gnome
 - gcc 4.5 (as add-on package, not as default compiler)
 - ...

I don't think that toolchain packages (like gcc-defaults, binutils,
debhelper, cdbs, etc.) are well suited for the purpose of 'cut-rolling'.

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

AFAIUI, the release managers have concerns about the whole cut idea, and
I've tried to explain why I think so. AFAIUI the paragraph above
proposes a "put the 'cut' suite between 'testing' and 'unstable':


   'stable' < 'testing' < 'cut' < < 'unstable' < experimental

I'm proposing a 'sandwich' approach:

   'stable' < 'cut' < 'testing' < 'unstable'    < experimental
                                < 'cut-rolling' < expreimental

>  - 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 have no strong opinion here, but TBH, I favor Anthony's suggestion to
merge with our regular release number scheme for consistency reasons.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4