overriding the maintainer...
Posted Jul 31, 2007 19:45 UTC (Tue) by firasha
Parent article: i386 and x86_64: back together?
Conceptually, I love this patch. It's easy to see why a lot of other maintainers like it. So it may seem strange that Andi opposes it. Going back in history, Andi has almost always objected to x86 (-32 or -64) patches that he believed would result in the archs requiring more effort to maintain--which seems a perfectly reasonable attitude, yes? In this case, he clearly feels the "old cruft" will make it harder to keep the x86-64 codebase "pure". In fact, independent of anything else, he really wants to get rid of NUMAQ/Voyager/P5-SMP/visws support, saying "those [users] could continue using old kernels".
Now, it's not new to see the tired old "legacy users should use legacy kernels" argument trotted out again. Anyone who has followed lkml for awhile knows that over the years, Linus and others have repeatedly, and vehemently, shot it down every time it comes up. Usually, though, it's brought up by a newbie posting to lkml; I don't remember the last time a major maintainer argued for this, and it frankly worries me.
I love the fact that Linux is willing to support just about any hardware or filesystem. Indeed, over the years many maintainers have stated that adding all the weird stuff forces them to think outside the box and come up with better abstractions, and that the end result is in fact code that is better designed, more elegant (and sometimes actually more performant) than if the code were excised of all that "legacy cruft".
When support for a feature *is* removed, it's almost always because it's started to bitrot, and nobody is willing to step up and resurrect it--but there's always the possibility of bringing it back sometime in the future (see the thread about removing the arm26 port for a recent example).
In the end, I think it comes down to what the role of a maintainer is. Andi, on dealing with the potential difficulties of the arch merge: "I must admit I prefer hacking on new code instead". The higher up the maintainership ladder you go, though, the less time there is for lots of personal hacking. Linus and Andrew are primarily patch integrators at this point; they don't have the time to engage in major personal hacking any more. Most of the major subsystem maintainers are similar (although they do have more time than Linus or Andrew, and they do still get some of their own hacking in). So avoiding the stickier problems in one's maintainership bailiwick because of a preference to hack, while understandable, isn't really the maintainer's job.
Andi has also recently been taken to task several times for questionable code or decisions--it's been most noticeable to me over the last six months or so, but you can see indications in posts even further back. The most recent I can recall at the moment is the breakage caused by commit 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177, which Linus commented upon thusly:
I think it shows a total lack of taste and understanding, and I'm totally tired of it. This has happened too many times.Andi: please don't send this patch *ever* again.
Personally, I think Andi is a gifted hacker. I have no complaints there. But I have to wonder if the maintainer's robes are still comfortable for him. He seems to chafe at some of the responsibilities that are expected of maintainers, and this does seem to have lead to some less than optimal decisions. It may be that he would be a more valuable contributor--and personally happier--if he handed the responsibility to someone else. Unfortunately, maintaining x86 is not at all easy, and there are very few qualified for the position. It's a difficult problem.
to post comments)