| |||||||||||||
Time for rolling release focus?Time for rolling release focus?Posted May 17, 2012 2:13 UTC (Thu) by lemmings (subscriber, #53618)Parent article: Stable distributions and unstable software
I personally would like to see more of a move towards rolling release distributions becoming the norm for desktops.
A rolling release ties in with the release early, release often philosophy and would provide all the benefits to development that that entails. The biggest challenge is ensuring stability and a hassle free end user experience as the software is constantly upgraded.
It even makes sense for many of the components on a server system where there is low risk of stability/compatibility problems with newer versions.
(Log in to post comments)
Time for rolling release focus? Posted May 17, 2012 2:33 UTC (Thu) by nickbp (subscriber, #63605) [Link]
You can more or less get this now with Debian testing.
Time for rolling release focus? Posted May 17, 2012 3:43 UTC (Thu) by lemmings (subscriber, #53618) [Link] Sort of. Continuous rolling unstable/testing distributions aren't what I had in mind so much. Like Fedora Rawhide, they tend to have moments of being frozen for release, breakage, and a mix of upstream stable/development versions. I'm more interested in continuous rolling stable versions of upstream packages with little delay. Ideally, this would be coupled with the ability to easily switch to a different upstream branch (e.g. development, SCS tag, or SCS head) on an individual package basis to allow the user to participate with testing/development on what they have time/interest in. I think Foresight Linux implements something like this. I'll have to try it out one day, however I would love to see the mainstream distributions migrate to this sort of model.
Time for rolling release focus? Posted May 17, 2012 4:45 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
I don't disagree with your points but these days Rawhide is never frozen. When a freeze is about to happen, a new development branch is created and Rawhide just keep flowing.
Time for rolling release focus? Posted May 17, 2012 4:59 UTC (Thu) by lemmings (subscriber, #53618) [Link]
Thanks for the link. I didn't realise Rawhide had changed that. I may have to try it out again.
Rawhide Posted May 17, 2012 13:37 UTC (Thu) by corbet (editor, #1) [Link] Yes and no... In truth, Rawhide often runs behind the frozen release for the latest updates; many Fedora developers have made it clear that Rawhide is a relatively low priority. Rawhide can be a good option—I run it—but sometimes I think that Fedora has bitten off a bit more than it can chew by trying to develop Rawhide and the next release simultaneously.
Rawhide Posted May 17, 2012 14:42 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
I don't think anyone would really describe the state of rawhide post-freeze as "development" - it ends up as a staging ground for things that can't be landed in the branched release, but there's certainly no expectation that it's a coherent release during that time. Whether there *should* be is a great question, and I'd agree that it's probably not very clear to an external observer what the expected behaviour of rawhide is at any given point in time.
Time for rolling release focus? Posted May 17, 2012 13:09 UTC (Thu) by tsdgeos (subscriber, #69685) [Link]
Archlinux does what you want as far as i understand
Time for rolling release focus? Posted May 18, 2012 17:06 UTC (Fri) by vonbrand (subscriber, #4458) [Link] OK, so you want stable (== no API change at all) while bundling the latest versions of everything. I'd like that too, and a pony while we are at it.
Time for rolling release focus? Posted May 18, 2012 17:22 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Stable API doesn't mean 'no change at all'. WinAPI gets new functionality all the time without breaking old functionality. glibc and the kernel do the same.
Time for rolling release focus? Posted May 21, 2012 6:58 UTC (Mon) by filipjoelsson (subscriber, #2622) [Link]
Sounds like Gentoo stable to me!</sarcasm>
Seiously, though, that's the main reaon I still use Gentoo. Though claming there's no API shift is a bit of a stretch. :-)
Time for rolling release focus? (for such packages) Posted May 17, 2012 16:28 UTC (Thu) by perennialmind (subscriber, #45817) [Link] It's much nicer when you can install the individual package frombackports into a stable environment. Running testing wholesale isn't an option for most folks and transplanting packages directly from testing is problematic. (I'm not saying it can't be done well, but so far I've only managed to do so poorly). One often runs into the odd package that needs to be updated on a different schedule. Typically it's a desire for a newer version, but sometimes it's a package that is only available in the upstream release. For projects which push updates like Wordpress, Chrome, and Firefox, why not bar them from stable, but let them live in backports?
Time for rolling release focus? Posted May 17, 2012 15:11 UTC (Thu) by bkw1a (subscriber, #4101) [Link]
I agree, to some extent, that distributions should move more toward "versionless" rolling releases, but the distributors will need to continue to test each update to make sure that it doesn't break things. That may be a bigger burden with a rolling release than a traditional stable release.
Distributions can't count on testing done exclusively by upstream developers. Interactions with the distribution's particular mix of other software and configuration options may reveal surprises that the upstream developers didn't anticipate.
Also, rolling releases won't help people running things like WordPress, which have lots of third-party add-ons. If you're running a web site that depends on one or more of these add-ons, you may find that a rolling release frequently breaks your site, because the latest WordPress is incompatible with the installed add-ons.
I really think that if projects like WordPress are serious about supporting production environments, they need to provide a "long term support" version similar to the Firefox Extended Support Release.
Time for rolling release focus? Posted May 18, 2012 4:33 UTC (Fri) by jcm (subscriber, #18262) [Link]
Dear goodness no. Please no :)
By all means, have whatever just-built bleeding edge you want in a testing distribution, but Linux distros in general are already too keen to move quickly as it is. I run a popular Enterprise distro on a number of machines, and that gives me the comforting warm and fuzzies, but it's not about me. You won't get more users adopting Linux by pushing for a moving target. You'll get more users by offering a tested and validated base and that doesn't come by just rebuilding whatever was released this afternoon.
Jon.
Time for rolling release focus? Posted May 18, 2012 5:28 UTC (Fri) by lemmings (subscriber, #53618) [Link] I also run a number of servers and appreciate the enterprise distro model in that it saves me time from not having to deal with upgrades breaking things. Unfortunately it does cause problems though as the software versions become obsolete causing development pain due to missing features or old bugs. The distribution eventually reaches end of life and then the OS major version upgrade becomes a huge exercise in planning. This is just a cost many server admins have to wear to keep mission critical services from breaking. The desktop is a different situation though. The quality of the experience is what counts rather than mission critical availability of services. I would argue that the free software community would be better able to improve the end user experience by closing the loop between the developers and the end users and feedback in a fashion similar to OODA loop. Right now as an end user on my Fedora desktop, it is a major PITA to effectively deal with software bugs. If I hit a bug, I have no idea if it has already been fixed in a newer stable version. Searching bug trackers can take quite a while. It may already have been fixed and I have to report to the distribution vendor to get the newer version available. This wastes my time and the distributions. Even if the bug isn't fixed upstream, it's going to take a while to download and install the upstream version to test it. And if I figure it out and either fix it or get the developer to fix it, then there is still the delay in getting the fixed version to end users. End result is that there is a lot of double handling and back porting and the rate of development (from the end user perspective) is really slowed down. If quality of individual bits of software can be decent enough, then I think the Linux kernel model of continuous stable releases is the way to go as a way to save our limited developer time and improve distributions. I hate to think how much effort the free software community must put into triaging bug reports, coordinating fixes, and back porting patches due to everything that sits between the end user and the developers. Effort that could be better spent improving the free software ecosystem...
|
|||||||||||||