> If you are a core maintainer, and your job is to interact with this code on a regular basis, you're the de-facto expert on its quality (albeit with some perso

> If you are a core maintainer, and your job is to interact with this code on a regular basis, you're the de-facto expert on its quality (albeit with some personal biases). If you think the code you have to work on is bad, and people don't work on that code are saying you're wrong after just skimming it, it's going to drive you insane. What you describe is the usual case, so it's a reasonable thing to assume, but if we examine reality we can make a case for concluding in this particular instance it's reversed. S. is a newcomer, ISTR he started out with XS just a few years before. I just spot-checked the last 200 out of 500 commits, not a single one touches the core C part, it's only documentation and release maintenance. I mention these not because I think they are strong evidence for the case that he is not an expert, but easily verifiable. nwclark, pevans, davem definitely got their fingers dirty with the core of the code base, and were (2 out of 3) also previous release managers, we should consider experts and not "just skimming". > whether or not code has "cruft" is entirely a subjective manner. This was not was the argument was about. It was rather: one party claims the cruft is a big impediment against improvements, the other party claims the cruft is not a big deal in that regard.