RHEL 5.4 released

Posted Sep 3, 2009 1:12 UTC (Thu) by qg6te2 (guest, #52587)
In reply to: RHEL 5.4 released by jhubbard
Parent article: RHEL 5.4 released

There's a reason that they do it. It because customers want it. I work on systems where they expect leave them deployed for 5 years on more with a minimal amount of change.

While I'm stating the obvious by pointing out that the above is an instance of "we want stuff that's not going to break", it also implies that the real problem lies with kernel development (or more precisely, the testing part of development).

Regressions are bad, but this problem would be far less prevalent if the kernel developers (which includes many RH folks) were more thorough in their testing before forcing a release every 3 months. I'd wager that most users would be far happier with a 6 month release cycle if they were assured an upgrade wouldn't break their existing setup.

On the other hand, it could be argued that sticking to an ancient upstream release and patching the crap out of it is a way of keeping regressions in check. At the same time, I really do wonder about the stability of such mongrel kernels, given that far less eyes have looked at the final source and there was far less exposure to various environments. Maintaining a huge patchset also destroys the huge leverage RH gets from collaborative development in the upstream kernel.

(and yes, I do submit bug reports).

to post comments

RHEL 5.4 released

Posted Sep 3, 2009 1:23 UTC (Thu) by dlang (guest, #313) [Link]

with a 3-month release cycle, the amount of new things that are found tapers off towards the end of the three months. delaying the release longer doesn't gain as much as you would like to think.

there is usually a 2-3 week time period where there are not many known regressions (there are very seldom none, and it's not unusual for a reported regression to actually be related to a change that was introduced several releases ago), the reason these regressions don't get fixed is that they are hard or impossible for the kernel developers to duplicate. what they can't duplicate they can't fix. if what caused the problem can be identified, but not fixed easily, it's usually reverted (specificly to avoid regressions), the one exception to this is if the fix is deemed 'important' enough (usually a security issue)

note that arguments along the lines of 'but it fixes far more boxes than it breaks' are _not_ allowed.