RHEL lifecylce [LWN.net]

RHEL lifecylce

Posted Dec 3, 2009 19:36 UTC (Thu) by kragil (guest, #34373)
In reply to: Between Fedora 12 and 13 by Richard_DCS
Parent article: Between Fedora 12 and 13

_I_ think RH silently went from time based to feature based.
I guess they want a kernel with a fairly ready BtrFS and some other stuff (KVM, maybe RT and also higher up the stack.)
If think about it it makes sense. Selling an OS with Ext4 in 2012? I don't think so. KVM has to replace the current Xen etc.

IMHO going feature based and even longer release cycles makes sense for an enterprise distro with a subscription business model. There is always Fedora (if you are into BDSM that is .. JK)

And I think the lifetime of RH5 will be extended even more.

(Log in to post comments)

RHEL lifecylce

Posted Dec 3, 2009 21:23 UTC (Thu) by sbergman27 (subscriber, #10767) [Link]

I think you are right about the incursion of feature-based thinking. Once a time-based
release cycle gets long enough, I starts getting harder to decide to release without some
highly desired feature. Because you know you are going to have to live with that for two
years. Of course, over the course of the extended release cycle, new things arise that you
come to think of as "must have". And you sure don't want to release without those.

Debian learned this lesson with the Sarge development cycle. The Linux kernel devs
learned this with the 2.5.x development cycle.

And the solution, in both cases, has been *more frequent releases*. And it is a solution
which has worked pretty well. I certainly don't mean that Red Hat needs to go to the usual
6 month release cycle. (Which is too rapid for any distro, IMO. Personally, I think Gnome,
KDE, Xorg, and most distros should target 9 months. But that's another post.) But RH could
benefit from dropping their 18-24 month target to 12-18 months.

With a 12-18 month release cycle, they could afford to go ahead and release the
improvements that are ready... and let the rest wait another 12 months, or so. It wouldn't
be so painful to release without everything on the current list of desired features. And 12-18
months is still long enough to preserve good QA.

It would, however, leave them with more releases to support simultaneously. Such is life, I
guess.

RHEL lifecylce

Posted Dec 3, 2009 22:33 UTC (Thu) by kragil (guest, #34373) [Link]

Well, there is a whole ecosystem around RHEL, which RH probably wants to preserve. More frequent releases would demand faster certification from Oracle, IBM, SAP etc. Which is very unlikely. They mostly only certify new products. Customers would be unhappy.
Yearly releases would only work if RH would provide the whole stack, but for most people they don't. I think they want to get there, but so far ..

I think most customers are happy with RHEL5 and are only willing to switch for compelling features. So if a 2 year update cyle won't offer those RH will adopt a longer cycle, which is what has happened I guess.

IMO this is RH new release policy:

"Gather enough features that would compel our customers to switch and that we can't realistically backport and then release.(and adapt lifetime of products accordingly. 8 or 9 years max)"

Maybe that is the crux of the subscription model, you have to do what your customers want (I know how strange that sounds.)

RHEL lifecylce

Posted Dec 3, 2009 23:33 UTC (Thu) by sbergman27 (subscriber, #10767) [Link]

"""
Maybe that is the crux of the subscription model, you have to do what your customers want
"""

Then if they've decided to change policy, they need to at least stop continuing to actively
advertise 18-24 month release cycles in their *current* sales material. Even if they are not
ready to actually announce a change yet. Unless they think their customers *want* to be
decieved.