Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Long-term support and backport riskLong-term support and backport riskPosted Jun 20, 2007 21:56 UTC (Wed) by iabervon (subscriber, #722)Parent article: Long-term support and backport risk
It seems to me that the sensible thing to do would be to never backport features, but to offer a recent kernel with each minor version upgrade. So if you're using RHEL 4 and you want infiniband, you upgrade to RHEL 4.3, and you get a kernel that infiniband waas merged for that's also survived a lot of Red Hat testing. If you don't want infiniband or anything else new, you stick with RHEL 4 and that's only got bugfixes.
They could have each stable series use the policy of the kernel.org -stable series, and have new stable series start internally reasonably frequently, becoming available to customers when they are well-tested and have no known regressions remaining relative to the previous stable series. In the testing region of a series before it gets to customers, the rules would probably permit disabling stuff and reverting problematic patches. And not every kernel.org version would ever get listed; with all the 2.6.21 problems, they'd probably just skip that one, since it'll probably be easier to get 2.6.22 into shape than figure out which changes between 2.6.21 and 2.6.22 fixed 2.6.21 regressions.
(Log in to post comments)
Long-term support and backport risk Posted Jun 21, 2007 0:27 UTC (Thu) by smoogen (subscriber, #97) [Link] That seems to presuppose that 2.6.22 is a stability kernel.. there are a ton of new features added in.. and it may have as many problems as 2.6.21 does.. people won't know until a large enough population with more than just the latest 'dell/ibm' hardware can test it. The people who pay the money usually do not test something that comes out straight. They wait until the other people have had their knocks. This kind of logic worked for the old days when 2.0.x and 2.4.x meant just stability and few new features... but that caused too many issues for other people who want the latest thing NOW and it caused too many breakings when the 2.1.x and 2.5.x tree opened. Linus has decided that he would prefer that if things break.. people are going to be held responsible for it right away.. not 18 months later then 2.8.0 shows up.
Long-term support and backport risk Posted Jun 21, 2007 4:38 UTC (Thu) by iabervon (subscriber, #722) [Link] 2.6.22 isn't changing anything as tricky as 2.6.21 changed. It's not going to be a stability kernel, in the sense of being focused on solidifying things without introducing anything new or substantially different, but it's probably going to go better than 2.6.21, just due to not undermining so many long-time assumptions.
I think the people who want a really stable kernel really do best by getting the first kernel that supports everything they want, waiting for other people to hit the problems (or waiting for their system vendor to hit the problems) and then sticking with that kernel, with only -stable-quality patches afterward until they get a newer system that needs a newer kernel.
Long-term support and backport risk Posted Jun 21, 2007 7:51 UTC (Thu) by dlang (subscriber, #313) [Link] people who think that 2.0, 2.2 or 2.4 kernels never had problem releases like 2.6.21 just weren't there to experiance them. there were releases in all three series that make 2.6.21 look rock solid (even ignoreing the early releases in all three series)
Long-term support and backport risk Posted Jun 21, 2007 16:48 UTC (Thu) by smoogen (subscriber, #97) [Link] Actually I did gloss over the issues of major changes in the 2.0, 2.2, and 2.4 series (2.4.9->2.4.14.. actually 2.0.10, 2.2.10 all were areas of instability). In most cases they were usually the kernel people seeing that something was majorly borked in their assumptions and having to retrofix a lot of stuff that they didnt make assumptions for. However from the items that LWN has shown on the kernel pages.. the amount of code changes in those series for a period of 2-4 sub-releases was less than what occurs between 2.6.20 and 2.6.21 or 2.6.14 and 2.6.15.
[From someone who has done systems administration support of kernels from 1993.]
Long-term support and backport risk Posted Jun 21, 2007 23:53 UTC (Thu) by dlang (subscriber, #313) [Link] there is no question that the rate of change has increased drasticly.
I wouldn't be surprised if the 2.6.21->2.6.22 changes riveled or exceeded the 1.2.0 -> 1.3.0 changes. the fact that it's happening so quickly with so few problems is amazing.
when I referred to the problems in the 2.0, 2.2, and 2.4 series, I wasn't just thinking of the couple major problems, I'm remembering that there were several 'brown paper bag' releases scattered throughout the series
|
|||||||||||