Results 1 to 3 of 3

Thread: Frozen point-release distro model is obsolete

  1. #1
    Join Date
    Feb 2010
    Posts
    56

    Default Frozen point-release distro model is obsolete

    Let's have a discussion about this, shall we? I'm starting to think that the model of having a developement period, then a package freeze and finally after few months or weeks to produce a so-called stable release of distribution, then proceeding to repeat the same process every six months like Fedora & Ubuntu do is obsolete.

    Stable rolling release distros are great. It's evident as openSUSE is already having Tumbleweed, and Debian is planning on rolling testing without freeze periods. Then you have Arch fork Chakra, which tries something new: it attempts to have a stable well-tested core set of packages, then a rolling release layer of user applications and KDE on top of that. Obviously, Arch itself being as popular as it is despite being a dick to setup and get running properly is a pretty clear indicator of power of rolling releasing system. Another indicator that at least short-term frozen point-releases are getting increasingly unwanted is the openSUSE Evergreen project, which seeks to greatly extend support period for point-releases otherwise getting 18 months of support.

    Frequent frozen point-releases are so wasteful from developing point of view it's not funny. Not only are users stuck with obsolete piece of software (Ubuntu 10.10 is supported and users are still stuck with FF3.6 lol), but they have to rely on extra set of developers to backport its worst bugs and security holes. Those same developers could just as well spend their precious time fixing errors upstream.

    Take a look at this and decide yourself how efficient this kind of circus is: http://en.wikipedia.org/wiki/File:De...ckage-cycl.svg

    I can fully well understand the need for frozen point-releases, as long as they are intended to be used longer than one year and in system-critical enviroments. And there are Scientific Linux, Debian stable and CentOS for that. Then the point-releases with short support times and as a results, short package-freeze periods. They inevitably end up shipping with volume of bugs which would have been fixed in next software version. Every single version of Ubuntu and Fedora Core pops to mind. It's just pointless. Why aim for a "stable" release when it can't be stable in the first place, more often than not shipping in worse state than snapshot of Arch? All that extra work for nothing.

  2. #2
    Join Date
    May 2010
    Posts
    684

    Default

    I think a semi-rolling release would be best for distros like ubuntu that want to be "mainstream". They should release less frequently than every six months (maybe more like 1-2 years like windows) but keep all the important applications up to date (web browser ect...)

    Rolling release tend to end up with more breakages, even when they try and be "stable". Personally I am an arch linux/linux mint debian user and love them, but I don't think full on rolling release is something that would work for every distro, but I do agree ubuntu's current release cycle is outdated and problematic. Non-LTS ubuntu releases tend to be pretty unpolished because of the current release cycle. Natty is a perfect example of this.

    Linux mint debian is doing some interesting stuff towards making rolling release less breakage prone though, with their recently introduced "update packs"
    Last edited by bwat47; 08-20-2011 at 02:18 PM.

  3. #3
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,441

    Default

    Agreed - IMO the important thing was getting some synchronization between distros and upstream projects, and that is starting to happen. The six month cycle seems to be a compromise between quality / stability (which argues for a longer cycle with more testing) and new hardware enablement (which argues for an even shorter cycle).

    I guess one idea would be to put the Linux kernel on a split-cycle model, with a slower release cycle for general architectural improvements and a faster cycle for hardware drivers. That probably has yet another set of problems we haven't thought about, but it might align better with the upper layers.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •