I'd like to add a few points to this that I feel haven't got much 
attention. Before I do, however, I'd like to explain that while I have 
used Ubuntu for a long time and paid attention to the development 
process, there are so many things that know very little about. For that 
reason, I don't really want to go into the pro et contra of the interim 
vs rolling releases from a technical point of view, but rather from an 
observers point of view. <br><br>It's about the enthusiasts. Not the 
curious, but the ones who have been using Ubuntu for a very long time 
and are decidedly into it. In the past, these are the kinds of people 
who have begun installing Ubuntu from a late alpha or early beta stage. 
They've been committed to filing bugs and are willing to experience some
 breakages, but want their systems to be fairly usable. To these people,
 the pre-releases have been the highlight of the season. However, in the
 early stages of development, things have been too confused for them to 
get involved and in the late stages, developers have been too busy 
getting things in place for the release. That means they've always been 
limited to a status of perpetual observers or testers at best. Every six
 months, there'll be a couple of weeks when people feel they're in the 
game, but that also means most of the time, they won't. If you want to 
learn something, you need to practice and then repeat. <br><br>One 
benefit I see from the rolling releases idea, is the possibility for 
developers to take a bug, announce that it's now being worked on, and 
enable people to tag along for the ride all the way from bug report to 
release. Of course, this means there has to actually be a release. A 
monthly snapshop can act to this purpose. The curious will install the 
rolling release at a snapshot and then install updates at regular 
intervalls along the way. But they are aware that things might break and
 are willing and able to fix or perform a work-around for those cases. 
Using btrfs might be helpful in that regard, since it could give them 
the ability to easily undo an upgrade. I see that as a prerequisite for a
 rolling release in either case, because you have to expect some people 
to suffer horribly from time to time. Bugs exist. If people can reboot 
and revert, it's not such a big deal if something _does_ break horribly.
 A boot menu option to "pretend today didn't happen" would allow more 
people to join in early. <br><br>In many cases, insightful people will 
be able to make an educated guess as to how difficult it will be to fix a
 bug. So label it properly before the work starts, write an introduction
 containing languages used and what the work is expected to look like, 
when it's estimated to arrive in rolling, etc and allow people to 
subscribe to these events. When applicable, schedule bug specific 
meetings so that hangarounds can ask questions,  become more enlightened
 and discuss among themselves. At the end, you'll have a well 
documented, real-life development story for people to study. With a 
library of these, journalists and technical writers will be able to use 
these as starting points for articles or even chapters of a book. The 
curious monthly-upgraders will be more cutting edge while the dedicated 
enthusiasts will have a chance to be a bigger part of the process. This 
enables bragging rights, particularly if there's a chance of getting 
your name in the release notes. Some bugs might also be useable in 
school projects, such as backporting a bug to the most recent LTS. <br><br>If
 this sounds horribly naive, it's because it is and I am. But from 
experience, I think the naive perspective can often be quite useful. I 
hope this was, and I thank you for your time and attention. <br><br>Jo-Erlend Schinstad