LTS-to-LTS Cycle Freezes: Transitions

[Scott Kitterman]

On Saturday, February 25, 2012 01:42:51 PM Ted Gould wrote:
> On Sat, 2012-02-25 at 13:53 -0500, Scott Kitterman wrote:
> > On Saturday, February 25, 2012 12:10:02 PM Ted Gould wrote:
> > > 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
> > > 
> > > transitions:
> > >   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?
> > 
> > Since Qt5 isn't even released yet, I think that may be premature.
> 
> Sure.  I guess the reason I put that in is that my understanding is that
> the transition for applications isn't very difficult.  But, I have no
> first hand experience there.  I would expect individual deprecations to
> be approved by the Tech Board, these were meant more as guidance to what
> I was thinking.
> 
> > In any case Main/Universe is really an internal Canonical issue.  It's
> > not one the community can really weigh in on.
> 
> Hmm, my understanding was that it was something in the Ubuntu policies
> and procedures.  I think it does effect things like derivatives, no?
> Anyone on the RT can approve MIRs, right?

No, there's a separate MIR approval team for that.  After Precise none of the 
other flavors will be in Main, so it won't matter.  For Precise and earlier 
Kubuntu would be affected, but it's status is changing, so it's only 
Ubuntu/Ubuntu Server that are at issue.

> Regardless of whether it's a Canonical thing or not, I think it's a good
> way to express a general transition away from a particular technology
> without just flat removing it without any notice at a particular point.
> But, if that's the only sticking point, I'll be pretty thrilled :-)

I like the idea of having a general roadmap of where we're going, but in many 
cases we have to follow upstreams and it's not like we have a great deal of 
control.

Kubuntu will use Qt5 when KDE ships a Qt5 based version, so it's on their 
timeline, not ours.  Similarly Python 3.  While we can port distro specific 
code to Python 3 (and I think it's an excellent idea), we can only go so far 
in porting external packages before the maintenance burden gets to be too 
much.

We also have to deal with issues like LSB requirements (which we may or may 
not decide we care about) when determining when to get rid of stuff (for 
example the current LSG release still requires Qt3 even though it's been dead 
upstream for years).

Scott K