In the recent past, after my rant about lack of QA from some developers but not sure if entirely related, I’ve been accused by some people of being more interested in creating “followers” than in the wellness of Gentoo. This really did make me unhappy; not only it’s definitely not the case, but as an atheist, being compared to a cultist is something that hits my very nerves.
Given that my main concern is with quality, I’d say that this is the exact opposite of what they are accusing me to do: QA is one of the most unpopular tasks, and it wouldn’t be effective if it was popular. This does not mean that QA people have to be assholes: while I’m pretty sure I don’t have the most likeable attitude on a technical basis, I’m also always careful to criticise the technical level and not get on the personal level. But it is true that QA needs to take harsh decisions sometimes, be it to remove software that might be bad for the distribution quality, or to remove developers who are harming the project (on a technical, rather than interpersonal, level; the latter is handled by devrel; more to that later).
Saying that I’m not looking to make followers is of course not the same thing than saying I don’t care about thanks, and tokens which would be definitely hypocrite to say. I don’t make a mystery that I’m happy to receive something from time to time, and I don’t avoid thanking when that happens (by the way, thanks Maxim!). I don’t think this is evil to say or write, since it’s in the human nature not to be entirely selfless. Which means that what I do, while being Free in nature, is often subordinated by having something back; it might be intended in the very broad sense of using Free Software and giving back to Free Software, or it might be more tangible, but still there is something for it.
Back on topic. As I said, I think the QA team should be the one deciding whether a developer is a technical liability to the project. This is crucial for the quality to be kept in check: having a “motivated” developer that makes a mess around the tree is not something we’re very happy about; while we strive to motivate people to help out, doing so recklessly is not good. But nobody expects the QA team to be good at judging the interpersonal skills of developers, which is why I said that devrel should do that. On the other hand, it seems like the Developers Relations team wants to take care of that as well. It would be all fine and dandy if the members of that team were to be chosen for their technical skills but … well, that’s not the case for most of them I’m sorry to say, and I don’t think that they’ll be saying otherwise here. The rebuttal we read about that has been that “some of you can join devrel” but the whole point is to keep separated and different the HR team from the technical QA team. They both have their different jobs to attend to.
And by the way, doing the reckless stuff of bumping lots of packages without testing them for the sake of the “bleeders” is probably going to be much much more popular, than turning down packages and ebuilds because they are not good enough (“suboptimal”). While I totally agree that “The perfect is enemy of the good” (or, as I’d phrase it “The perfect is enemy of the done” – Duke Nukem Forever anyone?), it doesn’t take an unreasonable time to get something “good enough”, as you might notice with my recent pam-pgsql or fcron work: neither was perfect the first time around, but they improved from the previous versions and kept going further and further. Now you have two very good ebuilds at your service.