With the nomination period beginning for the Ubuntu Technical Board, big changes like Unity having arrived in Ubuntu recently, and the upcoming UDS for being what will likely be a new LTS release of Ubuntu, it’s as good as time as any to ask big questions about the development process, challenge assumptions, and make suggestions for big changes.
Cadence
The Ubuntu release process is well known, and its developers talk regularly about the cadence of it. A new release of Ubuntu comes out every six months, and each release follows a predictable pattern. I’ve stolen the following image from OMG! Ubuntu’s recent series about Ubuntu Development.
Each developer working on Ubuntu follows this cycle. When Ubuntu 11.10 is released on October 13th, they’ll begin again. After they recover, of course.
First there’ll be a bit of a wait for the archive to be open, this gets quicker and quicker each release but since it depends on a toolchain being built and other similarly fundamental things, it tends to be a period where most people figure out what they’re going to discuss at UDS.
UDS is a bit late for the 12.04 cycle, so the merge period will probably occupy developer time both before and after UDS. This isn’t represented on Daniel’s chart above, but this is the time when massive amounts of updates arrive from Debian; it’s a time of great instability for Ubuntu. At some point there will be an Alpha 1, but you won’t want to try and install that.
Planning for UDS is going to take up some time, and writing up the results of the plans afterwards and turning that into work items. There’s also a UDS Hangover which nobody (except Robbie Williamson, when drafting the 10.10 Release Cycle) seems to like to talk about. Nothing gets done in the week or two following UDS, everybody is too wiped out.
So realistically speaking, development of features for 12.04 is going to start around mid-November at the earliest. And by features I mean the big headline things in Ubuntu; like Unity, like the Software Center, like the Installer. These things are important to get right.
Pretending for a moment that features are developed over the winter holidays like Thanksgiving, Christmas and New Year, you’ve got clear development time until Feature Freeze. The 12.04 Release Schedule isn’t published yet, but I figure that’s going to be somewhere around February 16th after which everyone switches to bug fixing and release testing.
That’s just 13 weeks of development time!
Chaos
So you’re an Ubuntu developer working on features for the upcoming release, you don’t have anywhere near as much time as you’d expect to actually do the development work. What happens if you’re replacing something that works with something completely new? Can’t you just target a later release, and work continually until the feature freeze of that release?
It turns out that you can’t. There is an incredible emphasis on the Ubuntu planning process of targeting features for particular releases. This is the exact thing you’re not supposed to do with a time-based release schedule.
Unfortunately Canonical’s own performance-review and management is also based around this schedule. The Ubuntu developers so employed (the vast majority) have such fundamentals as their pay, bonuses, etc. dictated by how many of their assigned features and work items are into the release by feature freeze. It’s not the only requirement, but it’s the biggest one.
Your new feature is going to take twelve months of development time to fully develop before it’s truly a replacement for the existing feature in Ubuntu. What you don’t do is spend twelve months developing and land it when it’s a perfect replacement.
What you do do is develop it in 12-13 week bursts, which means it’s going to take you roughly four release cycles before it’s ready rather than two. And you land the quarter-complete feature in the first release, replacing the older stable feature.
Consequence
If this were true, you would expect to see new features repeatedly arriving in Ubuntu before they were ready. Removing the old, deprecated feature and breaking things temporarily with the promise that everything will be better in the next release, certainly the one after that, definitely by the LTS.
Maybe you don’t believe that characterizes Ubuntu, in which case you should probably just stop reading now because we’re not going to agree with my fundamental complaint.
But I will say this: I know I’m responsible for doing this on more than one occasion because I had to; and I saw the exact same pattern in others’ work, when I was a manager my reports complained that they had to follow this pattern and I still see the same pattern today with features such as Unity and the Software Center.
Follow this pattern and developers are going to complain that they need a release where they don’t have any features to work on, and can just spend the time stabilizing and bug fixing.
Worse, follow this pattern and you’re going to create a user expectation that releases are going to be largely unstable and contain sweeping changes that are going to be surprising to administrators of Enterprise desktop deployments, and discourage them from using your distribution at all.
A kludge to this would be to overlay a second release schedule onto your first one, with more of an emphasis on stability and support. It’s a target for your developers to complete their features, or at least stabilize them in those 12 weeks; and it’s a target for your users to consider deployment. So three out of four of your releases are really just unstable previews of that final fourth release.
Complacency
This second LTS release cycle solves the unstable release issue, so why is this a problem?
Because developer time is wasted; because user time is wasted; because user confidence is lost.
Because features can take longer than two years to develop; or if even if a feature takes just two years, if it’s not begun immediately after the previous LTS release, it’s not going to be ready for the next one so you might postpone and lose the lead.
Because you might expect a knock-on degeneracy effect in the LTS releases as well; with 12.04 LTS being less stable than 10.04 LTS, which was less stable than 8.04 LTS which was less stable than 6.06 LTS. And it’s far too late now to have considered the 10.10/11.04/11.10/12.04 cycle to have been a Super-Long-Term-Support release and kept back the complete replacement of the desktop environment.
Because the original reason for the six-month cycle has already been forgotten: features are targeted towards releases, rather than released when ready; because the original base for the release schedule (GNOME) is no longer a key component of the distribution; because no other key component has adopted this schedule.
Because these might be a better way.
Cataclysm
What I’m going to suggest here is a completely new development process for Ubuntu, complete with details about how it would be implemented.
I’m going to suggest a monthly release process, beginning with the 11.10 release. It so happens that this fits perfectly with Ubuntu’s version numbering system, the next release would be 11.11, followed by 11.12, followed by 12.01 and so on.
This monthly release would be simply known as release in your sources.list, updates would be published to it on the first week of the month. There would be no codenames, and due to the rapid releases, changes would be largely unsurprising and iterative on the previous releases.
In order to provide user testing, a second release known as beta would exist. It’s from this release that release would be copied from on that first week of the month. beta would be updated every two weeks, on the first week of the month after it became the new release, and then on the half-way point of the month. Users who like a little bleeding on their edge can change their sources.list to use this more exciting release, or download appropriate disk images.
Developers wouldn’t run either of these, they would run the third release branch alpha. It’s from here that beta is updated; and from here that daily disk images would be generated.
Publishing from alpha to beta, and then from beta to release is handled semi-automatically. The release manager will track Release Critical bugs, and will hold up packages from copying from one to the other if they have outstanding problems. If this sounds familiar, it’s because this is exactly how the Debian testing distribution works and I recommend using the same software (which Ubuntu already uses to check for archive issues).
So where do developers upload? It’s tempting to just say to alpha, but if we say that, alpha will end up looking very different from release because it will be filled with unstable software that’s not ready for users yet. This will make it harder for problems in the release branch to be fixed, because none of the components are left in alpha because they’ve been replaced by something that’s not ready yet.
Developers will upload to an unpublished trunk branch. Packages will be copied to alpha provided:
- there is a signed-off code review for the upload
- the upload meets policy (lintian clean)
- the upload builds on all released architectures
- unit tests pass on all released architectures
- functional and verification tests pass on all architectures for the archive as a whole
I just introduced a bunch of new checks to the developer process there; I just introduced code review, mandatory unit tests and then piled functional tests and verification tests on top.
The first four are relatively self-explanatory; fail any of these tests and your upload has marked the tree red. In which case not only will your package fail to copy to alpha, but you’re about to have a conversation with the Release Manager.
For functional and verification tests, this means doing more automated QA. A failing test could be an automated installer run, or an automated boot-and-test run, etc. They’ll run sometime after the fact and will make the entire tree red. The Release Manager or their team will have to examine the logs to figure out the culprit.
So things aren’t copying to alpha, now one of two things is going to happen.
- the Release Manager reverts your upload. Because trunk is unpublished, this is simply overwriting with the older package from alpha; nobody except the original developer is going to have known about it
- after talking with the developer, it’s decided that further uploads of other packages are required (e.g. due to dep-wait, or the bug being elsewhere) in which case the tree remains red while the developer (or another in rare cases) prepares that fix upload.
While the tree is red, nobody else is allowed to upload unless it’s a fix for the problem. All effort should go to fixing the tree.
If the archive has to always remain stable, how do you develop large features such as Upstart, Unity, Ubiquity, Software Center, etc.? You use a PPA to do development, on your own timeline.
If your feature takes twelve months to develop, you take twelve months to develop it in that PPA. You’re going to be posting regularly to mailing lists or blogging about your feature to encourage users to add your PPA to their sources.list to gain testing. Obviously you’ll be doing various uploads to the main series over time to get all your dependencies in early where they don’t conflict with what’s already there.
Conclusion
My proposal is a radical change to the Ubuntu Release Process, but surprisingly it would take very little technical effort to implement because all the pieces are already there including the work on performing automated functional and verification tests.
I believe it solves the problem of landing unstable features before they’re ready, because it almost entirely removes releases as a thing. As a developer you simply work in a PPA until you’ll pass review, and land a stable feature that can replace what was there before.
It solves the need for occasional stabilization and bug-fixing releases because the main series is always stable and can receive bug-fixes easily separate to any development work going on. A developer can chose to focus on looking after the main series for some of their time in addition to their feature development work, or devote all of their time to it.
Another problem I’ve not talked about is that of building software on an unstable foundation, also solved by this change. Since developers will run alpha, and vendor developers can just run a relatively up-to-date, yet stable, release branch, software can be built on a solid foundation. Only the new feature or software itself is unstable until ready.
Canonical can keep its review schedule, and use developer uploads and work items; except rather than landing in a release, they can now land in a PPA.
Merges from Debian unstable can be handled pretty much continually as long as they keep the tree green, alternatively one can decide that users ultimately don’t care about an updated version of cat and until a case can be made (e.g. an open bug) for a package’s update, it need not be merged.
Users can now be confident of always receiving a stable operating system, because of the multiple testing and QA passes each change continually receives. Updates come in monthly, two-weekly or dailyish batches depending where in the main series they chose to run.
Enterprise administrators can run this stable release, because it only changes gradually with well-tested updates. The big changes and features have a long gestation period in PPAs, with many advance notices and blog posts about them. They’re not a surprise and can be planned for well in advance of their landing.
Downsides will, doubtless, be found in the comments below.
For your consideration.
I suspect you’ll find server admins don’t like this, but then Ubuntu Server could use a different system, so that shouldn’t be insurmountable, though it’s still something to consider.
I also suspect OEMs would hate it, which may be a bigger problem for Canonical. So you may want to check with whoever you’d check with internally about that kind of thing. =)
I’ve had a vague plan to try and convince everyone to move Fedora onto a rolling release for years, though, for many of the same reasons you mention; a cycle of stable releases ties up a lot of developer and other resources and doesn’t really provide a huge amount of benefits, particularly for the Fedora user base.
I would add two levels to the releases; there would be alpha, beta, release, STS, and LTS. STS would be a once-a-year, “short term support” – the “major release”, as it were. The software in STS would be frozen for a year, and supported for two. LTS would be released every two years, and be supported as it is now.
That way, while desktop users could get the continual upgrades (and a few bugs, inevitably) from Release, low-priority servers could use STS and be guaranteed the software won’t change for the next year, and high-priority servers could use LTS, guaranteeing four years of support and stability.
“I just introduced code review, mandatory unit tests and then piled functional tests and verification tests on top.”
Looking at the amount of resources available on one hand, and the amount of work required to do just this one line of your plan, how would you proceed with this?
Don’t get me wrong, I dig the Chrome-style approach here, but you’d have to at least start with a very small subset of the distro and be brutal about it, do we really have “the pieces already there”?
I believe the whole 6 months cycle is what’s taking up all the resources in the first place.
Not to mention so many previous releases that need to be supported with fixes, backports, duplication of efforts, etc…
In time resources should become gradually available for most of the stuff mentioned here.
Sure at first this will be a big change, but if it helps solve most of the problems mentioned , then i think is well worth it.
Oh, btw, Foresight had a system very similar to this, they chose a very stable older branch for their Shuttle preinstalls that rolled in from previously tested channels.
I agree with your assessment of the problem – older, stable features are replaced by half-complete features and lose user confidence. But I don’t agree with your solution – Ubuntu’s 6 month releases already don’t generate as much attention due to the little amount of changes between them in the media; making the releases a month apart will take a big hit on publicity.
Just look at Chrome – which barely gets any ‘big news’ coverage besides unstable features, and Firefox, that (used to) get a lot of pomp on a new release. With Firefoxes newer and faster release system, some announcements are even just “nothing new to see here, move along…” – which really doesn’t do good publicity.
To those who are saying this would hurt publicity, I would respond that publicity is absolutely the least of our problems right now compared to poor quality perception. We’re a Linux distro, not a marketing department.
That said, I’ve advocated rolling release for a long time and have Debian unstable installed alongside my Ubuntu precisely for that purpose. I would be thrilled if Ubuntu adopted a rolling or monthly release cycle, but I don’t see it happening because of the extra manpower that would be required to keep those monthly releases stable enough to use.
Why do you say that? It’s a product, and product you want millions to use, no?
…and you gain millions of users by having quality problems in 3 out of 4 releases.
interesting.
btw, chrome is one of the fastest growing browsers. despite not having huge fanfare with their small and frequent releases.
Chrome may be, but I find many people who have once switched to FF do not want to go away, just as Opera users are very loyal. It seems only ‘techies’ went for Chrome instantly.
But when I get someone to try Ubuntu, I never give them a normal release, always ensuring they get LTS + with a few updates for basic things (FF, Libreoffice, Chrome, and so on).
“btw, chrome is one of the fastest growing browsers. despite not having huge fanfare with their small and frequent releases.”
no fanfare? seems every piece of software I install says install chrome to make the web faster. Not too mention every google site out there advertising it
I’m not sure why we need to equate releases with new features.
What is the reason for a release, if not new features? Just random bug fixes don’t cut it in my book.
You can have publicity when you have a working product. The last thing you should be doing is pushing something that is horribly broken. Ubuntu stability has successively gotten worse, with occasional improvements (8.04.1, 10.04.1).
Buggy half baked features, Instability and Bad Press dont bring in more users, they do the exact opposite !
The best publicity you can get is by word of mouth and that only happens when your product is about “Quality” releases, instead of “quantity of releases…”
You either “aim to be the best”, or you’re just the rest…
I think this could work if the LTS is the culmination of two years of rolling releases.
So there would be 12.04 LTS and 12.05, 12.06,12.07… but the non-LTS would be rolling. I think all users would love this, you just need to make package upgrades less intrusive.
Nearing a LTS there should more emphasis on polish etc and less churn, then the LTS should get the normal 5 years support with extra bug fixes and security updates only.
Doing it that way would make OEM and server admins happy, coz they can run evenX.04.1 or evenX.04.2.
Canonical and the Ubuntu communitys would only have to provides updates for 2 or 3 LTS and 1 rolling Ubuntu, that is less than they need to do now.
I like the idea. A well tested rolling distro with small changes is how Linux should work on the desktop.
Completely agree. A monthly release would allow focus on quality (not crunch), combined with LTS releases every two years would please OEMs and server admins.
Best of both worlds.
Make it a LTS every 3 years (and supported for like 5 or 6) and you can start to grow an ISV ecosystem too. New versions, new APIs are all nice for FLOSS developers, but kill vendors. Many projects usually take a year to develop. If they start with the release of a LTS version they can expect to have just another year before the next one comes with all the latest and greatest… and without something your product actually requires.
Which is exactly the system debian has.
I wanted to write a comment but then i read yours and all left to say is:
Agree!
Completely agree.
I agree with you re the 6 month process/time taken out for UDS/reviews etc, however I am not sure I agree with the 1 month rolling release schedule. I don’t have any better ideas that would work well however.
I think this idea is awesome.
I agree.
Awesome…
I think that Firefox’s example should be looked and observed very carrefully: since its rapid release cycle, folks aren’t interested anymore in Firefox’s new features, etc in the “Hmm, another release, but, what version?? ..who cares” model.
Ubuntu must keep its codenamed previously scheduled heavily blogged about 6 months cycle, because:
people actually knows what vesrion they are using (and what they will stick with)
ppa better organized (1 month will say goodbye to non-Canonical PPA maintainers)
folks’ feedback heavily damaged (and how can Ubuntu gain 200 mil without the users’ feedback)
attention/advertising/new contributors that gathers to UDS (already a place to share ideas, plans, etc for the future) will be lost
and, a total confusion (I repeat, just like in Firefox, there must be some outstanding feature in order to catch some attention)
we are under 1%, 6 months cycle along with events, celebration, blogging, forums, etc are one of the main points to break this limit (along with polish, functionality, stability, improved drivers, etc)
In today’s ever changing world it doesn’t mind which version you have, only that is the most updated, secure and feature filled one.
This is simply not true. I used to want the latest features all the time when I was a student. But once you start using your computer for real work, the last thing you want is something which breaks because a random update implementing a feature you don’t need suddenly came in. Like a tex update the day before your thesis deadline, or an X update which suddenly breaks your system when you need to get things done instead of fiddling with your system.
I think we need less releases, but increase the usage of ppa’s so people can use the latest version of software if they want to, but have a safe backup if they need to.
No no no… We want a combination. Watch:
This gets implemented. X.01 does not exist, except as alpha (maybe).
Every year, we have a “STS” release, sortof comparable to what we have now, that covers the issues you mentioned.
Every _three_ years, we have a LTS that will be in support for 6 years. This covers commercial interests, such as OEMs.
Everything from the STS back to the prior LTS can be imported without breaking anything.
Suddenly, everything works.
Almost like having Stable, Testing, Unstable and Experimental right..?
As much as Ubuntu evangelists bemoan Debian, it works, has varying levels of stability and current releases and will always be better than Ubuntu.
+1. Exactly the reason why I switched from Ubuntu to Debian testing which is overall very stable (given the name).
Same here, after being frustrated (and sometimes furious) with “not-ready-for-prime-time-but -6-months-are-up” releases from Ubuntu, I moved to Sid. It vary rarely pisses me off.
Gonna agree with you too, reason Im using aptosid is for the rolling release idea, so there is none of that “oh crap 6 months is up”. Pushes out too many bugs from what Ive seen, which is why I also stopped using ubuntu. Debians release schedule works.
The only thing I don’t like about Debian is that one is forced to use Iceweasel and Icedove. Yes, I know they’re Firefox/Thunderbird rebrands/knock-offs/whatever you want to call them, but shouldn’t the user have a choice as to what browser/email client they want to use?
I tend to agree with you, the monthly releases would work great for typical users. It’s something I’ve been considering in an upcoming project as well.
I think it’s still important to have long-term support releases for software that requires certification with the system. I’m sure you understand how important that is in many organisations.
[this is a rant]
I hope Oracle (for instance) doesn’t decide to throw in the towel and stop supporting Virtualbox on ubuntu because they don’t want to keep building new packages every month to support the “latest” ubuntu.
Seriously, is there something wrong with the software distribution model on windows and Mac OS? Why do I have to update my distro in order to use the latest version of Inkscape? Why can’t I download it and run a fancy installer just like my colleagues on other platforms? Because of some mumbo jumbo about shared libraries, and about how indeed it is an elegant technical solution to keep everything tightly coupled and in sync?
If anything, I’d say Ubuntu should move to a slower release cycle. Release once yearly, and with every other, or every third release being an LTS. Support the single release with new updates to non-system software like Firefox, Libreoffice, Inkscape wherever possible. Surely, Evolution 3.6 should be able to work with Gtk+ 3.0, right? There’s supposed to be API compatibility in the Gtk+ 3 series right? Right?
Am I terribly mis-informed? I just want to be able to install the latest firefox and libreoffice and inkscape and java JDK and be happy. I don’t care whether I am running Linux Kernel 3.0.0.7, my hardware works, it has worked perfectly on this lovely 4 year old machine since like version 2.6.26 or something. I only look need new kernels when I buy new hardware and need them for proper support.
The servers I run? I don’t care what kernel they are running either. I just need my LAMP Stack in tip-top condition, and secure. Ditto for my SSH service. You guessed right. An LTS release serves me well in this regard.
Users want an LTS desktop too, but they want to be able to get the latest versions of apps that they use (such as, you guessed it, LibreOffice and Inkscape).
If ubuntu really cares about the everyday user, they should solve the end user package distribution system. The App Store concept is good, bring us MacOS style app distribution too.
I think this is the best idea to promote Linux among users who aren’t Linux enthusiast.
I myself don’t mind running an unstable system that I need to fix routinely. I also enjoy trying the latest Linux distros every now and then. But if I am to promote Ubuntu or any other Linux distro to friends and family, I think we should have a solid and rock stable OS base + most recent releases of applications. The PPA system works fine but it would be better if Ubuntu could backport the updates to desktop apps so I can update to the latest versions without upgrading my system.
You are confusing two things: software/package management and release schedule/cycle/model.
For you to be able tom get new versions of projects without going through a dist upgrade, the project should publish a repository. That is simply a different way of installing software, and some (many?) projects do this: Wine, Opera to name two. So instead of downloading an installer, what you do is download & add to the defaults is a source list & archive key. Then the package manager will automatically pull in updated versions if you do an upgrade (safe-upgrade in aptitude), and you will not even have to worry about manually checking for new versions or manually downloading or manually installing them.
Or if you insist on downloading stuff manually, you download a package. Try Opera.
Release model/cycle is just how the project (in this case Ubuntu) sees fit to organise its schedule(s). Completely and utterly nothing to do with downloading installers or packages.
I think you’re the one confused about his point: PPA doesn’t solve the problem in any way : third party still need to publish binary package for several versions, which usually is too much of an effort; so in practice, only highly-motivated third party publish packages for more than the last one or two releases.
The obvious solutions suggested above is that by adding stability to the base, publishing binaries will cover a large set of users during a reasonable time range.
More generally speaking, i wonder why this problem is not obvious to Ubuntu developers. It only requires watching one or two normal users for a one or two years duration to see the problem that this geeky upgrading brings
With Scott’s proposal they would have *less* Ubuntu versions to support actually, as there would be only one non-LTS release left.
The only thing they would have to do is test (and test-build) their latest released package on the “beta” release (which can be partially automated), and in case of issues, fix those & prepare a new package release. I expect that many software developers will have to release more often to fix their own bugs than for incompatible changes in the monthly-rolling release though…
(Other software developers might prefer to only support LTS releases instead; that’s what some do already of course.)
My point is that the package manager, and by extension the whole of package management does not care for version numbers of Ubuntu. It only cares about dependencies, conflicts and arch. As long as the upstreams of your libs do not push out updates that imply ABI or API breakage, a single package can support every version of Ubuntu under the sun that supports your minimum requirements.
Scott, I’m amused at how we’ve identified exactly the same problems with the Ubuntu development process (I mentioned some of them in my plenary talk last UDS), but we’ve come up with diametrically opposed solutions. You think we should have a release possibly containing new features every month. I think we should have one every two years.
We agree on the root cause: Ubuntu has not just time-based releases, but time-based features. Every problem is assumed to have a solution that can be implemented either in 13 weeks, or in landable 13-week chunks. Often that just isn’t true, and in trying to make it true, we release half-baked designs or implementations or both. (Or in the worst case, nobody bothers even starting on the feature.)
Moving to an always-stable-trunk model, as you describe, is something that could work no matter how frequent the releases were: every three years (like Windows, roughly), nine months (Opensuse, roughly), six weeks (Chrome and Firefox), one week (Facebook), or whatever.
Therefore, the ideal release cycle length depends not on that development model, but on other factors. And there are many factors that I believe don’t just make a one-month release cycle a non-starter, but also mean we should have a much longer cycle than we have now. ISV compatibility checking and migration tools (as “coward” mentioned above), OEM certification (as Adam mentioned), cross-feature integration testing, upgrade testing, promotion in free media (as Vadim and razz mentioned), training program maintenance, toolchain and language migration, enterprise migration, server uptime vs. security, tech support, printed manuals and other books, developer reference materials, and so on.
Most of these are much bigger issues for Ubuntu, or Windows, or Mac OS X, than they ever will be for a browser or Chrome OS — where outside the Web frame there is (if you’ll pardon my saying so) very little to speak of, and inside the Web frame the difficulty of application development is mostly a sunk cost.
Interesting point-of-view. May I point out that debian has the advantages of both with a stable release every 2-3 years as well as testing/unstable/experimental rolling repositories?
Making every monthly release very stable sounds like a lot of work, and as others have pointed out expecting third parties to release apps/drivers for every monthly release of Ubuntu, were this cycle to be adopted, is not going to happen. So why not take a split approach like debian and have annual or bi-annual stable releases as well as tri-monthly or monthly or daily beta releases for those who want to live on the edge, have the pain of getting the latest flash/inkscape/sun java to work with their system, and incidentally do a little bug reporting and patching?
Scott argues that a monthly release is good for users, and it is, provided they (a) only want to use software provided by canonical or third parties that release every month, (b) like updating their system regularly, and (c) don’t mind the occaisonal bug or upgrade glitch (pretty-much unavoidable). Ubuntu’s never going to be universally popular unless (a) third-party software and driver writers can provide installers that just work for every major release and (b) desktop users don’t feel they’re expected to update their system every few months (not all users are confident about doing system updates by themselves).
I don’t see any Debian advantage as such. All Debian users I know run unstable or testing, noone is running stable.
not for servers and supercomputers
I do! I like stable. It works. It does not get in the way. For Tinkering i install 2nd distro of choice. And for not really needed bleeding edge stuff and so on.
I run stable on all servers, and I run stable on my laptop/desktops for at least 6 months after release, and then only selected apps get upgraded. So real people
Users who don’t want their computers to change every few months (which is most non-geeks in my experience) are very happy running stable (or Ubuntu LTS). The 6-month cadence of changes is way too fast for them, and if they pick a non-LTS release they ‘fall off the end’ of updates. (Debian is only slightly better in this regard, with ~18months secuirity support once stable -> oldstable.
Well, I do. Because I want a stable system, even on my laptop!
I just add some backported apps like Iceweasel and LibreOffice and use a sid schroot for the really bleeding stuff, but my core OS is Debian stable.
I think what we need is a two layer approach, like others already said: a stable core with updated apps.
In Debian, this could be achieved by using more massively the backports repo.
Chakra Linux is using a process like that, they call it Half-Rolling release. Stable core, with up-to-date KDE.
Interesting article.
I am not an Ubuntu user, for a variety of reasons, but a big one is that i prefer a rolling release. I believe distro’s that don’t adopt a rolling release are somewhat flawed. Here’s why; As a user, i am not interested in re-installing my OS every six-months or even once a year… and i don’t think i am alone in this thinking. myself, i use Archlinux. There is no versioning, or tradional release. I install Arch and i update Arch ~ i think this is how an OS should work (and all of the most popular ones do work this way to a degree, aside from a new release every few years, like MacOS or Windows.
I will point out an obvious scenario where long release cycles are better; Enterprise Linux. Obviously, servers and some production environments benefit from long cycles, but i don’t think ubuntu is one of them, and as an administrator Ubuntu isn’t exactly my 1st choice for servers/workstations anyway.
For those who think Ubuntu needs 6 month cycles for promotion, or to sell some new killer feature ~ you all live in a fantasy world. lol. Ubuntu needs stability, reliability and confidence from it’s users. I think in all 3 of these areas Ubuntu is very up and down. Quality of product and a reputation built around that, is far better than publicity…
for those who want to play it safe, stick to stable repos, if you want more bleeding-edge packages, have something like Archlinux has – testing repos or use Launchpad PPAs. I think that tends tobe what users are doing anyway..
I am not sure if i even see the point of monthly releases. I think it makes for more sense to just have a straight rolling-release. The only big downside to having a rolling-release style, is that if users don’t upgrade for months, there will be a good chance of some breakage. This is mostly minor for a competent user, who will fix the issues as they come down, but also might cause problems for the newbie. i suppose that is food for thought.
anyways, great article Scott.
One downside of landing a big feature from a PPA is that this tends to cause massive *unnoticed* instability as a result: thats something observed in many projects, on many different timescales, and is what the ‘continuous integration’ workflow aims to address: keep everyone working on the same stuff all the time, so that integration doesn’t carry a years worth of integration; it only carries a day at most.
I love the rest of your proposal, I just wouldn’t develop in a PPA: develop on trunk, relentlessly rollback uploads that cause trouble, and use feature flags (some mechanism for optionally turning on new features) to separate in-development-features from released-things.
you both have the same problem: don’t like the present URP
and both of you choose the extreme way short or long. does this do not show us that the “middle” is OK?
+ the LTS solution?
imho the 6months solution is ok. but maybe not every developer has to work in this cyclus. you can make something new and put it online for others who are interested.
and with the next ubuntu maybe the other developers who works in this cycle put it in ubuntu xx.xx
malachi, I’m not sure who “you both” refers to, but anyway, that argument is a logical fallacy known as the “argument to moderation”. It’s like saying that a point halfway between two mountain peaks will also be a mountain peak. Usually it isn’t.
1 release per year
1 LTS every 3 years would do it.
I don’t think that sort of a ‘rolling release’ is the solution to the problem. I do agree that bonuses and rewards being tied to the number of features that landed in the release isn’t doing much good for the product.
I once talked about a hybrid between sort-of-rolling and 12 month release cycle distribution. One year is not too long for people to wait for and not too short for developers to write good quality code with unit tests and everything else that goes along with it.
Standard Ubuntu cycle is stretched to 12 months and at the same time, major applications are moved to separate ‘official PPAs’ that are available and turned on by default. This way we could have a new version of Firefox every month, LibreOffice would be updated when new version when it comes out and passes all the testing.
Essential system stuff, stuff that in fact is an operating system (everything from GNU to Xorg and Gnome, Unity and KDE) would stay the same for 12 months (getting the regular bug fixes). This would also ensure API/ABI compatibility for at least a year. Not to mention the dependency nightmares. Which would be beneficial for third party developers.
I like your plan – I stopped using Ubuntu precisely because every new release broke stuff that worked before. I liked the idea of Unity, but the version they first released was buggy, and missing a lot of features (especially customization). On the other hand, I also like having up-to-date Firefox, LibreOffice, etc. Nowadays, my personal system runs Windows 7 (it’s pretty, it WORKS, it has hardware compatibility), and my work system runs openSUSE+KDE (because it seems to be the most stable of the mainstream Linux distros (barring the occasional segfault, and inconsistent hibernation), though I may switch to Debian like the rest of my lab). If Ubuntu would wait until features were actually ready to release them, I’d happily go back.
2Dragos
1 release per day
1 LTS every 3 days would do it.
Ubuntu fast pace makes books (and tutorials, videos…) authoring almost impossible. A new feature or application is not understood by low-tech users when a new one substitutes it.
Big deployments are a nightmare as well. You can not plan a delivery of 100.000 Ubuntus in one month. Of course you can in your mind, but real projects need to find economical and human resources. And six months full updates are not a solution.
Please, slow down a bit.
End users (like me) need training material / books to get the most out of the software. It takes a year to get a book in print. People who can write well like to get paid for writing.
‘Missing Manual’ type books for Ubuntu LTS might actually sell in numbers if the books came out (say) 6 months after the LTS. PPAs for updating firefox and perhaps LibreOffice would help as those projects tend to change their interfaces relatively slowly. Those of you who knock off a patch before breakfast have to remember the average end user needs step by step instructions and visual cues!
My personal nightmare: LibreOffice introducing a ribbon, Unity/Gnome Shell doing a re-write, and all in the same release.
The books and tutorials will apply for LTS only, while the new features coming to non LTS versions will be presented (combined) into the next LTS official books and videos. All other new features could be well covered on website like Ask Ubuntu. I really think it’s a good idea, a lot of non tech users have a hard time upgrading every 6 months and running into issues. The LTS could be most stable, while the others cutting-edge. I bet that most enterprises would prefer the LTS, as well as tech users and non-techies.
I agree with the reasons for change, however it would be quite hard to eg. change Gnome version from 2.32 to 3.0 – this transition was not only a change in libraries, but it is also even now visible in some packages not working properly. Therefore it seems to me that gnome transition (maybe from 3 to 4) would not be a good idea to do in a month or in a developer PPA, which would only brake a system.
And even integrated seperately it takes most of people to work on this transition – and it is really not a month work.
Monthly releases doesn’t mean a major change like GNOME 3 needs to go in the first possible monthly release. It can stay in a “development” repository for several months until it’s ready to go into the monthly release, and only then users of the monthly release will get it.
I also think this idea is awesome. This release cycle thought it will be for desktop so it can bring major changes faster. So you can stay in safe environment with an lts or go for upgrades every month. This will be users choise. In the server side you could have every month a services upgrade for known critical bugs instead of having to stay with older versions of software patched with security upgrades. This will be also good for lab environments or systems that need to run recent versions of software for exploiting new features / functions / libraries.
It would also work well for variants like Kubuntu, where their releases can be more in line with major releases (of KDE SC,in the case of Kubuntu).
I thought that this was the point of an alpha release? Don’t let Google fool you with their release word doublespeak.
You’ve identified the problem, but not the solution.
New users HATE running updates. Remember how annoying system updates were on Windows? Now multiply that every month. Why can’t we separate system updates and application updates, and allow installed applications to update via strictly controlled, Canonical-approved PPAs? That way, major changes to kernel, DE, etc can come to users fully mature over a twelve month cycle while users can still enjoy the latest stable versions of their installed applications.
Brilliant idea. An annual release cycle that actually works and Approved PPAs for applications. Devs get more time, releases aren’t hit-or-miss, and users have up to date apps. A 6mo cycle is great to generate buzz, but when most of the buzz is about “what broke this time”, I think it shoots itself in the foot.
Windows does have updates every month. It may only be bug-fix and security updates that come through for Windows and any other MS software (Office, IE, MSE, etc.), but they come every month (usually the 2nd Tuesday of the month, the so-called Patch Tuesday).
Lol, on ubuntu I get updates every two or three days, which is *very* frustrating on my 1Mbi/s GSM connection :/
Using the Oneiric beta or the current Natty release?
This. I want my system to be stable and my applications to be up to date. I know I’m a version behind (using 10.10) but even if I was using Natty I would still get all my mains applications from ppas.
Everybody who says that this is bad should propose a better fix for one of Ubuntus biggest bugs, eg. that unfinished features land in releases and are only really polished in a LTS. Non-LTS releases are (have become) fairly crappy IMO.
Who here still runs 11.04 in its default installation?
This is a very interesting proposal, but I think it misses two pieces:
* Support timeframes. If you release monthly, how long do you support (think security fixes and critical bugfixes) a given release ?
* Beta testing. One reason for the 6-month timeframe is that it gives an amount of time where corner cases can be reported by random testers (think “this kernel broke my laptop suspend”) — you might have trouble catching that in a more rapid cycle
Could you elaborate on how you would solve those ?
[ In OpenStack we use a milestone every 4 weeks to solve the "time-based features" issue, but we still use a "release" every 6 months to get extra testing/QA on a longer-supported milestone ]
Jorge, I don’t think resources are an issue with this extra one line of Scott’s plan. We already do code review when trying to figure out people’s code. We already pay for the cost of writing functional tests with the incredible amount of time we spend suffering under and fixing regressions.
Great post, Scott.
My friend, what you are describing here is more or less the development process of Debian testing. Why do you need to reinvent everything?
Hey Scott,
honestly, coming from the server view of life, I think this will p*** off a lot of Server Admins.
But thinking about the other side of life.
Why don’t we make a difference between the Distro as underlaying foundation and the special products like Unity, Orchestra, Ensemble or whatever is being developed for the Distro.
It should be an easy task to release a distro every 6 months, but provide (example) Unity every week?
Just don’t push it into the distro.Provide packages with all necessary libs,tools,binaries (e.g. /opt/canonical/unity/{usr,usr/lib,…}) so, you can push your software product out whenever you want, or whenver it’s stable (having different pockets for bleeding edge, beta, stable)
This would help having different release schedules/cycles for different stakeholders.
Furthermore the distro people can focus on important things like the the kernel, X, and other important stacks like gtk, qt+kdelibs, build tools.
Or, and this is also not new, we just do rolling releases and branch at one point LTS releases with a really tightened featureset for all stacks used on it (something along the lines RH is doing it with Fedora and RHEL)
But as said, for the server people, it really doesn’t make sense and IMHO it’s dangerous to p*** off the SysAdmins.
Regards,
\sh
I agree with you: different system parts would need different managements, and basically the desktop side should get a faster cycle in wich the main apps get updated (including the DE and so unity and compiz), while the system side should get different levels of release cycles (keeping their number little, btw) calculated on their relevance on all over the system. However main libraries and other low level stuff should have the longest cycle that finally should determine the release.
This longest cycle (aka the release cycle) imho, as mpt says, should be longer than the current one to both allow better OEMs and 3rd party support, and no to force regular users to completely upgrade their system (not to call it “to change distro”) every few months.
I think this could be a good compromise between the rolling release (cool for techies, but inadeguate in our case) and the current state (where there are too few important updates and too much new packages to download anyway, with a breakage every six months).
Just the other way around… you get riots with even minor changes in GUI, changes in system administration (i.e., systemd vs upstart vs sysvinit) give problems with geeks mostly, changes in kernel or base libraries go by largely unnoticed (as long as the rest of the software stack is updated to match).
I use my Ubuntu Desktop to do my daily work, earn my living. Having followed the “normal” releases for a while, I am now sticking with Lucid until the next LTS comes out. De-facto reinstalling every 6 months just isn’t worth it.
This leaves me in exactly the situation “coward
” is in – chose your poison
- Stick with outdated versions of Apps (Firefox, anyone?)
- Upgrade Distribution (and possibly break what I need for my daily work)
- use some more or less exotic PPAs (and risk them breaking something)
So my wish for the Ubuntu release cycle is: Do less releases, but more backports
For example: Have repositories “lucid-classic” and “lucid-rolling”
- Firefox current would go to lucid-rolling, while lucid-classic would stay at 3.16 (wasn’t it?)
- lucid-classic would stay on Mono 2.4, with lucid-rolling being on 2.10
- Both lucid-classic and lucid-rolling would stay with the then-default Gnome Desktop: Big visible changes are perceived not as an update, but as something new.
I like that idea, but why stop there? Have classic, rolling-app, and rolling-system upgrade options, but be aware that things will break at major changes; a browser adds Html5 support, or the kernel changes some default behavior.
I personally think that more than 1 release a year isn’t useful to me, reduces the wow factor of the newness, and decreases stability. You may hate to think about it, but saying it is done when it is done is the best for the software. Make some initial plans, but don’t box a programmer into hacking a 2 year project into 6 or more 6 month chunks. (Yes, that is what I meant to say.) Do the right thing and make that particular release cycle two years long. Guess what, you get Debian…
For my servers, I would even vote for a Super LTS every 4 years that gets security upgrades for 8 years.
I have been using Linux and then Ubuntu long enough that I want long term security updates so I don’t have to spend a big chunk of time re-designing a server from scratch very often.
The one month release cycle has some issues with big changes and cumulative change effects. I pity the poor developer who has a big change and has to keep re-porting his changes to a rolling set of system code over a course of 2 years. How many times can you upgrade Ubuntu before you really need to just reinstall? You get the same cumulative config changes that force a re-install with what will be seen as monthly upgrades.
I have several machines that have been upgraded every 6 months (and several times but not always upgraded when the next release was still beta or even alpha), the oldest one since 2005 IIRC.
This makes sense; IF AND ONLY IF a better upgrade system is introduced.
Directly upgrading is and always was a lot of trouble, invariably introducing unexpected problems.
Though I see no better option, maybe someone else can come up with a golden idea.
Ubuntu rolling release is a great idea!
Absolutely. What we need is a system that simultaneously:
– propagates bug/security fixes and evolutionary-features from upstream fast.
– delays revolutionary features till they are really ready.
So, for example, if a game adds a new level, or gcc releases a new version with improved error detection, or apache releases a security patch, or CUPS adds support for a new printer or libgtkpod for a new iPod…I want that on my system right away.
On the other hand, a change like KDE3-4, Gnome2-3, Unity, PulseAudio, is something I want to delay till it has been fully tested and updated: maybe updates once a year.
The problem is that the new GCC won’t just update error reporting, it might start flagging your broken code which compiled fine before. A better oprimization might break dodgy code, the new release can very well have introduced new bugs while fixing others. And so on across the board with “just system code.”
Pingback: Рассматривается предложение по выпуску ежемесячных релизов Ubuntu | AllUNIX.ru – Всероссийский портал о UNIX-системах
I was going to post the same thing as Sadig: if Ubuntu considers itself to be a serious server distro, you cannot do away with long-term stable releases. From a business perspective, infrastructure needs to be reliable, not featureful. Features only matter at procurement, not while in operation. In a way, Mozilla and Google are making the same mistake: in the context of webapps, the browser is infrastructure and should be dependable above all else.
Regarding end-user applications, both fast-rolling and long-term approaches have their merits. Fast feature delivery is mostly desired by enthusiasts/power users, which probably make up at least 90% of the Linux userbase. On the other hand, long-term stability is probably better for the non-technical userbase, which Ubuntu aims to reach more than any other distro.
If Ubuntu does take this route, it would be wise to make a distinction between infrastructure packages and “enthusiast” applications. Arguably, the non-infrastructure packages might not need LTS releases (or upstream does not recognize the validity of LTS) and could always be pulled from the rolling release.
If this is going to happen I switch back from archlinux
Pingback: Links 9/9/2011: Bodhi Linux 1.2.0, VortexBox 1.10 | Techrights
First separate the releases for server, workstation, desktop and mobile. Then only the debate can start.
For servers, we know the Redhat release cycle works well.
For professional workstations, anything between a six month to two year release cycle should work.
For ordinary non-mission critical desktops, there are three possibilities: a long term release plus a rolling repo, or a monthly release cycle or a rolling release.
For mobiles, it should be decided in collaboration with respective OEMs.
@Jumbli:
No, it doesn’t. They do have big problems with their releases, if they wouldn’t they don’t have so many backports at their hand.
What they do, which I don’t think is right in cases where sysadmins should be really conservative, they are pushing new upstream versions with every point release, and sometimes even during maintenance times.
We need to make a difference between the Server OS and the libs and tools etc. other people in businesses need.
Developers are in need of newer libs for their apps.
RoR needs to be always up2date if not bleeding edge.
Python Libs are always mostly needed with their latest upstream version.
Unity needs always be refreshed with new features, which means all libs, which are needed, are in need for updates too.
Those things should be laid out from the pure server/base OS.
Anyways, the release schedule now is predictable, which is (or is at least for me as a decision maker) a good thing. The quality of the standard OS and the foundation of the server release had always a good quality, sometimes there were some glitches, but hey.
The desktop is another story, but the desktop is always broken ( or did you ever see a bugfree MS windows?) and needs to be.
Having a new release structure can remove the trust in Ubuntu and Canonical.
For Ubuntu this is not a problem, for the professional users of Ubuntu and eventually customers of Canonical this can be a problem.
For me, the 2 year release schedule for LTS releases was very good.
You can decide when you upgrade your server fleet to another supported LTS release.
Server LTS means 5 years of support, so there are at least 2 LTS releases which you could use.
And in todays times of automation, it’s been an easy task to upgrade your OS and your apps in no time.
This release-every-month or rolling release sounds pretty good to me. I’d use “release” for my desktop if the delay from “alpha” to “release” is one month in maximum. I can wait that long.
However, for selected business oriented user group, you’d still need an “lts” release that is similar to current LTS: never change any part of the UI if at all possible. Fix only security issues and crashes. This is because non-technically oriented companies sometimes insist on really stable UI for all the software they use (no matter how stupid that is). Mostly this is because they employ people that are not smart enough to figure out where the option that used to be the 5th option in the second drop down menu has gone (it’s now the 6th option). (That is my guess for the real cause, of course.) They teach every employee to use exactly one version of any given piece of software and then they teach the next release some later day – for every employee at once. And they never want to teach any people during “stable UI” period or update any of the material used for teaching the system.
After saying that, you’ll only need the “lts” release if you think you want those users. I’m not sure if Ubuntu would miss anything if those (l)users weren’t part of its user base.
Note that I don’t think that “lts” version is required for OEM installs: an OEM may specify that warranty is void unless latest “release” version is installed. Then they just need to keep the “release” version fixed for the period that the product is sold and still under the warranty. (If some OEM wants to use “lts” release because they do not want to support the product they sold even for the warranty period, I guess Ubuntu would be better without those OEM products.)
Ubuntu does not need “big” releases for media support. If the system is good enough, it will be used. See Windows XP for example, it was released in 2001 and still received pretty much media attention in, say, 2006. It did not need “big” releases to achieve that. If Windows XP was considered good enough to get media attention without “big” releases, then Ubuntu should have no problems either.
What you’re saying makes a lot of sense, for certain circumstances. I already run LTS on my servers for, well, long-term stability reasons. On desktops that I manage, we’ve been using the .04 releases since we can push them out in the summer (I work at a university). However, 11.04 seems to be completely unmanagable from a sysadmin standpoint and I just finished reverting back to 10.04. What I miss then are newer versions of apps that my users (and I) want, which means I’ll be rolling my own packages to make people happy. Monthly release cycle makes sense in that you get newer versions of applications more frequently. However, you cannot endanger stability in the meantime.
I see one major issue here. Monthly releases with the process you describe appear to let devs have more control over getting their own kinks worked out, and then potentially published more quickly. However, if a package dev is working from one release, the longer they work, the farther away from that release they will get, which means they will have to continually update their dev platform to ensure stability. This could get frustrating for devs very quickly.
For me personally, as long as stability isn’t harmed, I could get used to monthly releases. I previously had standardized on a source-based rolling release distro and found that I was going crazy keeping everything up-to-date. Stretching out my releases and going binary-based has improved my sanity greatly. If a rolling or monthly release cycle makes my life as a sysadmin more difficult, you can count me out.
Pingback: Ubuntu提议采取按月发布模式_互联网资讯最新报道_野火集
Debian testing kinda fits this really nicely. A nice flow of updates regularly, but have mostly been proven stable in sid. A perfect balance for the desktop user, to me. The server guys can stick to stable releases
I like this idea, but I think it would work only if Ubuntu scaled down significantly (something I’ve been calling for since 8.04, by the way). Universe and multiverse should just be moved to PPAs and a mechanism for finding them should be found. Packages which are deemed too important to do that with should be considered as part of the base.
Right now (or at least last time I checked), you have packages in universe that don’t even work and have had bugs files against them for months or years. Bugs that are reported on universe and multiverse packages during the alpha and beta releases are almost never triaged until after gold is shipped. That’s clearly unacceptable for packages which are considered part of the distribution.
Ubuntu seriously needs to streamline, get a real developer program in place (IDE / language / toolkit / tutorials / publishing), and stop releasing half-done software. I gave up on Ubuntu for a while after 8.04, when it shipped with a non-functioning default application on 64-bit. I figured they’d jumped the shark.
I hope your proposal gets seriously debated.
Pingback: Entwickler und Nutzer diskutieren Veröffentlichungszyklus » it-express
I would still propose to go for a rolling release and every second year a LTS version.
Pingback: Proposed: A Monthly Ubuntu Release Cycle « Linux « Technology « Theory Report
So you are basically saying:
Ubuntu folks: “Your release process is broken: so let’s look at what are doing the guys at Debian and just follow them”
cut ( http://cut.debian.net/ ) -> release
testing -> beta
sid -> alpha
Or are I missing something?
Gentoo effectively had a rolling release model (at the time–it’s been since 4+ years now, so I don’t know what they’re doing these days) where an upgrade consisted of rsync’ing the portage tree and then rebuilding half the world. And occasionally, stuff would break. Fortunately I never had to explain to my boss that a libxml upgrade killed my ability to use svn–i.e. do work–because it’s easy enough to remerge subversion. (Actual problem and chosen solution. Then revdep-rebuild could slowly fix random crap at its leisure.) But, it really made me worry about getting an upgrade that destroyed the system for good.
In theory, they tested it. In practice, testing got so spotty that stuff would languish in “testing” for months at a time, and there wasn’t a convenient way to install testing builds without running the whole system in test mode. Clearly, this testing process didn’t always work; and it could get so protracted that massively convenient features were unavailable to non-testing users, even weeks and months after they managed to get into binary distros. These, and the realization that compiling from source with meant you squeaked out a pathetic performance increase at the cost of compile time and conf file juggling (CFLAGS, USE, etc.), eventually made me realize that gentoo was a terrible choice for a work machine.
Anyway: testing on a rolling release involves just as much overhead as testing on a full release, but it must be paid repeatedly. And that gets nasty when the cycle gets short enough. Day-to-day changes were too rapid for Gentoo. One month might be too short for Ubuntu, unless they were to give up automatic Debian updates.
Now, to consider the original issue, that Ubuntu has put the focus on timed releases with predetermined features: this, too, is a problem. It’s being worsened by initiatives like Unity, where Canonical is creating a large base of code that’s effectively specific to Ubuntu. Sure, others can take Canonical’s code and integrate it, if they want to be one step behind Ubuntu and Debian.
I understand it’s a rough patch for Canonical: gnome is weighed down by committee and KDE is already too awesome for them to handle, since KDE has been following the Unity philosophy for four releases now. (Shamefully, I was back there knocking KDE 1.x for being “just like windows”. But I guess it’s the right way forward, as it seems to be practiced by Apple, MS, KDE, and Canonical, to great benefit for each.) The major difference here is that I don’t think KDE has a central design team acting as a strong driver for the project; they’re more like ‘rough consensus and working widgets.’
So to summarize, I would agree the URP as it stands is broken. It’s up to Canonical to decide what’s important: whether they want to keep the cadence, shed the pressure to put incomplete features in, and possibly focus harder on stabilizing LTS-1 as a pseudo-release-candidate for LTS; whether they want to alter the cadence to accommodate more feature work per cycle; or whether they want to keep making messes of every release and promising to fix it in the next one, something I’ve noticed happening since Karmic or so.
(I went Kubuntu Feisty-Gutsy-Hardy, reinstalled with Ubuntu Intrepid, upgraded to Jaunty, and then realized I’d fixed my setup after every upgrade for little effective gain; then I bought a print server so I wouldn’t have to fix anything which affected my wife (srsly? we can’t talk to XP after all these years?), went on to Lucid when it came out, fixed it, and stayed there. That’s a decision which has not been without its own issues like the maverick-backport kernel being basically unsupported and driver updates being thin on the ground. Which wouldn’t be a problem had someone closed the relevant bug, reported against Intrepid, prior to releasing Lucid.)
Anyway. I should probably quit writing and get back to work. Hopefully I didn’t leave any loose ends here.
I think you are missing the point. The reason for the decline in quality is that is that ubuntu is moving further and further away from its upstream (including debian). As long as Ubuntu was basically Debian unstable with proprietary drivers and some patches and themes, it was a great distribution. Essentially it was Debian unstable with greater stability and without the inconvenience.
Now ubuntu has moved away from both GNOME and Debian. It relies on a bunch of half-baked ubuntu-specific features and that’s the cause of the decline in quality.
Ubuntu should get back to doing what it was good at, polishing Debian, and stop developing its own flaky stuff like unity.
thanks ben!
As much as I appreciate fresh ideas for a discussion – I want to work with my computer and not start an endless cycle of updates.
In my opinion the Ubuntu release cycle is not too slow, it is actually too fast. I would recommend to provide users with a more stable and more tested OS instead of implementing feature after feature after feature.
At the moment I like the release cycle of Ubuntu and even if I do not stick to the LTS versions, I like the idea of having the possibilty to use a supported system for a longer period, if I want to. But I NEVER install the new version just after release, because in the last years the new releases becane more and more buggy. So it is necessary to wait for 3 months or more until the worst bugs are fixed.
The here suggested release cycles would lead to completly buggy systems and chase me away from Ubuntu, I would bet on that.
And following the discussion in German internet discussions I think that this is not my sole opinion, most of the users are not happy about such an approach.
As I said: I like fresh ideas and I have no right to critizize you – but I would like to give you my concerns and thoughts for your consideration.
Best wishes and thanks for a great OS!
Frank
This is the worst idea I have ever heard of. Beyond just plain stupid.
Rather than an endless series of untested, completely broken, monthly releases that will never be properly tested or fixed, Ubuntu should have one release per year – and every release should be a LTS release (rather than one LTS every other year).
As it stands now, only a foolish person adopts a current release for anything important – you want a LTS release that is at least a year old (so the major bugs have been identified and fixed), presuming it supports your hardware (and it may not).
i agree with 1 year releases, mandriva has recently taken that approach and stability and support is looking better. Once a year stable snapshot would be great.
But i also agree with the beta/alpha branches proposed here, and these have been well thought out, specially since is coming from a developer himself and knows more than most how ubuntu dev process works.
Pingback: Ubuntu avra’ una nuova release ogni mese? « GNU/Linux Area
AC, Frank, I do not agree. If you need the most stable version for your server of critical business application just use debian or the ubuntu LTS versions. IMO, for most end-users, waiting 12 month for software updates is close to the release cycle of windows and very painful. Linux on the desktop should be about innovation. A rolling release (not the per-month version) accompanied by a LTS version ever 18 or 24 months would be great.
Pingback: The quality of Fedora releases | woah!
#1 Non-techie user like consistency same goes for companies.
#2 Semi-techie users like having the last version of there installed software.
My suggestion is:
Offer ‘Canonical proved’ »opt-in« PPAs for the 50 most used programs (put a check box beside the installed program in the USC) and upgrade the underlying system every 8 months. This would reduce the need for a lot of users to upgrade to a non-LTS version. Having only three releases between LTSs would give some more time working on new features without slowing the development process to much down.
PS: Ubuntu is getting more and more populare. Doing such a radical change as Scott proposes could banish Ubuntu from OEMs list and lable them as a childish crowd.
Having 50 “opt in” packages is essentially having to manage something closer to a bunch of distributions. Can’t happen.
I doubt this will ever happen, although I would be totally for it. I love the rolling release concept, and would still be running Arch if it hadn’t gotten broken on my hardware. But there’s one very large reason it will never happen – rolling releases aren’t sexy. A large part of the reason Ubuntu has gotten to it’s present status is due to the massive buzz generated every six months – “OMG, look what new features are in it now!!!” This is all clever, if annoying marketing, and I doubt Canonical will want to give it up to go for a more sensible rolling release model. Without the constant hype, Ubuntu would have no way to generate the reams of press they currently enjoy, and which I firmly believe is a lot of the reason they’re #1 on Distrowatch.
I think you would still need to have an LTS release. You can’t count on IT administrators to be able to follow and monitor Ubuntu betas in order to plan in advance for a rolling release. Most simply don’t have the resources to do so. Whatever time pressures you may think you have, many IT administrators have far worse problems in that regards and there is nothing they can do about it. That’s why LTS releases exist.
I like the general concept of rolling releases plus an LTS release. However, the problem that Debian has is the transition from “testing” to “stable” requires a lot of bug fixing effort to get the release quality up to par. This is similar to the same problems you have now on the six month schedule, but there is more time for (minor) bugs to accumulate.
In addition, I think that LTS releases should be able to get newer versions of web browsers (and possibly a very few other packages). That would be better than trying to maintain rapidly evolving packages which have no LTS version of their own (and for which security back-port patches may simply end up introducing new security holes of their own).
However, I think you are under estimating the work involved in integrating major “feature merges” (such as Unity) into a rolling release. You’re still going to have feature targets and deadlines, and you will be aiming at a distro which is a moving target. Developing for a “rolling release” works best with small incremental changes. What you might need to do is figure out how to do changes like Unity on a more incremental evolutionary basis, rather than large “big bang” changes.
Generally though, I like the concept.
I like that. Here’s what I would do:
LTS – same as current, every 1-2 years
release – monthly update as Scott has proposed
beta – current (upstream) releases of packages, like Debian testing
alpha – development builds of packages
and use PPA’s for “pre-alpha” packages.
what do you say about that. BTW IANADJAU( I am not a developer, just a user).
I really love your idea. Desktop users definitly need a faster way to get updated software, in the server side i think every sysadmin will stick to the LTS for it’s own mind health. Maybe Debian unstable model might bee a good “tested” way to start.
Pingback: Ubuntu, proponen un ciclo mensual de lanzamiento « Soft-Libre
With due respect, much of what you propose sounds like Debian’s methodology. Debian Unstable packages become Debian Testing packages after no major bugs have been reported, and Testing packages becomes Stable after time.
Debian Unstable is meant only for developers. Debian Testing is a rolling version that would make a very good basis for Ubuntu rather than Debian Unstable. Debian Stable would be very good for LTS.
+1 on using Testing as the basis for all of this.
For a desktop distribution, the plumbing of the system (kernel, xorg, cups, libc, gcc, gtk, qt etc) needs to be updated frequently so that you have the latest hardware drivers. I have often bought new hardware, discovered that it is supported upstream, but had to wait 9 months or so for the package to find its way into the ubuntu stable release. For external projects (libreoffice, firefox etc), where the latest version is just uploaded into the repositories and checked for any system incompatabilities, the 6 month cycle is a good balance between getting the new and not updating too frequently. For this reason, I would be opposed to going to longer than 6 months for the stable releases. On the other hand, the 6 month cycle is not good for introducing entirely new repaclements or heavy reviosns of current software, for reasons you well describe. It only really works for polishing of already functional software (e.g. gnome 2.22-gnome 2.24). A less frequent update, on the other hand, leads to too unstable a system. I often find problems and incompatibilites when dist-upgrading, which I eventually sort out, but I don’t want to have to go through that each month. For most things, the 6 month cycle works well and is much better than either a significantly longer or shorter cycle; the problem is there are a few projects for which it doesn’t.
My solution would be to have two branches for each release, stable and testing. Stable is basically what we have at the moment, except for any undeveloped packages. Testing is mainly a rolling release intended to give developers to make large changes to their code. (It is only subject to the 6 month cycle in the sense that there would be natty testing-main, oneiric testing-main as well as natty stable-main, oneiric stable-main, but the packages are basically just copied from one release to the next at the start of each 6 month cycle, or when the developer feels that he and the +1 release is ready). Most software is mirrored between the two branches; projects which require a longer development cycle are developed in testing according to their own schedule, with the stable release maintaining the software it is designed to replace, unchanging from release to release except for bug fixes, until the replacement is ready.
The plumbing for both distributions is kept identical (and this is where this differs from debian), and updated at the start of the 6 month cycle (and refined as necessary until release); usually to the latest version unless this will break other software in stable. Other software or software maintained externally (open office, firefox, etc) that is mature enough to be maintained in the time frame of the 6 month cycle can also be maintained in stable (as it is now) and will be mirrored with testing unless there is a new approved project designed to replace it. Those projects maintained in stable are only updated for bug fixes etc. or very minor refinements (unless replaced entirely by the package from testing).
Otherwise, testing (intended for major new projects or projects with sufficiently large changes such as unity, software center, gnome shell or in the past KDE 4.0-4.1) is basically a rolling release with no freezes or cutoffs to allow long term continuous development (except for any adaptations needed when updating to the new version of the library or compiler at the start of the release cycle). Goals for development in testing can be targeted for any future release, say 27.10, as seems appropriate for the project. If the developer whose new package is in testing feels that it is ready by the feature freeze of stable, he can apply to have his package transferred to stable to replace whatever it is designed to replace; it is reviewed and if it is deemed to have no serious feature regressions and no bugs which can’t be fixed by release then it is transfered to stable to replace whatever was there before, then it undergoes three months of intensive bug fixing and polishing ready for the stable release; again, it is now mirrored between stable and testing until at least the end of the release cycle. If it is not ready (or one of its dependencies is not ready), it has to wait 6 months in testing for the next feature freeze. Because the plumbing and most other packages are mirrored between stable and testing, there shouldn’t be too many incompatibilities moving a package from one branch to the other.
After release, the developer can choose to either make only small 13 week adustments in stable, or move back to testing with the stable branch basically left unchanged baring any bug fixes or small refinements which can be easily ported from testing.
For example, one would maintain gtk2 and gnome2 in stable, with gtk3 and gnome 3/unity/gnome shell in testing, until unity was found to have no (major) feature regressions compared to gnome2 (even if this takes until 2017 or whenever), or somebody fully ports gnome2 to gtk3 so the libraries can be moved to stable, only updating for security fixes etc. Because it is not in the stable repository and has no artificial deadlines, unity can be worked on continously, avoid the problems outlined in this post, and will hopefully be completed quicker. The drawback is obviously that canonical would have to maintain both gnome 2 in stable and unity in testing until unity is ready; but gnome 2 shouldn’t require too much bug fixing given how mature it was, and you are not looking to add new features.
I’ve always been quite smug about the idea of not having rolling releases for distros. Look at Chrome. Their six week cycle is amazing. It makes for development, constant new features, three different builds allowing you to see what’s ahead, upcoming, and current, is a a rolling release, and is guaranteed to be standards compliant.
It really works, and Mozilla copied to a tee. (including with channels.) The question is, can this work with an OS? I think so..
But I’m switching to completely free software anyway, so
I think this is fabulous. Home users can use the rolling release, enterprise users can update every two years to the new LTS, and server users can upgrade every four years (you will note how there is no reason Scott’s model cannot be extended in this direction). Problem friggin solved!
Note that enterprise and server users don’t want to upgrade, mainly because upgrades tend to not work. But with a rolling release, upgrade paths will tend to be more tested and work with fewer problems. So even they benefit, even if they rely on LTS releases.
Upgrades do work when people are testing long enough and file bugs.
Right now, we do have problems with testing, because enterprise and server people don’t have the time to test upgrades so often, because with a server fleet of 500 and more servers it’s really a hassle to test everything on different kind of HW and SW layouts.
Anyhow there is a difference between desktop users and enterprise/server users.
There is also a difference between app devs for enterprises and server admins.
And this is not so different between linux distros.
Pingback: Ubuntu提议采取按月发布模式 | 开源百科
I solved the update problem a long time ago: I went back to Windows.
Pingback: Will Ubuntu Linux Switch to a Monthly Release Cycle? | Install Ubuntu
Pingback: Ubuntu technical board member proposes monthly Ubuntu release cycle | Tramadol
Scott,
As a developer, adopting a true agile approach (using iterations to add stable features gradually) has improved my productivity and release quality, even with only limited automated testing (legacy code in particular).
Switching from alpha/beta/stable release cycles to true iterations may help you guys and if you are doing iterations ideally they should be pretty good quality and suitable for release to public, so why not release more frequently than 6 months ?
If a feature spans more than one iteration, it still gets built and tested – the parts that can be completed during an iteration, go through testing, but simply not including in the release build.
As someone who looks after a number of desktop machines I personally want to see overall reduced admin time for dist-upgrades, particularly the time having to solve problems due features being released broken.
If moving to a monthly cycle will improve the release quality and upgrading between releases does not need baby/sitting or fixing, this is a good thing IMHO.
I also think that you should consider greater use of backports for those that have to rely on LTS versions, this is as well as or instead of your proposals.
Cheers, Nick.
The actual situation is not working: LTS can be ok for OEM but it’s too old for normal users who want to stay update. Normal release every six months does not work for the reasons explained by Scott: developers have to fit their code into the next release and they will fit it, wether it’s ready or not. This is so BAD for final users because we’ve experienced that this often bring very unstable or incomplete software into Ubuntu.
First thing to do: please separate the server product from the desktop one or release only the LTS server.
You should also separate the system libraries from the desktop libraries. I mean: things like libc ecc… must be very stable, while Unity libraries should be stable but updated often.
Make a LTS every 2 years, just like now, and start doing monthly release. This does not mean that monthly release will be more unstable, because actually if someone want to code the “feature A” it must do it within 6 months. With monthly release if he needs 8 months to code/stabilize this feature it will have all the time.
It’s not true that third party developers would stop releasing packages for Ubuntu: actually if someone prepares a .deb for Debian it works for many releases, so why should not be compatible? For example why VirtualBox .deb for 12.01 should not be compatible with 12.12 one?
Please remember this again: monthly release doesn’t mean unstable software. If something needs 10 months to be ready, it will wait 10 months to be included into stable branch, if it needs 12 it will wait 12.
Pingback: LinuxLife Blog - News: Remnant: Ubuntu sollte monatlich erscheinen
Pingback: New Ubuntu releases each month?
Pingback: NewsFerret Tech » Blog Archive » Ubuntu technical board member proposes monthly Ubuntu release cycle
Rolling releases are great but you do not need to go there just to solve the problems you outline. Also, rolling releases introduce lots of problems you do not anticipate. Many LTS customers value constancy as much as stability.
Changing to upstart, kernel framebuffers, new compilers, compiz, wayland, new databases, new web servers, or the like are gigantically disruptive no matter how stable you thing they are.
I think the suggestion to move significant new feature development to PPA’s gets you most of what you are shooting for. You could still have six month releases as long as you are not trying to wedge massive and incomplete features into them. The releases could plod along as they are, including LTS, with major stuff landing when it is ready.
Of course the PPAs need to inccorporate all the quality messenger you outlined.
Pingback: Will Ubuntu Linux Switch to a Monthly Release Cycle? : Tera Code – Portal Information Service
Pingback: Ubuntu’s Release Cycle « tlohg | gholt
Pingback: A new release process for Ubuntu? | Ubuntu-News - Your one stop for news about Ubuntu
linux mint debian edition seems to want to do something similar on the monthly basis, might be worth studying the pros/cons and see if it would apply to part of the proposal:
http://blog.linuxmint.com/?p=1781
This “concept” is already done! Debian month testing snapshot releases (for the past six months):
http://cut.debian.net/
Ubuntu patches tacked on that release (with security support not currently provided for the Debian version); now that would be very interesting indeed.
Pingback: Ubuntu technical board member proposes monthly Ubuntu release cycle — gadgetmeister.com
Pingback: Ubuntu pójdzie w ślady Chrome i Firefoksa? | Programy Wiadomości
Interesting post, I am not sure how well the rolling release cycle thing that you are proposing will work over time, although I highly encourage investigation, since the quality control story has not been wonderful.
This reminds me of a presentation I saw by Theo de Raadt a couple of years ago:
http://youtu.be/i7pkyDUX5uM
Here he explains the OpenBSD release process, which I consider to be the golden standard to which others should be compared. Anyway, the video is a good one.
Pingback: Рассматривается предложение по выпуску ежемесячных релизов Ubuntu
Pingback: novatillasku.com » Blog Archive » Esta semana en NovatillaSku
I also like this idea, it’s something like rolling release cycle. It would provide some relief to the users from installing each new releases every six months.
Anyway I appreciate the idea. And Ubuntu Team must think about it.
I completely agree with your diagnosis for developers; that 6 months is too short to actually develop and deliver features and/or applications. But guess what. 6 months is too short for users to have to re-install their OS from scratch (let’s face it, distr-upgrades almost never work). At the end, what happens is that every 6 months the users are forced to install Ubuntu releases with half-baked features. I am certain as hell that any shortening of the release cycle will make things much worse. Other than the fact that it’s not going to make server admins and third party developers happy, it’s going to send many current Ubuntu users away.
I think the solution is to have longer release cycles. Once a year for non-LTS, and still once every two years for LTS. This way, the pressure on the devs would be alleviated, third party devs can easily maintain their PPA’s , or package their software, and the users can have a system that just runs for at least a year without major maintenance. Effectively, we’d have a release every year, one non-LTS, followed by an LTS, followed by a non-LTS, and so on. If you give 2-year support to non-LTS, 3-year to desktop LTS and 5-year to server LTS, non only you would reduce the number supported releases at any time to 3 (from 4), you’d have a longer support time for non-LTS releases. This would eventually increase the overall quality in Ubuntu and its perception.
I doubt if this change would keep Ubuntu’s releases stable. And I don’t want to download 650MB of updates for all my PCs.
Pingback: ¿Pasará Ubuntu Linux a un ciclo de lanzamientos mensuales? | PC World Perú
Great article. You state correctly the problem, ubuntu is losing user confidence because it gives the feeling that is an unfinished product.
On the other hand, I’m not quite sure on your monthly release schedule, I don’t have many problems with updates but with upgrades, and upgrading every month surely be a pain.
My suggestions?
1. LTS every 3 years, supported 4.5 years on the desktop and 7 years on the server. Enterprises and OEM’s would surely love this.
2. LTS should be considered “stable”
3. Non-stable releases every 9 months. Not considered “Final” or “stable” releases, only “milestone” releases.
4. Version numbering: LTS should be Ubuntu X.x, “Milestone” releases should be “Ubuntu X+1.x MS 1″ to “Ubuntu X+1.x MS 3″. Next LTS should be Ubuntu X+1.x Final
5. In other words, NON-LTS should be considered as Alpha, Beta and RC.
6. New and revolutionary changes(aka, Unity, Gnome-Shell, Window buttons side change, theme colors) should be implemented on NON-LTS and fully corrected before the LTS.
7. Essencial software (As Firefox, LibreOffice, GIMP, LyX, Inkscape) should not be in the official repos, but added as certified PPA’s so they continue upgrading freely in the 3 year cycle without affeccting the system. IF any software upgrade may change drastically the system, it should be frozen and tested on the NON-LTS releases until it gets corrected.
8. NON-LTS releases lose support after the next release, so only 2 releases are been supported actually, the LTS and the current Non-LTS
9. Milestone releases should be rolling releases, LTS non-rolling.
10. (Conclusion) By doing this way, The “Final” or LTS should be for everybody (Home users, Enterprises, OEMs) Milestone releases are more for the adventorous users, sacrificing stability for cutting edge.
THX
As a app developer, it is completely unsatisfactory that I am not in control of the version of my application that users use.
If I release my software now, and upload it to debian it will be 7 months before that version gets into a stable ubuntu release, and users will be stuck on that version for another 6 months after that. (that’s over a year)
If I find a major problem with my software and fix it there is no way for me to roll out a fix until the next cycle ( > 6 months) this is unacceptable to me as an app developer.
Yes I can (and do have) a PPA. But this is an advanced feature which is not a solution for your average user. The user has to add this manually.
Both android and IOS allow app developers to update their software when ever they want and have that update rolled out to all users. And it will be surprising for you all to learn that this does not cause the world to end.
The current process constitutes an unacceptable risk for application developers.
totally agree!
we will need a development process and release cycle that is capable of supporting/pleasing … 200 million users, and ultimately large vendors.
the problem i see with the proposal is;
steam, adobe creative suite, and (insert some other random large software vendor that doesnt currently have a nix port) all decided that with 200 million users creating a linux port is now “worth” it. SO they create a stable working version of their current offerings that works on 12.04, but when 12.05 is released it breaks dependency’s and blah blah blah … this would most likely scare off any vendor to begin with. I could see a whole new world of back scratching. Ubuntu now with the new cool release and dev process for some reason never implements any updates that breaks software of large vendors … oh i wonder why.
these large vendors would have to sink a large amount of work into maintaing their apps to stay current with the proposed fluent release process.
Sooo, basically you invented Debian ?
If there is a need, the development cycle should be extended to something like PabloCampis proposes – 9 months or even a year. LTS’s could come out once every 3 or 4 years and be supported for 5-7 years.
But i promise you this – switching to what you propose, will make it easier for development and worse for administrating ( speaking as a server administrator here, couldn’t care less about desktop ). Having to constantly stay up-to-date with new features, API and config changes, when you have a few hundred servers is something that most people like me would like to avoid. Switching to a monthly push-out, will just create 2 things :
1. Ubuntu fork with stable release cycle ( like current LTS ).
2. People switching to something not-so-rolling – Centos ?
Stop thinking only about the desktop users when you propose stuff.
Why “cycle” in the first place? Release CDs/DVDs as you see it fit, which are just snapshots of packages in your repository. And maintain your repository as rolling release — when package A is built, tested, passed review, simply put in the repo. It is and old idea, and it is pity, Ubuntu (and many other distros) still stick to outdated model of “release every N months”. Instead think in terms on packages, not entire distro, and ship when ready — every package. This is what makes rolling release.
I hope I will see some day (i.e. before I die) Linux distro with:
* rolling release model
* self-contained packages
* rollback package install feature
Pingback: Ubuntu Switching to Monthly Release Cycle Like Firefox? | Siti News
I just think it is great that Ubuntu is going with this concept. I know Linux Mint started doing that with their Debian edition. It is more or less making Ubuntu a “Rolling release” like Debian. I think someone in Linux Mint called it a “Rolling Snapshot”.
More or less this allows them to still be cutting edge while having a stable release cycle. This means that things are likely to be fixed in a month or two instead of six months to a year.
They can still offer their LTS cycle, but do not have to designate a specific version of it. They can no say: “Ubuntu 12 LTS” instead of “Ubuntu 12.10 LTS”.
@Eylem – “let’s face it, distr-upgrades almost never work”
They have always worked for me. Then again, I try to wait 2+ weeks after a release, mainly for the mirrors to regain their speed, but bugs are probably shaken out in that time as well.
Hey you guys, I have a better idea, release a new version of Ubuntu every 2 or 3 YEARS. So you will have TIME to development and testing and stuff.
Improve the repositories so I can use the latest version of my favorite apps like Firefox, LibreOffice or Wine.
And, for last, I suggest to introduce something similar to a Service Pack, so I can update my Ubuntu easily and without breaking a thing.
I don’t see the problems with this Rolling Release proposal that others are speaking of. The real problem is in people’s unrealistic expectations of the 6-month Ubuntu releases and what “kinds” of users will be and should be using it.
First off, both Microsoft and Apple produce a new OS version on roughly a 3 year cycle. Remnant’s proposal would keep the Ubuntu 2-year LTS release. So what’s the problem? How would the LTS releases face any new problems? The proposed monthly release schedule would help further stabilize the LTS releases.
Second, the Monthly Releases should not be looked upon as “The Ubuntu Release.” They can come from the release channel. But this doesn’t mean the majority of users will be using the monthly release. The users that gravitate toward the Monthly Release will tend to be “computer geeks” and the “computer literate.” New features would roll in when they are ready. To address the Firefox analogy, So what if an Add-On stops working because of an update? The important Add-Ons will remain functional. For example with Firefox, both Adblock Plus and NoScript have remained operational with new Firefox releases. More importantly, the “broken” add-ons will surely be updated and functional for the LTS release every two years.
Finally, the rolling releases will fix the huge amount of bugs and lack of stability that plagues Ubuntu. It will give developers more time to “perfect” and “realize” new features. THE MAJORITY OF END USERS SHOULD BE FOCUSED ON USING LTS RELEASES. UBUNTU SHOULD BE “RECOMMENDING” THE LTS RELEASES TO USERS. The users that know what’s going on will know that they want to use the Monthly Release. The majority of people in the world use Microsoft Windows which releases every 3 years. Why doesn’t Canonical expect the majority of its users to use the LTS release? The technically minded and computer tinkers out there will be using the Monthly Release. The Monthly Release schedule is perfect. It caters to both user populations: the computer savvy and the non-technical majority.
The resistance to the monthly release proposal, I think, is because people have unrealistic expectations about which release users should be/will be using. As I said, Canonical should be “Recommending” and encouraging users to use the LTS release. And the LTS release should be viewed as the Ubuntu Version that the majority of users see. An Operating System (which ties together so many disparate parts) is not the equivalent of a web browser. But an Operating System release schedule that releases monthly with a target of an ultra stable release every two years is an ideal balance of getting new features out quickly, AND producing a stable/solidified/unified release for the majority of users who just need a stable OS to run a computer so they can get their daily work done (i.e., computer users who don’t necessarily have an interest in computers).
Remnant’s proposal would take Ubuntu to the next level and dramatically IMPROVE everything about the distro. However, I’m worried the powers that be are going to keep Ubuntu on the broken & unstable trek it’s been on.
yes, lts releases should be the ones recommended and offer users the latest versions of the apps they use when possible.
and yes, they seem to keep postponing and postponing a solution to this very old problem…
Well, from my point of view, everybody likes software updates. A handy little tool which gets new features or a web browser which solves some bugs (or gets WebGL support for example). An OS is a software too. But it is a different kind of software. It’s your environment, the place you work or play in. All other software works in that environment. I switched to Ubuntu from Windows7 for stability (yes I think unix system are more stable). But it really starts to irritate me. For example, my internet connection is 1Mbit/s GSM, and I pay for the data transferred. Updates? Don’t get me started, it’s a pain in the ass when you have 200MB of updates per week on a GSM 1Mbit/s connection. And now in this post you suggest the whole system should be updated more frequently? That’s just a bad joke.
In work I also use Ubuntu. Every system update I had took about 1-1.5hrs. I don’t think my employer would be satisfied with me wasting my time on updating the system everymonth + normal updates.
And yes, I’m a geek, I really like to check new software, tweak something, but it really is irritating when an evironment get’s in my everyday geekiness. I will gladly switch to WindowsXP at work and Windows7 at home if there will be a new ubuntu everymonth, but for now I’m just considering it, because for now only the frequent updates get in everyday OS usage.
This idea is very exciting…..i like it!
Why not just use OpenSUSE’s model – 8 month release cycle..
3 releases every 2 years with the third one being an LTS that solves everything..
Gives developer enough time, users a stable system with new features, and a new version doesn’t pops out when you were just getting used to the old one (well with current model ubuntu users don’t use it they just upgrade it) , also it creates more publicity as you’ve been waiting more than ever but not like forever for the new release.
One more thing openSUSE might not seem to benefit from it but believe me Ubuntu will.
less frequent releases (for the stable version) looks better overall:
either 8 months (like opensuse)
or once a year (like mandriva).
ubuntu really needs to cut down on supporting so many old releases and make it easier for everyone.
Pingback: Canonical planeja lançamentos mensais para o Ubuntu « Blog Seja Livre
I don’t use Ubuntu very much. One of my desktop runs Fedora and the other used as server run Debian stable. I have used ArchLinux for a couple years on another (now retired) laptop also.
1. Now, the problem with monthly and rolling releases is bandwidth. Most people simply don’t have bandwidth to keep downloading major upgrades to packages every month. And in the kind of schedule you say, it’s inevitable there will be huge downloads every month. Ubuntu shipit program was a huge success because it put Ubuntu into hands of people who didn’t have the bandwidth to download the CDs.
2. So what about updates to packages in between? Do you handle them like arch (purely rolling) or push them out in the next month cycle?
3. Unlike Arch/Fedora, Ubuntu modifies upstream a lot. It could simply be difficult to keep with the modifications every month.
4. Any major change that occurs (kernel, xorg etc) will break stuff. Arch/Debian stable and Gentoo are all targeted to experienced users who can do the occasional fix from the command line. Their configuration systems (specially ArchLinux) is very simple and straightforward in plain text files. Ubuntu however, is targeted towards a different/wide set of users. Most of them simply would not be comfortable fixing stuff every month.
What this would result in is that users would migrate to the LTS releases and stay there. Vendor/OEMs will support only LTS releases of Ubuntu and gradually only developers will be using Ubuntu. Even some of the experienced users will migrate to Debian testing or unstable.
Should you consider using another rolling release as the *only* productive system, you’ll give up within a couple of months for sure. It will just get in the way of getting real work done.
All in all, I like the idea of more frequent releases.
Too often, I have moments like: Oh, MongoDB 2 was released this september, now I have to wait 7 Month (and maybe even 13) to get it. Thank got I use a PPA for that.
The problem here is to deliver upstream versions faster. I’m glad Ubuntu figured out how to keep up with mozillas rapid release cycle, but there are a lot of packages that could profit from more timely upstream->distro migration.
You are talking mostly about the developer perspective, which also benefits from a mozilla-like rapid release cycle. Develop in peace, land a complete and non-broken feature and be sure it will just move through the stages and be in the hand of users 12 weeks later.
From my own perspective, I can also tell that the quality of the releases, especially the prereleases deteriorates. While I could just happily install an alpha-3 a few releases back, now the beta frequently breaks.
The problem I see that hinders such a release cycle is interdependence. Lots of stuff depends on other stuff being available. Ubuntu already skipped gtk 3.0 and went for 3.2 instead. So how is it possible to make rapid releases with all those dependencies?
I prefer something like this:
-Two year LTS cycle
-Desktop supported at least four years
-Server installation and all libraries and components required by third party developers must be stabilized at least six years.
-User interface changes must be minimal at least six years.
-All releases must follow newest LSB standard and offer newest Java platform at release time.
How this can be achieved I propose this:
-Applications top of system foundation may upgraded six month cycle. Then it is not necessary to patch them for security reasons.
-Amount of packages in repositories may be reduced to get better cohesion, loose coupling and less crap to maintain. Some quality control for packages to get in distribution would be nice and packages should be able to develop more easily without coupling them with unstable system libraries.
-Preview releases should be abandoned or support should be limited to minimum. Some gradually stabilizing development branch without security support would be nice.
At the moment, I only use LTS releases for my desktop. It works really well for me as it seems secure and I don’t have to reinstall the whole OS every six months…
The only problem I have with LTS is that there is no easy way of getting cool updates quickly like unity for example.
If the new proposal can fix this, that would be amazing!
Full aka. Plus LTS cycle of course. If this gives developers more time, introduces less bugs and more stability, Ubuntu will be on the right track again. As in the OpenBSD video above, maintaining bugs isn’t funny. Lets hope this isn’t going to end like all the other previous discussion about URC.
In addition, finally make incremental updates possible, considering less bandwidth, but benefits all users worldwide. Thanks.
I translated your proposal for the French Ubuntu users and I give you my full appreciation for it. Truth has to be told, kudos for saying it.
If I may, I have some questions:
- does your proposal of monthly release derives partly from the – rather successful – new LMDE “latest” and “incoming” repository experience?
- you have not been designated to stay a member of the Ubuntu technical board for the next term (2011-2013). Due to your released study, it seems as if you were candidating for it. Do you plan to attend the UDS nevertheless and to express your views there ?
- What would be your percentage guess of Ubuntu switching to a non-semestrial release cycle after the 12/04?
I will comment your new short stories in their own place.
Roger
Pingback: S04E15 – Remember Tomorrow – MP3 HIGH | Ubuntu Podcast from the UK LoCo team
Pingback: S04E15 – Remember Tomorrow – OGG LOW | Ubuntu Podcast from the UK LoCo team
Pingback: S04E15 – Remember Tomorrow – OGG HIGH | Ubuntu Podcast from the UK LoCo team
Pingback: S04E15 – Remember Tomorrow | Ubuntu Podcast from the UK LoCo team
Pingback: Новости компьютерного мира - Рассматривается предложение по выпуску ежемесячных релизов Ubuntu
this bug needs more attention:
“Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS”
https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/578045
I think a faster release cycle would be good. especially as kubuntu user it makes me angry every time a new release come closer. The new KDE major version is published and not upgraded in Kubuntu (without ppa – and with version from ppa often there are some little problems) You should devide release cycles from desktop and server version then of course. I like the release philosophy of chakra for example but it is not as userfriendly as kubuntu in my opinion.
interesting article, thank you.
11.04 is a prime example of a bad ubuntu release. unity wasn’t ready for example. it was the vista of ubuntu releases. take a look at the mint releases based on ubuntu; they are usually better and smoother out of the box.
i would love to see a yearly ubuntu release instead of 2 minor and usually too broken releases. who remembers those numbers and silly names anyway besides linux nerds?
ubuntu 2011, ubuntu 2012… now that’s something to remember.
make an LTS of the server release only, every 2 or 3 years.
there is no need to make an LTS for the yearly release of ubuntu for personal uses, if you up the quality level of the release compared to now.
I honestly don’t think there is much wisdom is migrating to a faster release cycle process. As it is the 6-Month Release Cycle keeps lots of Debian Users from making the leap to Ubuntu.
Here’s my idea:
1. Eliminate normal releases, leaving only the LTS releases. The LTS moniker should be dropped. The version numbering should stay the same, since having everyone constantly be confronted by the month of the release would help prevent the date from sliding.
2. All editions of the LTS releases should be supported for 5 years. Even through that’s 2 more years on the desktop, that’s 1 less release than the situation today.
3. LTS releases should by default have a stable platform with rolling applications, but updates should only be released when ready. All supported releases would get equal priority for bugfix and security updates, but the newer ones would get priority for feature updates. There should be an option to freeze the apps, for those that want it.
4. There should be a public preview of upcoming releases. The preview could be a rolling release representing the current state of development, but the final release would only include the software that’s ready, so what appears in the preview wouldn’t necessarily be in the actual release.
5. The incentives to developers would be granted only when the software or project is ready, with a very high standard set for that. There would still be an incentive to finish quickly in order to get the reward as quickly as possible, but there would no longer be a rush, as a rushed project would just get shot down.
Pingback: Canonical planeja lançamentos mensais para o Ubuntu | Blog Seja Livre
Pingback: Ubuntu eyes speedier releases | Install Ubuntu
Interresting idea.
My conclusion of all the comments so far is; look at the phone platform Markets (or OS X App Store even). Maybe “Ubuntu” should stay as the basic operating system and every “app” has it’s own repository (where ppa is already very common today)?
With Android-like security to dpkg the developers might very well be able to take care of their own repositories. They will also be responsible for making it compatible for different Ubuntu version, which release cycle could then be increased to maybe a year?
I do like the idea of Android where the OS is limiting what harm could be done from an app, and the developer is free to do any upgrades.
Apple, on the other hand, requires every new version to be reviewed prior to any App Store release. This is pretty much as Ubuntu works today, really.
What about at least separating the base system from “apps” where the latest app is always available but system critical updates might be isolated to the yearly releases?
Pingback: Ubuntu 11.10
I don’t have time to read all the comments, but as a ubuntu NOOB, you have addressed most of my issues with ubuntu.
I love using linux, but it is so dissapointing to be waiting for all the cool new features, and after you install the updated version, it breaks half the software I use and all the new features don’t work.
Unity is 1 year old (since the netbook edition), and it still is broken. Half the time I have to minimize all windows to access it, I have problems with the top bar or when I find a workaround for one of the countless issues, there’s a new update and I need a new workaround.
Ubuntu 10.4 was great, fantastic in fact. And I think Unity would have been a lot more appreciated if it was realeased in a working condition.
New users will love 10.4 (that’s where I started), but I know I wouldn’t have stood a chance if I had started at 10.10, 11.4 or 11.10. no matter what the press coverage.
Ubuntu’s biggest problem is not getting people to ry it out, but getting people to CONTINUE using it.
I will reinstall all my computers with 10.4 until Unity works flawlessly. Maybe even another distro??
What the article seems to be talking about, is the INTERNAL problems at Canononical leading to unstable/not ready for release features being included in the 6 month releases. I absolutely agree Unity was not ready for prime time, but YOU CAN TURN IT OFF!
I use Synaptics package manager, and can update any of the software on a version (basically I have the XFCE interface installed, so you might call what I’m using a customized Xubuntu) independent of a Ubuntu release, anyway, such as installing or regressing Firefox, etc. It’s what package managers are FOR.
As to the OS release version, new capabilities are added but should ONLY be added if stable. Typical users (who may be migrating from another OS such as Windows) do NOT want to see broken software, nor do they want to mess with re-installing or upgrading very often, typically before they’re even used to using a current version.
“Bleeding edge” only works for techies. Companies, and casual home users, need a stable OS with stable packages added on, without sweeping changes, or even unnecessary minor changes!
Do as you like with the Ubuntu releases within the company, but make SURE the newly released versions, whether they be the 6 month release, or the 2 year LTS release are polished, stable, and contain no sweeping changes unless you can turn them off and revert to a previous behavior.
Thanks, Scott.
I am an Ubuntu desktop user and I have noticed a definite degradation from Ubuntu 10.04 LTS to 10.10 and a slight improvement in 11.04 but it’s not as stable as 10.04 LTS.
Also, after an online upgrade on my friend’s PC from 9.10 to 10.04 LTS completed about an hour ago resulted in the boot hanging apparently due to some file corruption.
He now wants to install Windows.
While 11.04 has some new features, I don’t feel it’s as stable as 10.04.
Your article on Canonical’s development requirements forces developers to focus on being paid rather than to produce quality. What’s wrong with holding off the release of new features and applications until they have been tried and tested to work well, rather than release them half-baked.
Quite frankly, I’m losing confidence in Ubuntu, after having been a strong advocate of it and I may shift to another distribution, such as OpenSuse or Linux Mint Debian.
Stop telling me that there is every 6. month a new stable ubuntu version. Thats not true. There is only one stable: LTS. The other **** is just a buggy alpha for testers. So they could really change it to RR, that wouldnt change anything. The LTS is fine for the most of us, the only anoying thing is to upgrading the kernel. Sometimes LTS Ubuntus got a crapy old kernel…
Doing this would KILL Ubuntu and all it’s deriatives.
Pingback: Ubuntu, discussão sobre Liberação de Alfas e Betas sem “congelamento”
Pingback: Новости » Blog Archive » [recovery mode] Canonical всерьез задумались об отказе от полугодовых релизов
Pingback: LinuxLife Blog » News: Erneuter Vorstoß zu Rolling Release bei Ubuntu
Pingback: Ubuntu Linux developer squabbles go public | nano Geek