<div dir="ltr">Hi mpt,<br><br>A lot of points in here. Some follow up thoughts ...<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 28, 2013 at 12:14 PM, Matthew Paul Thomas <span dir="ltr"><<a href="mailto:mpt@canonical.com" target="_blank">mpt@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
The six-monthly Ubuntu release cycle is exciting for Ubuntu fans, KDE<br>
fans, and (lesserly) Gnome fans ... and awful for pretty much everyone<br>
else.<br>
<br>
It's awful for first-time users trying to choose a version, for ISVs,<br>
for OEMs and ODMs, for people who write and run training programs, for<br>
Ubuntu-related book authors, publishers, and sellers, for people<br>
providing tech support, and for Ubuntu developers themselves trying to<br>
release features in a finished state. Little wonder that some of those<br>
groups ignore non-LTS releases altogether.<br>
<br>
So, I'm all in favor of having two-yearly releases. But for the same<br>
reasons as six-monthly releases are bad, monthly snapshots and/or a<br>
rolling release would be much worse -- unless we are careful to<br>
communicate that they are for contributors only, not for end users or<br>
ISVs.<br></blockquote><div>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 "contributors".<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Rick Spencer wrote on 28/02/13 15:31:<br>
<br>
> * As Scott James Remnant pointed out some time ago, the six month<br>
> cadence causes features to be either rushed, or to have to wait<br>
> for six months to be released (along with other problems).<br>
> (<a href="http://netsplit.com/2011/09/08/new-ubuntu-release-process/" target="_blank">http://netsplit.com/2011/09/08/new-ubuntu-release-process/</a>)<br>
<br>
LTS-only releases would not solve that problem, but they would reduce<br>
the problem by about 75 percent (three releases out of four).<br>
<br>
Less time spent on the release process itself would also allow<br>
more time for actual development. But on the other hand, the urge to get<br>
features and other major changes into an LTS would be even more<br>
frantic and rule-bending than it is for every release now. There would<br>
be no post-LTS interim release as a consolation prize, and two years<br>
is a long wait.<br></blockquote><div>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.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> ...<br>
><br>
> More clearly, I think we should:<br>
><br>
> * Stop making interim releases.<br>
><br>
> * Keep doing daily quality and keep improving our daily quality.<br>
><br>
> * Take a monthly snapshot of the development release, which we<br>
> support only until the next snapshot<br>
<br>
For software, the word "support" is incurably vague and best avoided.<br>
What do you mean? Security updates? Backports? Tech support from<br>
Canonical? A section on <a href="http://help.ubuntu.com" target="_blank">help.ubuntu.com</a>? A listing on<br>
<a href="http://friendly.ubuntu.com" target="_blank">friendly.ubuntu.com</a>? Repackaging of commercial applications in Ubuntu<br>
Software Center?<br></blockquote><div>In this context "support" refers to security support and possible fixing the gravest issues.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I don't understand why you are proposing monthly snapshots at all. Can<br>
you elaborate?<br></blockquote><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
A download page that offers a choice between the LTS and a rolling<br>
release would be exactly as horrid as one that offers the choice<br>
between the LTS and a six-monthly release.<br></blockquote><div>I would expect the stock download page to *only* point to the last LTS.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> ...<br>
><br>
> == Because we Can ==<br>
><br>
> Daily Quality means that developers can ensure their components are<br>
> stable and useful before they upload, and our processes protect us<br>
> from most mistakes these days. The result is that 13.04 has been as<br>
> robust a release over the last many weeks as 12.10 was when we<br>
> delivered. We have achieved rolling release quality in our<br>
> development practices, so we can capitalize on this capability<br>
> now.<br>
<br>
Comparing with 12.10 is an easy target: 12.10, even after hundreds of<br>
SRUs, is roughly 20 to 40 percent crashier than 12.04.<br>
<br>
Even then, your statement is true only if you change "the last many<br>
weeks" to "yesterday". It was only yesterday that R's error rate came<br>
close to 12.10's -- for both, about 0.07 errors per reporting machine<br>
per calendar day. For most of the past month, R has been much<br>
crashier: between 0.10 and 0.15. <<a href="https://errors.ubuntu.com/" target="_blank">https://errors.ubuntu.com/</a>><br>
<br>
So if there is a plan to make daily Ubuntu versions as stable as<br>
interim releases, it has yet to be demonstrated.<br></blockquote><div><br>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. <br>
<br></div><div>Cheers, Rick<br></div></div></div></div>