Staring down the scarecrow; should ubuntu roll?

After being away and enjoying some lovely downtime, I've returned to the online world to be met with the rush of a virtual UDS, a rolling release announcement, and a new windowing stack announcement. With the discussion advancing and the UDS sessions completed, it's time to weigh in and speak my thoughts as well.

I'd like to stare down the scarecrow -- that is, let us examine the straw man argument of a rolling release.

On a rolling release
I am definitely in favor of streamlining what we ship and support. The inter-LTS releases in general only make sense to run until the next one arrives. From a quality perspective, I really like what we've done with precise. I think it's an excellent solid base and the point releases we've done keep it relevant and offer a really nice way to get the latest stuff and keep a stable and long-term supported system.

As for a rolling release with LTS's sprinkled in, I have run a rolling release distro in the past (alongside ubuntu). I definitely enjoyed having access to the latest stuff, and having everyone on the same archive all the time (community-wise) kept us tighter and more able to relate and help each other. Overall, I think the pros outweigh the cons on moving towards it, but I have several caveats with the current approach.

• Monthly snapshots
• As Colin Watson put it, if we're presumbly releasing and testing a monthly snapshot, we failed in a rolling release sense -- we don't have daily quality.
• In general, I don't see a target audience for a monthly snapshot. Why can't we create an installer image (do full testing milestone on it), then call it gold for a long period (until new installer changes we want to bring in, which require us making a new image). In other words, I would like to see us only generating new images for an actual release (in this case only LTS's), or for a new installer. (Note that I mean supported images (in any sense), not just an image for testing)
• Quasi-rolling mentatility
• It seems like we want to support the idea of users running a snapshot of our archive on a certain date, and then only update at certain days and times
• This is insane fragmentation and defeats the purpose of being a rolling release. People should strive to run up-to-date systems, and always be current. For us, we need to ensure the archive is always upgradeable so they can do so
• LTS point-releases
• Continue and enhance point-releases for LTS to keep regular flows of new, well supported and stable software
• This was discussed and well noted in discussions and at UDS. As I mentioned, I really like how precise is going, and we can continue and bolster these efforts even more in a rolling world.

On flavors
I will prefix everything I say here with the fact I have never put together and supported a flavor, but I most certainly have enjoyed utilizing them, and working with members of the community who focus there efforts on them.

I was able to catch the end of the UDS session on flavors and had an excellent discussion with some folks from xubuntu and kubuntu. Thanks to those folks who helped provide some flavor feedback on the proposal.

I would like to challenge the flavors to engage in healthy discussions about how there release process works, how to serve the needs of there users, and how to make the best use of there time and resources. I'm sure this type of introspection happens in each flavor on a regular basis, but I'd like to call special attention to how releases work.

Last cycle, ubuntu adopted a cadence for driving quality into the daily images. This work has been on-going since precise really, and rick's idea's for a rolling model continue this line of thinking. If you'll ask the community folks who helped be a part of these cadences, they can tell you it was a challenging change, but we're really hitting our stride now. The constant iterations on how we test and what we do I think had been extremely positive towards helping quality make a bigger impact.

With that in mind, our release processes shouldn't be exempted from this. QA (and development :-) ) efforts are seen as linked to the current release process, resulting in chaos if you are radical enough to unlink them. So what options (in my opinion!) of course exist for a flavor in this new world?

• LTS only
• Some flavors have already gone to an LTS only model, and I think it's been extremely helpful for those who've done so, in terms of what they can focus on without worrying about supporting lots of releases.
• Rolling only
• You can chose to go full force into a rolling release, and eschew LTS's altogether
• 2 year "normal" releases
• You could choose to simply push a new image out every 2 years (like an LTS), but without long term support. Instead, consider supporting until the next (2-years or so) release.
• Keep things as-is
• As kubuntu and others have shown this cycle by not adopting a cadence for testing, you can keep the traditional model in place. The buildbots are still there, the testing tools still exist, and the knowledge and experience in releasing on a 6 month cadence is there. Remember, ubuntu itself has synced from upstream debian every 6 months; a flavor could choose to do the same with ubuntu.

Now of all these options, at this point I would personally recommend adopting the LTS only model. Work with and sync your development to your upstream project and land your work in the rolling release. Release an LTS as normal and deliver timely point release updates to the LTS. There is nothing stopping you from even delivering these point releases every 6 months (or a different timetable!), emulating the current process but with a stable ubuntu LTS base and a simplified upgrade process.

On some alternative ideas

6-8? month-stable releases between LTS

Not a bad idea for retaining the flavor of the current system. Indeed, if you really like the idea of monthly snapshots and updating, this is probably the better way to do it. However I don't think it solves any issues for an OEM or for flavors. Namely, the release support timeline is too short for an OEM to base an image on, while for flavors, it would force an even faster cadence and churn upon users. I also don't see a target audience for it. Who would run this, but not run a rolling? Folks who want stability couldn't adopt such a small supported time-frame, and I feel like our efforts to test and release would be wasted as we throw it away as soon as the next stable is out.

Don't change anything!
This idea is just a knee-jerk reaction to change. Unless you feel like our last release was the pinnacle of perfection (I don't), we should be evaluating how we do things, iterate and try and do them better. 

On quality in a rolling release
I want to talk specifically about quality as that's what is dearest to me. How do you ensure quality in a rolling release world?
 
First, I would like to challenge you on what you mean by quality. Is older software better quality than newer software? Age != quality, even though we often traverse down that slippery slope. I wrote about this before, but simply put how we define quality is subjective. For the sake of comparison here, let's talk about quality as having a desktop that just works. That is, your hardware works and the applications and software running on it enables you to accomplish your tasks without issue.

So, with that in mind, how does that work in a rolling release? If you've run the development versions of ubuntu in the past, there have been times where a bad package may have rendered your system unbootable. For any user trying to run this as there daily system, it's obvious that level of 'quality' doesn't work. But at the same time, I've found bugs running the development version of ubuntu that cause actual crashes (see this for example), yet have little impact (if any) on my system working properly to enable me to accomplish my tasks. So how can we define quality metrics (and we should!) for each release? Here's a quick summary of my expectations in extremely simple terms:

• LTS
• No issue that hinders or prevents utilizing ubuntu
• Rolling
• No issue that would cause a crash for expected usecases and workflows

The key difference to me is usability. If I am forced to use a workaround for a crash in a minor application or task in a rolling release is probably ok. Note that I say probably, because well, we haven't defined these metrics yet as a community. Being forced to do so in an LTS is not an acceptable level of quality. And of course, causing a system to not boot is never acceptable.

On the reaction and the future
I'm excited to see these discussions taking place, and I would encourage people to think critically and take part in these discussions. There are definitely some wonderful ideas and conversation taking place.

Just remember we're a team and all part of ubuntu. Healthy debate is a very important part of continuing to better ourselves as a community and project.