mether's Fedora Blog

Random thoughts, usually on Fedora

Fedora release cycle

“David Nielsen: you might have a point. However that requires you to consider 9 months slow and why is that slow I wonder?”

Thats a good question. The reason it is slower is because in relative terms we have been doing a faster release cycle. Now its certainly possible to make a 9 month release cycle the norm but one of the problems might be that we would be constantly struggling with users disappointed over not able to get a good hand on the latest GNOME release with Fedora falling in and out of sync. With Fedora, we have a public time based release cycle which is non rigid and let’s us have a longer development cycle if we want a certain set of features in that particular release for some reason or delay the release a bit if the current development/test release feels too broken for example.

The important thing to understand is that Red Hat wants to actively work on new emerging technologies that push the envelope in terms of forward progress in Free and open source software and the whole design of Fedora is to avoid spending too much time working on the same release or maintaining older release.

Promoting active participating in Fedora Legacy is the way for the community to help in that if they wish to stick to the older releases. The key towards acceptance of Fedora Legacy is having Fedora Legacy as a default repository from Fedora Core 6 onwards and I am hoping to see that happen. Others have been advocating pushing the legacy updates into the Fedora Core updates repository itself but I believe users need to retain the right to disable legacy repository since the development is moving into maintenance mode into the hands of a different team with significant changes in QA and updates policy which they may not chose to adopt.

I have been writing down changes that I want to see happen as well as moving over some of the original plans in FC5 that didnt happen to the roadmap page at just to keep a tab and communicate the potential plans moving forward.

Fedora updates-testing repository needs to be more heavily used and developers should ask for explicit help in the test/development lists and communicating their plans like Mike.A.Harris has been doing often lately.

Fedora Core 5 certainly seems like it would be a good release in terms of robustness and that has in my opinion really nothing to do with the prolonged development cycle but more to do with how we managed to judge the quality of the test releases and adjust the schedule to do a good release in terms of testing and bug fixing being done on it. We did a good job with that and certainly not just developers but active participation and feedback from the testers have a key role to play in it. For my part, I basically made sure that mails in fedora-devel and fedora-test list didnt go unanswered even when the subject being discussed werent my area of expertise at all since a active communication channel I believe encourages more people to help further.

The longer release cycle for Fedora Core 5 was basically done for very precise reasons to provide core infrastructure work like Anaconda yum backend, Xen, SELinux reference policy, modular Xorg, migration to GCC 4.1 as the system compiler among various other changes that would be hard to split up between releases with no intention to change the release schedule for the subsequent releases. The take away is that we dont need be too rigid about the release schedule since unlike GNOME which should be focused towards consumption by distributions, Fedora is meant to be used directly by end users and we dont have the luxury of middleman to fix issues that arise out of a rigid schedule in .1 releases. If there are significant fixes that has been made in GNOME.x.y.z releases that we didnt already pull in during the GA release we should consider providing that as updates like we push out kernel updates but thats significantly more problematic for GNOME due to the amount of modular dependencies that really go down the core of the OS like HAL and Dbus with multiple maintainers who have to repackage, test and push out updates in sync unlike the kernel. This could incidentally very well explain why KDE 3.5 (all of KDE in Fedora being maintained by the same person) was available as an update for Fedora Core 4 as opposed to GNOME 2.12 which wasnt pushed out in combination with the fcat that GNOME 2.12 wasnt being packaged for the development tree either unlike KDE 3.5.

If you notice, GNOME 2.14 is being shipped in the same date as Fedora Core 5 according to the current schedule leaving supposedly no room for polishing it, yet it appears very robust and polished and the key towards that has been an early decision to move into GNOME 2.13 and fix the major issues quickly. Basically every Fedora release is so rapidly developed that we dont need to really differentiate between technology previews other than test releases and polishing work which is done all through the development cycle. In Fedora Core 5, things like the entire new look and feel and the menu reorganization progressed incrementally and quite discretely despite being a high impact change because the design, interaction and desktop team doing the polish work is different from the base os development team changing the guts of the core operating system in Red Hat and they can work in parallel quite efficiently without stepping into each othe’s toes.

I am not saying that opinionated testers dont have a voice in the Fedora community. More feedback and discussion regardless of whether you are a kernel developer or a list lurker is a good thing to have but I think we are unconsciously associating the goodness that we see in FC5 to the longer development release while that might not necessarily be the case. Doing more of the same thing just because it sort of worked for us previously is just monotonious. We might be better off switching to the roughly six month release cycle for FC6 while retaining a culture of doing high quality releases and see if we can do it the right way. With a six month release cycle, if we screw up something despite out best attemps not to, we can again look forward to a fabalous and rocking new release right down the line in the next six months. We can be always be forwarding thinking and excited about new development. Isnt that what Fedora is all about anyway?


Written by mether

March 6, 2006 at 5:20 pm

Posted in Uncategorized

2 Responses

Subscribe to comments with RSS.

  1. The merits of adding GNOME minor releases as updates

    Basically one of my biggest grip with the stance that minor releases not being pushed for lack of “important” updates is that I’m a translator and I know how much work is involved with trying to hit the deadline. This means that we often times push work for the x.1 release to give us a bit more time. If Fedora doesn’t update to great the lastest bugfixes, the users end up with fewer complete languages.

    I am also interested in making the Fedora specific translations better but thus far no l10n-status like service with as easy access is available to the best of my knowledge. So Danish has not recieved any loving from my hand at least and I haven’t seen postings to our language team list to indicate any updates either – this needs to change and hopefully for FC6.

    Kind regards
    David Nielsen

    P.S. I just noticed how alike we look, I just wish I was wearing my glasses in my mini me picture to make the illusion complete.


    March 6, 2006 at 1:19 pm

  2. Translation updates

    I have been fairly involved with the various L10N efforts within and outside Red Hat and you can track the L10N string translation status of Fedora and participate, take a look at and post in the relevant mailing lists.


    March 8, 2006 at 12:30 pm

Comments are closed.

%d bloggers like this: