-----BEGIN PGP SIGNED MESSAGE----- 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. Rick Spencer wrote on 28/02/13 15:31: > ... > > = Role of the LTS Releases = > > Many users prefer their OS does not change very often. We have a > great system in place for these users. Every 2 years Ubuntu > release an LTS and users can ride that LTS for the whole support > period. Since the LTS comes out every 2 years, they can set a 2 > year cadence of updates if they want to stay "up to date" with LTS > releases. I think this 2 year cadence works out very well for > these users. So, this proposal maintains those LTS releases as > anchors for those users. LTS-to-LTS upgrades are tested, and documented, much less than they would be if they were the only type of end-user upgrade. For that reason alone, having LTS-only releases would be a good thing. > ... > > * Many community members recommend only LTS releases to new users > because of its longevity and stability, but the interim releases > cause confusion about what is the “right” version for someone to > install. For evidence of that, you need only look at <http://www.ubuntu.com/download/desktop>. "The latest features", or "long-term support"? That's a question people can't reasonably be expected to know the answer to. It's a choice they should not have to make. > * 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. > ... > > 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? I don't understand why you are proposing monthly snapshots at all. Can you elaborate? > That means users could choose: > > * The LTS release > > * The rolling release updated daily or as frequently as desired > > * The rolling release updated at least monthly For example, what is the difference between "daily or as frequently as desired" and "at least monthly"? Why have both? > = Benefits of Moving to a Rolling Release = > > A rolling release instead of interim releases will benefit users, > community members, and developers. > > == For Users == > > Users who prefer the LTS releases will be unaffected by this > change, at least directly. For users who prefer more up to date > software, the rolling release will truly provide the latest and > greatest software that they are looking for, but without the 6 > month wait for a new release. Developers won’t be under pressure > to rush a feature in before the release deadline, so users will be > receiving more complete software when they do get updates. That would leave, unmeliorated, the biggest problem for users: that, as you said, "the interim releases cause confusion about what is the 'right' version for someone to install". 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. Instead, I suggest that the rolling release be clearly targeted only at Ubuntu contributors. At developers, testers, translators, but not end users. Not shown on the download page, not "supported" in any sense, and not listed anywhere except cdimage.ubuntu.com or its successor. > == For Community == > > The community will benefit from the simplified model. They will be > able to recommend either the LTS or the rolling release, and the > users of each will be clear. People who need to provide support may > find their lives dramatically simplified, because on any one day, > there will essentially be 2 releases with clearly differentiated > user bases instead of their user base being distributed across a > minimum of 3 supported releases. For example, on any one day, an > ISV typically would only have to worry about the LTS releases and > the current rolling release, instead of 11.10, 12.04, 12.10 and the > current development releases, Raring. Another reason end users should not be offered rolling releases is that they would be a bad platform for ISVs. During the Ubuntu 12.10 development cycle, the messaging menu API changed for architectural reasons. Every application using it broke, but that wasn't so bad -- because end users weren't using it, OS developers expect things to break, and most of those applications were fixed before the 12.10 release. But if that change had happened during a rolling release used by end users, either end users would have experienced the breakage, or we would have had to pay the cost of reimplementing the old API alongside the new one. That would be a cost our competitors do not pay -- or pay only because they benefit from vastly more and older third-party applications than we do. That is not an isolated case. There have been similar API changes for application indicator menus, for Unity lenses and scopes, and probably for subsystems I've never even heard of. With an end-user rolling release, if you installed OS updates overnight, an application you had paid money for could stop working while you slept. The attractiveness of a platform to ISVs depends, among other things, on the homogeneity of versions amongst the user base. Right now, of PCs running Ubuntu 12.04 or later, 54.6 % are running 12.04 LTS, 44.9 % are running 12.10, and 0.5 % are running R. As far as ISVs are concerned, that's pretty close to the worst possible fragmentation of just those two releases. But at least 12.10 is a stable target! Now imagine that 12.10 didn't exist. Our success as a platform would depend on how much of that 44.9 % were instead using 12.04, a stable target, rather than R. That's why we need to be as clear as possible that the rolling release is for contributors only. > ... > > == 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. Cheers - -- mpt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEvusAACgkQ6PUxNfU6ecq0FwCgkPR1QKbgNCl41S+hHAr2PlzW NlcAmwTJFDLKilvPy+85hr8xTldDjjYb =3yCV -----END PGP SIGNATURE----- -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
