Updated release management straw man for TB consideration

[Soren Hansen]

2013/3/12 Mark Shuttleworth <mark at ubuntu.com>:
> Am writing to ask you to weigh in on an updated release management
> proposal.  Details are on Planet Ubuntu, salient portion of the
> proposal is:

Thanks for raising these points here, Mark.

> optional newer versions of major, fast-moving and important platform
> components. For example, during the life of 12.04 LTS we are providing
> as optional updates newer versions of OpenStack, so it is always
> possible to deploy 12.04 LTS with the latest OpenStack in a supported
> configuration, and upgrade to newer versions of OpenStack in existing
> clouds without upgrading from 12.04 LTS itself.

People have generally suggested that using PPAs for this is the right
path forward. However, this is not how it's done with the updated
OpenStack packages. I would love to hear from the server team about the
rationale for this and whether -- after having used the process for
around a year now, IIRC -- they find that the benefits outweigh the cost
of divergence. That should give us better grounds for working out if
1) using PPAs really is perfectly sufficient or 2) if we should look
into improving PPAs to make it so or perhaps 3) make the system used for
the OpenStack packages available to maintainers of other software
stacks.

> 2. Reducing the amount of release management, and duration of support, for
> interim releases.
> Very few end users depend on 18 months support for interim releases. The
> proposal is to reduce the support for interim releases to 7 months, thereby
> providing constant support for those who stay on the latest interim release,
> or any supported LTS releases.

Like most everyone else, I feel that 7 months is a bit on the aggressive
side and that 8 months would be more appropriate. I'd be perfectly happy
with that, too.

> Our working assumption is that the latest interim release is used by folks
> who will be involved, even if tangentially, in the making of Ubuntu, and LTS
> releases will be used by those who purely consume it.

Do we have any data to support this or is it a gut feeling?

> 3. Designating the tip of development as a Rolling Release.
> Building on current Daily Quality practices, to make the tip of the
> development release generally useful as a ‘daily driver’ for developers who
> want to track Ubuntu progress without taking significant risk with their
> primary laptop. We would ask the TB to evaluate whether it’s worth changing
> our archive naming and management conventions so that one release, say
> ‘raring’, stays the tip release so that there is no need to ‘upgrade’ when
> releases are actually published. We would encourage PPA developers to target
> the edge release, so that we don’t fragment the ‘extras’ collection across
> interim releases.

The best policy years ago may not be the best policy now (and vice versa), so
I'm totally ready to explore this suggestion. I'm having trouble visualising
how this would work in practice, though.

Specifically, it's not clear to me what the relationship is between the rolling
release and the LTS release (for the sake of this argument I'm assuming that
the non-LTS releases are no more). Do you see the LTS release a simple snapshot
of what's in the rolling release? If not, how will they be split?

-- 
Soren Hansen             | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer         | http://www.ubuntu.com/
OpenStack Developer      | http://www.openstack.org/