When Alan has quit, he wrote: "some people will wonder what [my departure] means for Red Hat engineering. Red Hat has a solid, world class, engineering team and my departure will have no effect on their ability to deliver." True, we're good, but of course there was an effect too. Aside from responsibility of being a Fellow (and I only know two others: Tiemann of Cygnus and SCT), he was officially working in my department, hacking on drivers. That's the side of his work at Red Hat that I observed. And although on paper it's easy to cover the gap by a small realignment or responsibilities, we'll miss something else.
When working on RHEL one of hazards is that tiredness over the old codebase sets in. To prevent relaxation of our basic standards, we have a review process. I do it too. However, pressures are always there. It's very tempting to think "a customer really needs this", "one little module parameter cannot hurt", "do I want to delay whole release", "adding a goto here makes the patch smaller". It's corrosive. You just want to rubber-stamp a patch and move on.
Last year I wrote a patch for usb-serial which, honestly, was not quite up to standards. It did fix the customer problem though, so in a moment of weakness I tried to throw it into RHEL 4 and forget it. Alan has put his foot down on it, and basically said: "What is this shit?!". After that incident, I reinstalled the personal "no shit code" rule (supposedly it was always there, but...).
I'm trying to fill Alan's shoes review-wise now that he's gone, but I don't have his moral authority. He's never tried to commit shit code, and I had (even if I learned from it). That's probably the part of him our department will miss the most.