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

[Dmitry Shachnev]

I meant "there are already some apps from GNOME 3.7 in raring, while
core GNOME components are at 3.6".

--
Dmitry Shachnev

On 3/2/13, Dmitry Shachnev <mitya57 at ubuntu.com> wrote:
> 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).
>
> --
> Dmitry Shachnev
>
> 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.
>>
>> Scott K
>>
>>
>> --
>> ubuntu-devel mailing list
>> ubuntu-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>>
>