[cut-team] Ideas for the rolling release

[Anthony Towns]

On Mon, Aug 16, 2010 at 06:38, Lucas Nussbaum <lucas at lucas-nussbaum.net> wrote:
> Also, I don't think that we need to determine precise criterias or
> policies for when we will fast-track migrations or when to do direct
> uploads to rolling through rolling-proposed-updates. As long as we agree
> on the goal we have for rolling, it should be easy for the team in
> charge to determine when/how to do fast-tracking on a case-by-case basis.

I think it's important to get some precision in there though; it would
be very interesting (IMO) to track people's ideas of what they think
should be in "rolling" that isn't already in "testing", and look into
why it isn't in testing.

Examples so far:

    chromium-broswer -- involved in icu transition, which release team
hasn't hinted
    wesnoth -- RC bug blocking wesnoth 1.6, pending wesnoth 1.8 upload
    gcc-4.5 -- in experimental only
    ffmpeg 0.6 -- in experimental only
    linux-2.6 2.6.35 -- in experimental only

Perhaps it would be interesting to look at this from the other
perspective: "testing" should be constantly usable, but only expected
to be supported for 3-6 months, which might not be sufficient for a
"stable" release (with a ~2 year support timeframe). For packages that
have new versions suitable for testing but not the upcoming stable
(such as linux 2.6.34, eg), these packages should be "blocked" somehow
by the release team for their stable candidate, but not for unstable
or testing. Taking xorg-server as another example, that might mean
something like:

    2009/10/01 1.7.0 released upstream
    2009/10/04 1.7.0-1 uploaded to experimental
    ...
    2010/01/06 1.7.3.902-1 uploaded to unstable
    ...
    2010/03/30 1.7.6-2 uploaded to unstable
    2010/04/02 1.8.0 released upstream
    2010/05/12 1.8.1-1 uploaded to experimental

*** Xorg maintainers and release team decide to target 1.7 for stable
*** xorg-server 1.7.6-2 gets copied from testing to "frozen" suite
*** xorg-server 1.8 gets uploaded to unstable, migrates to testing, etc
*** xorg-server 1.7.6.901-{1,2,3}, 1.7.7-{1,2,3} get uploaded to frozen directly

*** next stable release is composed of frozen + testing packages

That scenario only works if you "freeze" all the packages that will
end up with >= versioned dependencies as well. For xorg-server that's
probably reasonable, for libx11 it's probably not (libx11 1.3.4 and
1.3.5 haven't been uploaded to unstable or experimental as of yet,
afaics).

It would mean users would need to choose amongst:

    stable -- supported for ~2 years, barely changes
    testing + frozen -- supported for 3-6 months, but everything is
expected to be supportable for 2 years; can upgrade to next stable
release
    testing -- supported for 3-6 months, some packages may be newer
than next stable release
    unstable -- supported for ~6 hours
    experimental -- not supported

which might be plausible: you'd prefer experimental over unstable over
testing over testing+frozen over stable because you get newer
packages; while support goes the other way: stable doesn't require an
upgrade for up to two years, testing+frozen needs to be updated at
most every 3-6 months and can be upgraded to the next stable release,
testing avoids RC bugs from unstable, and unstable avoids maintainer's
test packages from experimental.

It would also make it plausible to unfreeze packages if desired (in
April we're sure xserver-xorg 1.7 will be okay for squeeze, but we
have doubts about 1.8; in September, maybe we decide 1.8 will be okay,
so we just drop 1.7 from frozen, and instantly have 1.8 from testing
for everyone who cares).

I'm not sure the release team would be satisfied with not being able
to encourage maintainers to freeze library packages in unstable,
though.

I'm not sure that we've got the infrastructure to support maintaining
five different versions of packages (stable, frozen, testing, RC
buggy, experimental), plus the update paths for them
(stable-proposed-updates, frozen-proposed-updates at a minimum,
potentially testing-proposed-updates as well) -- there's the archive,
the BTS, and the buildds that would need to cope with that, beyond
just users/maintainers/release team being able to understand it all.

"frozen+testing" doesn't provide a way to deal with packages that are
to be excluded from stable rather than frozen, but which are fine for
testing -- such as wesnoth 1.6, or maybe some volatile packages
(though afaics all the current volatile packages have a version in
stable anyway).

Cheers,
aj

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