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

[Scott Kitterman]

On Saturday, March 02, 2013 09:34:22 AM Dmitry Shachnev wrote:
top post fixed.
> On 3/2/13, Scott Kitterman <ubuntu at kitterman.com> wrote:
> > Colin Watson <cjwatson at ubuntu.com> wrote:
> >>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?
> >>
> > I wouldn't backport a major release of KDE libs or Qt.  We tried
> > backporting Qt4 for Hardy and it didn't go well.  These libs are,  IMO,
> > used by far to many applications for backports of major versions to be
> > safe.  I'd be surprised to find I felt differently about gtk2/3 if I
> > looked into in detail.
>
> OK, if we can't backport full KDE / GNOME, we can at least backport
> some individual apps (that don't depend on new versions of libraries).
> I don't know about KDE, but in GNOME lots of apps look backportable
> (for example, there are already some parts of GNOME 3.7 in raring,
> which is based while core components are at 3.6).
> 
You certainly could, but that couldn't provide an equivalent user experience 
for users of the complete new release.  I don't know what the right answer is 
for how to achieve the goal, but I think LTS + flavor specific package updates 
is an attractive release model.

Scott K