Avoiding fragmentation with a rolling release

Rick Spencer rick.spencer at canonical.com
Thu Feb 28 20:41:01 UTC 2013

Hi mpt,

A lot of points in here. Some follow up thoughts ...

On Thu, Feb 28, 2013 at 12:14 PM, Matthew Paul Thomas <mpt at canonical.com>wrote:

> Hash: SHA1
> The six-monthly Ubuntu release cycle is exciting for Ubuntu fans, KDE
> fans, and (lesserly) Gnome fans ... and awful for pretty much everyone
> else.
> It's awful for first-time users trying to choose a version, for ISVs,
> for OEMs and ODMs, for people who write and run training programs, for
> Ubuntu-related book authors, publishers, and sellers, for people
> providing tech support, and for Ubuntu developers themselves trying to
> release features in a finished state. Little wonder that some of those
> groups ignore non-LTS releases altogether.
> So, I'm all in favor of having two-yearly releases. But for the same
> reasons as six-monthly releases are bad, monthly snapshots and/or a
> rolling release would be much worse -- unless we are careful to
> communicate that they are for contributors only, not for end users or
> ISVs.
I would put "enthusiasts" in the category of potential users. There are
people who will set the dial to much fresher software if they can, even if
it comes with costs and even if they don't consider themselves

> Rick Spencer wrote on 28/02/13 15:31:
> > * As Scott James Remnant pointed out some time ago, the six month
> > cadence causes features to be either rushed, or to have to wait
> > for six months to be released (along with other problems).
> > (http://netsplit.com/2011/09/08/new-ubuntu-release-process/)
> LTS-only releases would not solve that problem, but they would reduce
> the problem by about 75 percent (three releases out of four).
> Less time spent on the release process itself would also allow
> more time for actual development. But on the other hand, the urge to get
> features and other major changes into an LTS would be even more
> frantic and rule-bending than it is for every release now. There would
> be no post-LTS interim release as a consolation prize, and two years
> is a long wait.
I agree this is a risk that we need to carefully managed. We already have
faced this with every LTS, in fact. I am not certain that changing to a
rolling releases changes the dynamic much, but the next *big* release is 2
years away could cause some additional pressure that we we'll need to take
extra steps to guard against.

> > ...
> >
> > More clearly, I think we should:
> >
> > * Stop making interim releases.
> >
> > * Keep doing daily quality and keep improving our daily quality.
> >
> > * Take a monthly snapshot of the development release, which we
> > support only until the next snapshot
> For software, the word "support" is incurably vague and best avoided.
> What do you mean? Security updates? Backports? Tech support from
> Canonical? A section on help.ubuntu.com? A listing on
> friendly.ubuntu.com? Repackaging of commercial applications in Ubuntu
> Software Center?
In this context "support" refers to security support and possible fixing
the gravest issues.

> I don't understand why you are proposing monthly snapshots at all. Can
> you elaborate?
The monthly snapshots would be for users who want the fresh software, but
don't want to manage the daily grind of updating to ensure that their
system is secure. The way I think of it is that we "support" 2 cadences for
updates, daily and monthly.

> A download page that offers a choice between the LTS and a rolling
> release would be exactly as horrid as one that offers the choice
> between the LTS and a six-monthly release.
I would expect the stock download page to *only* point to the last LTS.

> > ...
> >
> > == Because we Can ==
> >
> > Daily Quality means that developers can ensure their components are
> > stable and useful before they upload, and our processes protect us
> > from most mistakes these days. The result is that 13.04 has been as
> > robust a release over the last many weeks as 12.10 was when we
> > delivered. We have achieved rolling release quality in our
> > development practices, so we can capitalize on this capability
> > now.
> Comparing with 12.10 is an easy target: 12.10, even after hundreds of
> SRUs, is roughly 20 to 40 percent crashier than 12.04.
> Even then, your statement is true only if you change "the last many
> weeks" to "yesterday". It was only yesterday that R's error rate came
> close to 12.10's -- for both, about 0.07 errors per reporting machine
> per calendar day. For most of the past month, R has been much
> crashier: between 0.10 and 0.15. <https://errors.ubuntu.com/>
> So if there is a plan to make daily Ubuntu versions as stable as
> interim releases, it has yet to be demonstrated.

I think that crash reports is a useful and valid measure of robustness, and
your measures do point to the fact that Quality is journey, not a
destination. We should certainly continue to focus on decreasing crashes,
increasing performance, increasing security, etc... all the things that
make software robust for users.

Cheers, Rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130228/bcabdd26/attachment.html>

More information about the ubuntu-devel mailing list