Tuesday, September 7, 2010

Fedora 14, features missing?

I was not the only one noticing there are not many features in Fedora 14 compared to the former releases, but I wondered how much this is anecdotal and how much it's reality.

So I actually counted them from the Feature pages and here is the results:

Fedora  8     21 Features
Fedora  9     30 Features
Fedora 10     28 Features
Fedora 11     52 Features !!!
Fedora 12     42 Features
Fedora 13     38 Features
Fedora 14     20 Features

So it is true Fedora 14 is the least feature equipped release we had since Fedora 8, and it's even worse if you compare side by side the features list and note how many features in the current release are just updates to (admittedly important) packages like boost or python.

So why did it happen? I think it all boils down to Red Hat Enterprise Linux 6:  the exact date for the release is not known but surely it should be nearing by now; add to this the notion most features we have in the distro carry a @redhat.com owner and the result starts to be less surprising.

So, how bad is this? Surely, other distributions could potentially move on and improve while we are "distracted" in another direction, raising the bar for us to really "lead the advancement of free, open software and content".

However it is also true more and more reports indicate Red Hat employees as leading contributors in upstream projects so, in a way, we can afford being lazy for a release because upstream would slow down as a result and we could catch up easier.

So what's the truth? I am not sure, but if it is the latter, maybe RHEL 6 also delayed GNOME 3, or at least contributed to...

8 comments:

  1. I guess the answer is: time based releases are useless.

    But having a "roadmap based" release isn't that popular than the "every 6 months" scheme that it's working in other distros.

    You can look at Ubuntu: not all the releases have the same quality. Just check the "worst ubuntu release ever" meme* ;)

    So I expect this to happen again, because some 6 month cycles are more productive than others. It's not a big deal, if we keep on going with time based releases.

    * http://www.google.com/search?q=%22worst+ubuntu+release+ever%22

    ReplyDelete
  2. Fun! a search for "worst fedora release ever" turns into 3 results aimed at Fedora 7 and Fedora 9.

    ReplyDelete
  3. May be it's a good time to have more polish when there is less feature.

    ReplyDelete
  4. Sure.... few features.... I thought they were working on bug fixing and stability...but when I tried the alpha release and it didn't boot at all....I realized that something is going wrong at fedora project.. The worst fedora release was the 9.... the best (for me) the 8 and 10.

    ReplyDelete
  5. > maybe RHEL 6 also delayed GNOME 3, or at least
    > contributed to...

    No, backing off Gnome 3 was done on request of Canonical. Just to the contrary ... I believe most F14 issues in desktop could be tracked to process of pulling of Gnome 3 packages and replacing them by Gnome 2 ones. Take a look at koji.

    To your general thesis. Yes, you are right. And your problem is that you don't have statistics for Fedora 7 (when RHEL 5 was created) ... there was like only one real feature (merge of Extras and Core; and new Python).

    ReplyDelete
  6. piuemeno: so do you know what "alpha" stands for, don't you?

    ReplyDelete
  7. Hrm. This made me think about the feature proposal process - anyone can submit a feature, after all... and I can't find any indication that feature proposals were turned down because they didn't fit into a RHEL release (rather, they're turned down because they're incompletely written, or so forth).

    A stat I wonder about: in the releases with a lot of features, what's the proportion of features owned by RH employees as their dayjobs vs features owned by community members, or RH employees as a self-selected interest? (For instance, one of the color management features in F13 was owned by a RH employee, but he was doing it as a community member as a side project in his spare time - it wasn't his job to work on that - so I'd count that feature as "community.")

    If the flux in feature numbers is due primarily to RH contributions going up and down in number (community contributions stay steady), then hrm, perhaps it's a "RHEL thing." If the RH feature numbers stay steady but the community numbers fluctuate, then maybe there's something else going on - community members needing to take a breather, major upstreams going through a big revision, etc.

    ReplyDelete
  8. One of the things that you are not taking in to account is "Features" that were... non-features. More or less no one cared other than the feature owner.

    ReplyDelete