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
--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
