Follow Up from "Let's Discuss Interim Releases"

[Jo-Erlend Schinstad]

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.

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.

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.

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.

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.

Jo-Erlend Schinstad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130308/597d42c7/attachment.html>