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
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel