Let's Discuss Interim Releases (and a Rolling Release)

[Colin Watson]

On Fri, Mar 01, 2013 at 07:37:34PM +0400, Dmitry Shachnev wrote:
> We must decide whether the rolling branch is for users/enthusiasts or
> for developers only. If the latter (it's what most of us like), we are
> *not* switching to rolling release model. We are just dropping non-LTS
> releases.

If it's for developers only then I would account that a failure.  It is
necessary to open it up rather more widely than that if we stop
providing non-LTS releases.

> In both cases, we should try to make it more stable than the current
> raring is. My suggestions are:
> 
> - Auto-sync packages from Debian testing, not sid;

Please no.  Now that we have -proposed to release migration, we're
guarded against the worst excesses of unstable.  Past experience has
suggested that the main effect of autosyncing from testing is to make it
take longer for regressions to get fixed, or else make us spend more
time chasing down regressions fixed in unstable but not in testing.

> - Make -proposed → -release migration more clever (i.e. recursively
> building all reverse dependencies, and running their autopkgtests, if
> any) — not sure if it is already done;

This is planned and partially implemented.  I'd hoped to finish it off a
couple of months ago but got a bit stuck; it'll clearly need to happen.

> - Create and use -experimental pocket (as suggested by Stefano) for
> testing unstable changes and handling transitions;

I can understand why people ask for this, but new pockets are very
complex to create due to extensive hardcoding of pocket semantics in
Launchpad; they aren't something we can do easily or flexibly.  Plus, if
we create one new experimental pocket, what happens when different
people's in-progress projects clash?  I foresee trouble with this
strategy.

I wonder whether we could petition for the Canonical-only restrictions
on devirtualised PPAs to be lifted for people in ~ubuntu-dev as a
consequence of this release plan, and what other changes that would
take.

> Also, if we are dropping non-LTS releases, we should make more use of
> -backports. Some flavours ({K,L,X}ubuntu) may use it for providing the
> latest stable versions of their desktops for LTS users, and other apps
> that are not part of DE (from the USC top: Vlc, Clementine, Lightread)
> should also be updated there. Core stuff like
> GCC/Python/Glib/Gtk/kernel shouldn't be touched of course.

Serious question: why is GTK+ materially different from the core KDE
libraries, which typically seem to be updated (even if only by minor
releases) as part of KDE version bumps?

-- 
Colin Watson                                       [cjwatson at ubuntu.com]