Strawman: Change the Ubuntu Release Cycle

[Emmet Hikory]

On Dec 31, 2007 8:59 AM, Evan wrote:
> While I generally like the current Ubuntu release cycle, I find it has a few
> problems:
>
> Forcing LTS users to make do with software that is 2 or 3 major versions
> out-of-date is just wrong. I understand that the focus is on stable software
> rather than cutting-edge, but some of the stuff in 6.06 is just plain
> obsolete, forcing people to upgrade to a non-LTS to get programs that do
> what they need.

    In large environments, it is not rare to take six months to a year
to roll out significant application updates when changes in
functionality are expected.  This time is composed of testing,
updating local and custom applications, training of support personnel,
and staged deployment so that any regressions can be discovered before
they impact critical operations.  An new release every two years is
about right for this cycle, as it allows major software upgrades to be
under consideration only one-half to one-quarter of the time, with
other time spent focused on other environmental changes.

    In such environments, the deployed software is known to "do what
[users] need" at the time of the deployment, and these needs are
unlikely to change much, as most interaction is with word processing,
presentation, spreadsheet, and bespoke software, where the bespoke
software is constructed to be compatible with the deployed
environment.  Significant updates to common applications such as
OpenOffice.org or FireFox would change the operating environment
sufficiently to possibly require modification or redevelopment of the
bespoke applications, significantly impacting the ability of the
development group to produce new functionality to meet user goals.

> I find that the 6 months between major releases is just a touch too short
> for the developers to make significant changes and do a proper test cycle.
> Their are no 'service pack cds' meaning that any bug which makes it into the
> final release stays there forever. This has led to what is basically a
> never-ending early adopters penalty.

    This is a good point.  Having an update CD as iso released,
including all traffic to -updates, in the last six months would
perhaps have value.  On the other hand, most environments that are
organised in such a manner to require LTS support are very likely to
have at least limited internet access, and maintaining a local mirror
with updates, and constructing local installation CDs from that mirror
ought not be a significant effort.

> Here's my proposal. While it isn't perfect, I think it fixes the issues
> mentioned above.
>
> Every six months, coinciding with the current releases, put out a 'service
> pack' for the current LTS. This service pack will include:
>
> All normal updates previously released.
> A selective upstream merge. Core, (and breakable) components such as X and
> the kernel remain unchanged, but normal apps (especially ones that are
> 'user-visible' such as Firefox) get updated.
> A new cd image with all of the above changes.

    Users who "need" updated "user-visible" applications are likely
best served by one of: following the normal release cycle, using the
-backports repository (perhaps selectively), or applying "required"
updates to a local mirror for the local environment.  Admittedly,
currently creating an updated installation CD is less than trivial,
but that is a smaller problem to resolve.

> More features, less testing for non-LTS releases and vice-versa.
> Add a note that the non-LTS are 'stable for everyday use except where 100%
> uptime is required' or something along those lines.

    I'm unsure from where the "more features" would be sourced.
Already there are coordination issues with the rate of feature
introduction, and many transitions to new features take two or more
releases to implement correctly in affected packages.  Increasing the
feature volume while decreasing the integration effort would likely
further delay these transitions, significantly reducing the
integration of the releases for normal use.  Given that the current
development cycle consists of 2 weeks planning, 15 weeks of feature
updates & integration, 6 weeks of integration, and 3 weeks of final
testing, it seems that any further reduction in the timeframes would
likely lead to a somewhat unstable final product, and would not meet
the "stable for everyday use except where 100% uptime is required"
goal.

    More generally, those who have the flexibility to upgrade every
six months are encouraged to use the regular releases.  Those who
cannot due to organisational issues related to very large deployments
rely on the LTS releases remaining feature-compatible over the
existing lifecycle, and would not be well served by the change.

-- 
Emmet HIKORY