LTS-to-LTS Cycle Freezes: Transitions

[Matthias Klose]

On 25.02.2012 19:10, 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).

this is a lot of wishful thinking ... and from my point of view not very realistic.

Consider the OpenJDK to use for an LTS.  We planned for 7, but didn't have the 
resources to convert everything to 7.  This was planned for two release cycles, 
but if OpenJDK7 is only released nine months before the LTS, then it's even 
difficult for an upstream project to have a release out, which works with 7, and 
can land into the LTS.  Note that we will have the same issue again with OpenJDK 
8 (to be released in late 2013).  I am not saying that it is not doable, but it 
would require a man year or more to get this done in such a short time frame 
(ask James Page what he did spend for the 6 to 7 changes).

Your assumption that the new technology is already available two years before an 
LTS is wrong in this case.

There is no Python 2.x to Python 3 transition.  Even for the next LTS python 2.x 
will be kept in main, because third party modules building for both python2 and 
3 will build from the very same source package.  Getting Python3 only on the ISO 
images is a goal (was again just removed from the images), but it requires 
porting of upstream software to Python3 which is not yet ported upstream.  This 
is not different for our own software like apport ...  Barry did do the 
python3-dbus port, which did require at least a man month.  So again, it is 
slowly done, but resources are limited.  How many python scripts do you still 
write using python2.x?

For new toolchain versions there is already a process.  Here, it is again a 
resource issue to get the build failures fixed within one release cycle.

I cannot see the benefits of converting to 100% to a new "technology", if you 
have to put in a lot more resources into the conversion having to do the 
upstream port yourself.

While you describe the LTS to LTS cycle, you don't say anything about the six 
month cycles, and what users should expect for an in-between LTS release.

So I am very sceptical about such plans for technology transitions.  What else 
are you planning to use this process for?

   Matthias