<div class="gmail_quote">2008/11/10 Eric Springer <<a href="mailto:erikina@gmail.com">erikina@gmail.com</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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?</blockquote><div> 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. </div></div>