What future for 2.4? [LWN.net]

After the 2.4.23 release, maintainer Marcelo Tosatti let it be known that the development period for the 2.4 series is coming to an end. His plans are to accept relatively intrusive patches for 2.4.24 - especially driver patches. But, starting with 2.4.25, only serious bug fixes will be accepted. People will be running 2.4 kernels for some time yet, but the 2.4 series will not be acquiring new features.

The result of this sort of announcement is always predictable: people start coming forward with the the patches that they feel, for whatever reason, absolutely have to be merged before the gate closes. One of those is Jeff Garzik's "libata" driver, which provides much improved serial ATA support. Marcelo initially said that he would incorporate libata, but has since changed his mind, saying that people who want libata should use 2.6.

The big discussion, however, concerned the inclusion of the XFS filesystem. XFS is relatively controversial because it requires some significant core VFS changes, and not everybody is happy with the quality of the code. There was enough clamor, however, that Marcelo has relented to the extent that, if some of the core filesystem maintainers can be made to agree, he will let XFS in.

The reasoning behind the policy change for 2.4 is that the 2.6 kernel is on the horizon. 2.6.0 may well be released before a 2.4.24 kernel could be prepared. At that point, attention is expected to shift to 2.6, and there won't be much interest in 2.4 anymore. This approach does worry some people who remember that the 2.4 kernel took almost a year to truly stabilize after 2.4.0 came out. If 2.6 follows the same path, Linux users could be left for several months with no kernel which is being updated with new drivers, bug fixes, etc.

The general expectation, however, is that the early part of the 2.6.x series will be rather more successful than 2.4 was. The 2.6.0-test kernels seem to be far more stable than 2.4 was at this stage, and there is a high level of confidence in Andrew Morton's willingness and ability to stabilize things further. Not everybody realizes how differently the development process is working this time around. The year-old feature freeze has (mostly) held, which is a nice difference. But the big change is that Linus will be handing 2.6.0 to Andrew Morton from the beginning. In the past, Linus has always continued to manage the stable kernel releases until he felt confident in moving on to the next development series. Linus, by his own admission, is not the best release manager for a stable kernel; he would much rather be breaking things. So his early handoff of 2.6 could make a big difference in how quickly that kernel becomes truly usable.

That said, 2.6.0 is still not going to be the best kernel to use to run your nuclear power plant. A small set of fixup releases will certainly be required first. But the confidence in 2.6 is high enough that the distributors are looking in that direction for their future releases. There is little interest in building a new distribution release on 2.4; that, more than anything else, is the reason for putting 2.4 into a "critical fixes only" mode in the near future.

Unhappy

Posted Dec 4, 2003 18:21 UTC (Thu) by AnswerGuy (guest, #1256) [Link] (2 responses)

I have nothing personal against Marcelo. However, I have to express, for the THIRD TIME in these message boards, that I don't like his approach to kernel maintenance.

He sets and stays his own course oblivious to the priorities of the user
base. If he was a sailor he'd steer right into a hurricane rather than
attend to the prevailing winds. He'd sink.

When security (or possible security fixes) become available they need to be
merged immediately and a new patch expedited. He should have dropped the current rc* series and cut a new kernel with NOTHING BUT THE brk() fix ON THE SAME DAY that this issue was publicized. Then the last 2.4.23rc* becomes 2.4.24rc1 and he can continue as usual.

The release of 2.6 may be wonderful. That remains to be seen. However
have over a decade of experience with this process and this code base
spanning five major releases (1.0, 1.2, 2.0, 2.2, 2.4). We know that it
will take AT LEAST six months for 2.6.x to stabilize and gain any
signficant marketshare. He should be committed to providing real
substantial support for 2.4 for a full year after 2.6 is released and
then he can taper off a bit. Critical fixes should be maintained for at
least 2 years after that.

This isn't just about servers and desktops. This is about embedded and
carrier grade systems that are already out in the field. The adoption
cycles for some of these environment is measured in years, not months.

Sure we can claim that the distributions will take up the slack. However,
having each distribution fix the brk() bug seperately is wasteful,
reckless, and a PR nightmare. A fix that is necessary for all (or almost
all) Linux systems should be made in ONE PLACE --- at the core, in the
mainstream kernel. It's stupid to balkanize the 2.4 kernels over the next
year by having each distribution merge varying sets of patches as
central maintenance is choked off prematurely.

Marcelo, listen to me. Listen to us. Think beyond just the mainstream
desktop and server market, and outside the box of your own methodology.

Jim

Unhappy

Posted Dec 4, 2003 18:37 UTC (Thu) by wolfrider (guest, #3105) [Link]

--I agree with you 100%. Actually you should send Marcelo an email, or post this to lkml. (Actually if you do, feel free to throw my reply in with yours.)

> Jeff Garzik's "libata" driver, which provides much improved serial ATA support. Marcelo initially said that he would incorporate libata, but has since changed his mind, saying that people who want libata should use 2.6.

--IMHO, this is a HUGE mistake. 2.6* isn't *THERE* yet -- it won't even be **considered** by a great many people for months. People want to be able to use SATA with 2.4 *NOW* because 2.4 is the "stable" kernel! This whole thing is ridiculous - why should we, the Average Joe end-users, have to wait for 2.6?? The whole 2.4 development process has taken WAY TOO LONG, with *months* inbetween releases. Whatever happened to "Release early, release often"?

--The egg hasn't even hatched yet, and already they're preparing to kill the goose.

Unhappy

Posted Dec 5, 2003 22:28 UTC (Fri) by xorbe (guest, #3165) [Link]

Dude, it's not like the guy drops by and purposefully
ignores your obscure LWN comment after reading it.