[cut-team] Ideas for the rolling release

[Raphael Hertzog]

On Mon, 16 Aug 2010, Reinhard Tartler wrote:
> On Mon, Aug 16, 2010 at 16:18:46 (CEST), Raphael Hertzog wrote:
> 
> >>   - 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:
> >
> > I think using experimental here is only a bad way to avoid maintainer
> > uploading stuff to sid that is targetted to rolling without consideration of
> > testing.
> >
> > I don't find this a good design.
> 
> OK. But could you please elaborate why you don't think experimental
> appropriate for that?

Because experimental is for stuff that is not yet ready for end users.
It can't be reliably used to feed a rolling release that is supposed to be
usable.

> Uploading a package to unstable that is not targeted for testing means
> this package can no longer be updated via unstable but needs uploads via
> t-p-u. The release team asks package maintainers since a couple of
> releases to avoid this. It seems to me that you disagree with the RT
> here; could you please elaborate on that?

I'm not disagreeing with the release team on that. It's the current
situation and we have to live with it.

That does not mean we should not discuss other ways of dealing with
the release process if rolling was already existing.

> > It depends. The idea of rolling is also to alway allow pushing the latest
> > stable version out to users even during a freeze.
> >
> > For packages like dpkg it means we can continue pushing out new features
> > during the freeze and really maintain two branches in parallel.
> >
> > But this requires that testing stops relying on unstable during the
> > freeze to get fixes.
> 
> ...you want to get rid of this workflow.

I don't want that necessarily. I'm thinking out loud with you all to have
ideas of what could be done. Then we have to decide something.

> It seem to me that we disagree on this point: Should uploads to unstable
> always be targeted for the next release, even during freeze times? My
> answer is clearly 'yes'.

Why "clearly" ? If we want a usable release that contains fresh
software, we need a place where we upload packages that are supposed
to be of release quality. That place is unstable currently.

> What's the problem with uploading new features of dpkg to experimental
> ask users to install it on their systems that follow 'cut-rolling'? To
> me installing it by default will get you of course a much bigger
> testbed, but also sets users a much bigger risk of breaking their
> system. And the whole project was coined 'constantly *usable* testing'
> after all, no?

I don't follow you. The rolling release would continue to behave like
testing after the freeze. Only versions aged enough without new RC bugs
would migrate to it. Manually asking users to install is cumbersome and
doesn't bring enough testing (I tried several times and defects were only
found once the package hit unstable).

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

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