Linux 2.4.18 Released

Kourino writes: "Marcelo announced the release of 2.4.18 a couple hours ago after 4 release candidates, but the tree marked 2.4.18 on kernel.org is missing the -rc4 patch that finally made the kernel releasable. Basically, what's marked as 2.4.18 is really -rc3, and what's marked as -rc4 is what should have become 2.4.18. According to Marcelo on #kernelnewbies, most users won't be affected, but people on SPARC systems should definitely grab 2.4.18-rc4. Your best bet is probably just to get 2.4.17 and patch to 2.4.18-rc4. Seems 2.4 is destined to be an "interesting" release branch ^_^; For the new release, head over to your favorite kernel.org mirror. (Marcelo will set things straight in 2.4.19-pre1.)"

Comments

this is an enterprise ready os?

[ostiguy]

C'mon, we're all friends here. Lets just forget this mess ever happened and relabel 2.4.x rightfully as 2.3.

Re:Block anonymous Cowards?

[phoxix]

are you retarted??

We live in a society that does nothing but bitch about anonymity and personal privacy, and yet here we are censoring posts from those who wish to remain anonymous ...

makes you wonder don't it?

Sunny Dubey

Very upset about the RC4 error.

[Zeio]

I tried to reason on an IRC channel where marcelo (and other kernel 'hackers') hang out. I was kiboshed. I tried to convince them that fixing the tarball called 2.4.18.tar.gz would be a good thing to do.

Here is some of my reasoning, musings and retorts to those who 'know' more than I do.

"Is there a plan to fix the 2.4.18.tar.gz or will I have to patch it. It is really annoying if this isn't going to be fixed to rc4/final, instead I have to patch 2.4.17 with the RC4 patch. This makes it difficult to use kernel.org as a "library". Pretend in some number of months some Joe Schmoe says 'Gee, 2.4.18 has been out for a while and is considered stable,' downloads it, and misses the RC4 patch."

This was rejected as reasonable. I was told that assuming a release is stable is bad practice, particularly based on how long its been out. My impression was this was the stable branch. I'm sure that, for example, RedHat picked 2.4.7 and 2.4.9 and hacked them for their own distributions for some reason or another. They, like the rest of use, should be ensured that what is fixed in the changelog should be included in a given release. I don't like being shunned for being closer to correct.

"I appreciate the need for a releases in software. The line is drawn, certain things are in, other are out. Its just that what was determined to be final and what is being masqueraded as such are two different things. so, the gatekeeper in this case should be able to rectify the mistake."

From the group came no response. The conversation had turned to more pressing things, such as people bragging about compiling XFS into highly experimental versions of the linux kernel. Proper release procedure is not nearly as important as strutting about having XFS working in a situation where it probably shouldn't.

Here is a reply, which was well stated and polite, but I vehemently disagree with:
"Zeio: You and Marcelo both :) everyone would have liked this to be a better release than it was, but ... mistakes happen. and, once published, one must live with them. :)"

So, with this reasoning, if I published a book. For the sake of argument this book is supposed to have 10,000 copies printed. I catch a typo after shipping 1,000. Wow, the rest of the 9,000 people have to eat the typo because once something is released it shouldn't be changed.

I also state this:
"I'm suggesting a viable way of dealing with it[the mis-release], to fix the problem by putting what was supposed to be final in place of the tarball which masquerades itself as a release, or rename it to DONT USE like 2.4.11. I would expect higher standards from the linux maintainer.

Finally, to my dismay, I realize that there is denigration concerning the theory that and open community should be attempting to mold the linux kernel tree into a pillar of perfection. Lines have to be drawn, periodic shortcomings have to be accepted until fixed, but gross errors which are easily fixable should be ignored because 2.4.19 is on the way. I'll lower my expectations of the "stable" 2.4 linux tree for the time being. I'll put 2.4.18 in the same category as 2.4.11 and the "greased turkey" release. Seems this is becoming a norm. I strongly appose nonchalant and half assed attitudes towards maintain something of this importance.

Another joke was made that this only gravely affected SPARC users. This reinforces the wholly incorrect attitude that x86 should come before others. I'd bet that if this 2.4.18 wouldn't boot on x86, they would have re-released it.

Sadly, I had to point out that even Mickey$oft was forced to re-release service pack 6 to 6A. The claim was that 2.4.19pre1 is already out, and that 2.4.19 will likely be out in less time that it took Mickeysoft to put out 6A. These to me are excuses. Inferior ones. I expect more from linux than Microsoft. I expect a group project to put its best foot forward. I'd hate to have to write code for a project where FINAL is a line that is arbitrarily drawn. I know I'm over reacting, but I tend to like testing the latest stable release when they come out, and wouldn't you know it I have a SPARC. Guess I'll wait for 2.4.19, like I had to wait after 2.4.11 (2.4.12 was out soon, albeit with a broken LPT module, but that is when Linus maintained 2.4) and greased turkey. Sorry, I don't like to patch a previous major release, I just don't like doing it, I don't get off on it, I don't want the hassle, even though it is easy and have done it for things like the AIC driver when it was taking them forever to integrate the changes into the stable tree.

Linus, show this kid how to rectify an error and do it quickly.