Proposal: Rolling Release

[David Nielsen]

2008/11/10 Eric Springer <erikina at gmail.com>

> Fedora has always lead the progress of FOSS by closely following
> upstream and making non-trivial contributions. I see this is a great
> strength, and like many other people it's my primary reason for using
> it. But it's not without trade-offs, such as giving Fedora a
> perception of being 'beta' software and balancing new software without
> burning the large user base is not easy either.
>
> This hit home today, after being impressed with the work you guys have
> done with plymouth, I did a quick Google search[1] to find out a
> little more. The first result is a "Ubuntu brainstorm" page[2] about
> implementing it in their own distribution and the second comment is "I
> support the idea but I do think that it should only be considered
> after Fedora has done all the dirty work of getting it to work". This
> is no way intended as a criticism of a Ubuntu, but it's a realization
> that distributions like Ubuntu are able to offer a better user
> experience by using stable software on a longer support cycle.
>
> So what I propose is that Fedora goes to a rolling release cycle.
> Implemented properly I believe we can better achieve Fedoras
> objectives[3] of rapidly progressing Free Open Source Software, while
> providing a more user centric focus (and bringing something new to the
> easy-to-use-table). While I would prefer to not get bogged down in the
> technical details at this stage, we would need to provide software in
> varying levels of stability.
>
> Perhaps something like:
> hemorrhaging -> rawhide -> stable -> rocksolid
>
> Users should be able to very easily and freely move through the
> levels, especially on a per-package basis (with PackageKit). It should
> also be easy for users to "freeze" their system/package to only
> receive security (and optionally bug) patches, as many aren't
> interested in the constant upgrade cycle.
>
> New features/software/functionality would be easily tested by the
> masses without needing to upgrade the entire distribution. It would
> give the open source community a massive user-base they could call
> upon to test easily.
>
> The average user would sit at the 'stable' level while perhaps
> testing/using a few of their favorite software from rawhide. Servers
> would typically sit at the rocksolid level, and use stable packages on
> a needs-only basis.
>
> Thoughts? Flames? Ideas?


We already have a pretty much rolling release, and in many cases it serves
us best to attain stability. Take an application like Banshee, typically
only the latest release will be supported upstream, keeping one version for
a long time will thus not do our users any favors. Many applications are
like that today, we really need to supply the latest to lessen the burden on
maintainers. The same way with frameworks such as Mono (or KDE, GNOME),
upstream today generally has good QA and if it's deemed stable enough for
F10 then it should also be for F9. If something cannot be backported to
earlier releases for stability reasons then it only has a place in rawhide.

Keeping the same platform across releases will cut down on the amount of
code we have to maintain and it will keep our users supplied with the
applications they crave.

There are distributions that does this, Foresight Linux e.g. and they are
incidently greatly helped by Conary in this way of working. Gentoo also does
this. Neither camp has ever reported serious issues with this approach to
releasing updates and it seems generally appriciated by their users. It does
though diminish the idea of a release, and would require much greater effort
in QA underway (and find a convincing yet reasonably safe approach to con
users into enabling updates-testing to smoothen the roll out of big
updates).

I, for one, really like that I can install my F9 desktop and be sure that
most of my applications are up to date, and in terms of maintaining I always
did my best to keep the packages the same regardless of which release it was
on simply because it was much less work supporting and confirming bugs this
way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081110/8fd02f78/attachment.htm>