Shuttleworth: 2 year cadence for major releases: some progress

It's basically not affecting the general kernel development track much,
and the support as it is depends greatly on volunteers for the task, no
volunteers, no support, but in practice, that's what the long-term-stable-
kernel projects are supporting. Development in the general mainline
continues as normal, with the exception being that when a kernel community
member declares their intent to do a long term stable series for a
particular release, various big kernel projects might be sped up slightly
to target it, if they'd normally try to hit the next release, or delayed a
release if they're interim solutions not considered suitable for long term
support.

The idea of mainline supported long-term-stable kernels is reasonably new
as these things go, and there's only been two of them. I don't claim to
have followed the details even here at LWN, so part of this may be wrong,
but based on my takeaway from mostly LWN, the first one (2.6.16, IIRC)
came about sort of accidentally, as IIRC Red Hat realized toward the end
of the normal kernel stable period that they'd be maintaining it long term
for their own enterprise release anyway, and, as is common for them,
decided to play well with upstream, making it an official upstream
supported long-term-stable kernel, instead of a Red-Hat-Only kernel.

A new one was recently announced, tho I've not tracked it well enough to
be able to tell you the release number. This was a new volunteer for long
term maintainer for that kernel, and thus, given the informality with
which these things seem to be done in the kernel community, a slightly
different take on what would qualify for inclusion.

The important part in regard to our current context, however, is that I
believe multiple enterprise distributions have announced that they are
basing their upcoming releases around this kernel, /because/ it's an
official long-term-stable kernel, and, reading between the lines, there
was in fact some deliberate cooperation between them and the general
kernel community in terms of deciding which release it'd be and finding
someone to volunteer. IOW, unlike the first one which seemed to come
together informally based on someone taking the lead, this time around
there's some deliberate cooperation between distributions and coordination
with the larger kernel community toward that end, involved.

A logical projection into the future would be that #3 long-term-stable-
kernel release will happen in 2-3 years, and be even /more/ coordinated,
possibly even to the level of formal long-term-stable-kernel (LTSK)
guidelines being drawn up. Presumably the cycle will continue every 2-3
years after that, until something happens to dramatically change the
general kernel development pattern thus necessitating a change in the
LTSKs, or something equally big happens to the way enterprise
distributions and their kernels are developed, quite apart from the
regular kernel release cycle.

Of course, if LTSK maintainer volunteers fail to appear, that'd cut the
cycle short as well, but given the money involved in enterprise
distributions, I expect that volunteers (from the kernel project
perspective) will appear, even as they are paid employees of either some
enterprise distribution or another company (like Google), or possibly
taken on as a Linux Foundation Fellowship arrangement (thereby being more
formally distribution/corporation independent), for the support period.

The desktop environments have talked about regular releases, and the concept is essentially the same: If you want your app to be part of DE version X, you have a fixed ship date to work towards. Similarly for distros, if you want your DE shipped by packagers, you know what the release date is. The more distros that ship together the more real this date becomes. (And Mark has said he'll change Ubuntu's release dates if others will agree on a fixed one.)

Now, these DE/Distro release dates by necessity can't be the same - that's the not issue. New stuff takes time to stabilize and integrate. Distros can differentiate based on what they ship - stable or shiny, for instance. And "boutique" distros will still exist (perhaps even thrive) in this environment.

I clearly think it's a good idea, and don't think it contributes to the "homogenization" of Linux -- from the user level. In one sense it can make for a more uniform platform (and this is a good thing (ie: LSB)) but in another it forces distros to be more innovative to differentiate their products. It seems a win-win to me.

-jef