Follow Up from "Let's Discuss Interim Releases"

[Clint Byrum]

Excerpts from Thierry Carrez's message of 2013-03-11 03:12:45 -0700:
> Robert Collins wrote:
> > One thing I think has been missing from the discussion so far has been
> > in reviewing our *definition* of a release. There was some mention of
> > defining what Ubuntu is - how big the surface area we maintain, vs app
> > developers maintain and deliver /on/.
> > 
> > I'd like to decompose 'Release' though. Technically, it means a number
> > of things today:
> > A - an archive that we place a high friction change process on,
> > intended to eliminate regressions [the SRU]
> > B - a logical name that users can associate with a /large/ bundle of
> > changes. One can say 'Unity in Raring is fantastic' only because
> > Raring is a thing.
> > C - A set of APIs that work well together and which we commit to keep
> > working for the duration of the release (except where it is infeasible
> > [e.g. due to facebook dropping their support for the server side of an
> > API].
> > D - A mostly unchanging environment. No surprises.
> > [...]
> 
> Today, it's also [E] an install media.
> 

Not sure that is any different than B. "I installed using raring install
media". Or "I failed to install using raring install media". If you plan
for a changing core, the install media is just a vehicle to get on the
crazy train.

> > So, here is an alternative approach to solving these four things while
> > still integrating upstream changes etc.
> > 
> > tl;dr version:
> >  - Identify a really small set of APIs to support, and set LTS
> > timeframes on them. Examples - boot configuration, networking,
> > graphics, etc.
> >  - For new APIs set timeframes that reflect their maturity (and
> > support them for that timeframe).
> >  - Support those APIs for that timeframe irrespective of upstream -
> > but in selecting them discuss that with upstream.
> >  - Use feature flags to decouple 'new code release' from 'new
> > behaviour' for the platform itself - Unity, indicators etc.
> >  - For key upstream applications (e.g. using data from popcon) make
> > sure we allow co-installability of multiple versions. (libreoffice may
> > be an example of this).
> >  - Move the concept of using 'a release of Ubuntu' to using 'a
> > configuration' - LTS is 'keep my behaviour unchanged', interim
> > releases are 'give me new features when they are production quality'
> > and 'development edition' is 'give me new stuff as soon as it enters
> > the archive'.
> 
> About LTS mode ('keep my behaviour unchanged') I suspect every n years
> you'll have to create another LTS mode. For people who want their
> behaviour unchanged but from a reasonably modern starting point. How do
> you handle that ?
> 

I believe what Robert was advocating was just a configuration that does
not move behavior forward. So each LTS is a configuration that does not
move forward.  The LTS cut today is not special from the one cut tomorrow.

> >  - Stop doing fixed releases altogether.
> 
> Once we adopt the rest of your proposal, what would be the added cost of
> actually still doing "releases", that could serve as reference points in
> time and install media ?
> 

As you stated in your follow up, the more frozen states there are,
the more states the security team has to ensure work with the new
configuration/patched software.

> With a well-oiled release process, the cost is not high. And keeping
> that logical name to describe a point in time has benefits: reference
> install media, time-based cycle to focus development community, media
> attention, LTS mode starting point, easy way to describe a set of APIs
> and everything else you have in [B] above.
> 
> If you think of a "release" not in term of upgrade and maintenance but
> in terms of a development milestone and a breathing rhythm, I think the
> benefits outweigh the costs. And it's certainly compatible with the rest
> of your proposal.
> 

I see those benefits too. I think the cost of backporting fixes is what
has grown too high in proportion to the other costs. So if one can keep
moving the majority of software forward, and only have to backport fixes
to a minimal core, then releases of that core still do make sense.

I actually think this is already how many server/cloud users use Ubuntu
right now anyway. Run the LTS as your core, encapsulate your custom apps
in containers/virtualenvs/rvms/etc.