On 01/28/2012 07:42 PM, Noah Hall wrote:
Fuduntu Dev here.
...
Fuduntu didn't start out as a rolling release. We had versions for a while, until we realised we were basically releasing newer snapshots of our current software with slightly different defaults. Having discussed it as a team, we decided to move to rolling - less work for us to handle the repos and create images, less hassle for our users to reinstall with each release just because we'd changed some default package or updated something vital to a newer version. Our users could just update, and we could just create images. Simples. The transition was painless. I can't say I noticed much fallout, if any. Perhaps fewt can remember some, but I can't. Our distro is pretty stable, with new software - something that's a treat in the Linux world.
The argument against rolling upgrades is that it's a wonderful idea early on, but then you run into a morass as time goes on, because of:
- difficulty of handling wanted vs. unwanted updates, which in turn creates combinatorially growing number of config permutations (Gnome 3 yes, GCC 4.7 no, KDE 3 no , kernel 3.x yes, etc.)
- cruft resulting from rolling upgrades trying to preserve old customizations and 'old way of doing things', as opposed to installing latest shiny stuff from scratch
In other words, you have to wait a while and think long term to truly evaluate a rolling upgrade. You have just started, and things are going swimmingly for now, but the clouds are gathering.
I believe that the problem with the current system is lack of long term support, i.e. what happens on the trailing, rather than the leading, edge of upgrades. I can afford doing manual upgrades to the systems under active development. It's the working, stable systems that I don't want to touch, but obviously I need security and other essential updates.
To solve that, I'd be nice if there was a way to roll over an EOL version into an appropriate release of one of the long-term-supported systems such as RHEL, Centos or Scientific Linux. Without this option, it's hard to deploy Fedora in a long term fire-and forget capacity, because I know that every one of them will require manual upgrade or rebuild when it goes EOL---if not for technical reasons, then because a lot of places, right or wrong, have a policy requiring currently supported software. It's a pity because otherwise Fedora is an excellent, reliable system capable of such long-term operation.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
