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.
to post comments)