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

[Scott Kitterman]

Dmitry Shachnev <mitya57 at ubuntu.com> wrote:

>On Fri, Mar 1, 2013 at 11:08 AM, Stefano Rivera <stefanor at ubuntu.com>
>wrote:
>> Hi Scott (2013.03.01_06:55:18_+0200)
>>> > I fully agree, and this is not even limited to the kernel. There
>are
>>> > other kinds of "major transitions" like switching to a new X.org
>>> > server, preparing a new major Qt or GNOME release, new eglibc,
>etc. Or
>>> > we want to do a complex transition such as moving from ConsoleKit
>to
>>> > logind.
>>> >
>>> > For those we'll need temporary staging areas which are not put
>into
>>> > the RR yet until they get a sufficient amount of testing; these
>could
>>> > be "topic PPAs" which interested people would enable and develop
>in,
>>> > which get landed into the RR when everything is ready?
>>>
>>> For people or teams that are largely or entirely !canonical, this
>only works
>>> if all you care about is x86 (i386/amd64).  Anything for armhf (or
>powerpc)
>>> would have to land untested since the PPAs that are available for
>!canonical
>>> don't build these architectures.
>>
>> It feels like an -experimental pocket would be the best solution
>here.
>> Which we would try to keep small, but could stage major transitions
>in.
>>
>> SR
>
>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.
>
>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;
>- 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;
>- Create and use -experimental pocket (as suggested by Stefano) for
>testing unstable changes and handling transitions;
>- Maybe it'll make sense to freeze the archive for a couple of days
>before every monthly snapshot (like we did for beta releases).
>
>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.

Backports aren't suitable for sustaining newer versions of things like KDE. The libs are too far broadly used to properly test.  I'd expect other DEs to be similar. 

Scott K