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