2.4 kernel maintainer Willy Tarreau [story] announced the release of the 2.4.34 stable Linux kernel, "2.4.34 brings the usual bunch of security fixes, bugfixes, and adds support for gcc 4 to x86, x86-64 and sparc64, thanks to Mikael Pettersson's work." Willy also released the 184.108.40.206 kernel with a security fix added in 2.4.34-rc3. He went on to note some caveats:
"One user reported regular panics with aacraid since 2.4.32, so there's no regression here. I will seek for some help to get this fixed in 2.4.35. I also get reports of people getting trapped by NIC vendors who suddenly change their ethernet chips with no big warning notice. The i82546GB chip which replaced the i82546EB in e1000 cards come to mind. It is not supported by the driver in 2.4.34 but I will try to solve this in 2.4.35 (right now, you have to download the vendor's drivers when you replace a NIC). Another driver should get some lifting : skge. I have got a few reports of problems with the vendor's sk98lin driver and I noticed the same problems at work (UDP becoming silent on NFS server)."
Willy Tarreau replaced Marcelo Tosatti [interview] as the 2.4 stable Linux kernel maintainer in August of 2006 [story]. In response to a series of compilation fixes sent to the lkml by Mariusz Kozlowski, Willy suggested that all patches would be postponed until 2.4.34 is released. He suggested that in the interum the appropriate subsystem maintainers should be contacted to determine whether or not each of the patches should be merged, "we would merge the accepted patches and those without any reply which we consider relevant early in the 35-pre cycle so that people have some time to inform us about the potential conflicts they encounter."
Willy went on to describe how to determine who maintains each of the files, "check for the maintainer in the files themselves, or in the MAINTAINERS file. As a rule of thumb, if a file has not changed in the last 3 years and its maintainer is not one of the active ones you regularly see posting on LKML, then there are great chances that the file is unmaintained." He continued, "generally, the core subsystems (network, filesystems, archs, ...) are still well maintained by people who *really want* to validate the patches before forwarding them upstream." He went on to note, "they're all busy, so make the question simple enough so that they can quickly reply with ACK/NACK/QUEUED. Keep me CCed so that you don't have to forward me the response. Generally, they will reply within one week." Willy concluded, "if there's no easily identifiable maintainer anymore, or if some maintainers don't reply, then it becomes my job."