LTS-to-LTS Cycle Freezes: Transitions

[Ted Gould]

On Mon, 2012-02-27 at 12:31 +0100, Matthias Klose wrote:
> 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.

What I'm suggesting is not that we would migrate all of the software
from technology A to technology B.  Instead, that we would consider the
software not adequately maintained if it did not migrate to technology B
in that amount of time.

Now, I would agree that anything that is a 9mo transition to hit an LTS
is too short.  This is a two year cycle.  I don't think we should use
this process for anything that isn't available *at least* at the
beginning of that cycle, and perhaps even a bit before that.

> 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?

I don't know the specifics here, but let's use python-dbus as a
contrived example.  Let's say that the python-dbus maintainers didn't
have the time or didn't want to migrate to Python 3.  Should we be
continuing to carry python-dbus or be encouraging Python developers to
use gdbus via the GObject Introspection bindings for it?  It's easy to
collect cruft like this, and use it as rationale to not move forward,
but we need to provide good recommendations for developers using our
platform.

> 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.

I think the benefits come entirely in maintenance.  For instance, in the
indicator stack we are maintaining GTK2 compatibility right now.  I hate
it, hate it, hate it.  After the LTS I am going to drop it, drop it,
drop it.  Again, I'm not saying we should commit to doing the conversion
ourselves, I'm saying we should remove packages that aren't converted.

> 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.

Besides the additions that I noted, I don't think this effects normal
in-cycle behavior.  Sure things will get added and removed.  This is
more for larger feature deprecations that really can't be done on the
shorter scale.

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

All I'm proposing here is the technical transitions.  But, I think that
we should start doing more things on an LTS-to-LTS basis.  Some poorly
thought out examples would be:

      * Policy changes.  For instance if we wanted to change the dpkg
        warning of a binary having a man page to an error.  This might
        be a good way to achieve that.
      * Testability.  Perhaps the QA and security teams would want to
        introduce some requirement that all packages have at least one
        unit test.
      * Documentation.  This might make sense to make major changes more
        on a two year cycle rather than a 6 month cycle.

Those would almost all require slightly different timelines and freeze
dates than what is proposed above, and are just examples of some things
that we could start thinking about on a 2 year cycle.

		--Ted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120227/b50966d7/attachment.pgp>