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 <ubu...@kitterman.com> wrote:
> Colin Watson <cjwat...@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@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
