LTS-to-LTS Cycle Freezes: Transitions
ted at ubuntu.com
Sat Feb 25 18:10:02 UTC 2012
As we're hitting beta freeze for this LTS I think it's a good time to
talk about something that gets discussed from time to time, but we
should commit to for this round of the meta-cycle. That is quite simply
having a process for things that aren't in the 6m release cycle, but
instead on the LTS meta-cycle. Obviously this can't be decided on this
mailing list, it'll require a UDS discussion and tech board approval,
but I think it's good to start here.
As an concrete example of something that could be done on this meta
cycle I think we should start talking about technology transitions.
Things that we don't want to carry, or transitions that we want to
encourage. And also things that we're willing to take the pain of
dealing with, either by dropping packages we love or by committing
development effort to that transition. I image many of these will be
hard for various communities. But, I think this is part of Ubuntu's
charter of making opinionated choices for continued inclusion.
Here is what I'm proposing as a schedule for a transition:
LTS + 1: No MIRs approved using the old tech
LTS + 2: Old tech not allowed in main, packages demoted at FF
LTS + 3: Only bug fixes allowed to packages, no syncs, no updates
except to migrate to the new tech.
LTS + 4: Packages dropped at FF that use the old tech
^ Probably the next LTS
For the Precise + 1LTS release I'll start to propose the following
Python 2.x -> Python 3
GConf -> GSettings
GTK2 -> GTK3
Qt4 -> Qt5
I think there should be an exception process that would get release team
approval like a standard freeze. But, in general, this should be
discouraged (like all freeze exceptions are).
Any suggestions before I try to formalize this further?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the ubuntu-devel