On Saturday, March 02, 2013 09:34:22 AM Dmitry Shachnev wrote: top post fixed. > 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. > > 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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
