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