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 <[email protected]> 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 <[email protected]> wrote: >> Colin Watson <[email protected]> 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 >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel >> > -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
