Re: Proposal: Rolling Release

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





2008/11/10 Eric Springer <erikina@xxxxxxxxx>
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.
-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux