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

Dmitry Shachnev mitya57 at ubuntu.com
Fri Mar 1 15:37:34 UTC 2013

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

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.

Dmitry Shachnev

More information about the ubuntu-devel mailing list