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.
Too argumentative. You’ll never ever be able to keep everybody happy, regardless what you do.No need to justify yourself for every action or thought we have.So, just keep doing what you do and disregard the noise.
I think, even people that disagree with you or don’t like the tone of your reasoning have to credit you for your passion for the good of Gentoo.In my opinion you do an amazing job – not only as a developer but also in bringing up painful subjects that affect the Gentoo experience. Your vigorous efforts to improve the situation give me new hope – not in a religious or political but in a geeky way. Instead of being denounced as a “follower”, I’d prefer seeing your critics voicing their opinions more visibly on how they think the structural issues that Gentoo undoubtedly has to face should be addressed.From my perspective as a long time user, Gentoo seems to lack leadership and developer engagement for quite a while now. The project has survived so far because of its unique qualities that no other distibution can provide. But surviving is not enough. Therefore we _need_ the discussion that you have fueled again as much as we need more people to weigh in – even in differing directions:* What can be done to increase the engagement of developers? What motivates them, how can they be rewarded?* How can the hurdles for new talents be lowered without putting quality at risk?* How can the project leadership be strengthened without alienating volunteer developers?* Which processes can be improved to prevent mistakes of individuals from resulting in major problems?* How to keep red tape to the necessary minimum?Thanks again for your substantial contribution.
QA vs QC -Control vs Assurance. I once worked for an organization that had a QC team. There were shipping delays due to reworks forced by the QC team. One day the team leader was fired and the QC team became the QA team.Assurance is the best you can hope for here.If your mission is Assurance then I think the main task is to assure the quality of packages for your customer -us. So publish it, not on your blog but in a specific place, as a list. If I have a troublesome package I would like to be able to check if it also got put into portage having failed QA. That score card should be your one and only stick.What I’m trying to say is don’t engage, don’t be a player, be the referee. A simple reporter of facts. Anything more and you start to become the QC and that can really be counterproductive.The pass/fail criteria itself will be an endless debate of course -there will always be subjective elements. But, the primary reason (imo) for arguments is that people naturally want to avoid accountability and that means avoiding process. The argument is always wrapped up in efficiency or ‘flexibility’ but the underlying motivation is often “I don’t want to be held accountable for what I do.” It’s hard to end that argument without calling someone out (saying publicly that they are avoiding accountability). Then there’ll be a grudge…what a tough job.To be honest if all the package maintainers loved the QA person I think Gentoo would be really broken.
I’m not sure that mixing the roles of QA and devrel really makes sense. Devrel’s job is to deal with personnel issues with developers. That’s what they’re good at (or should be good at). QA’s job is to spot problems with packages and point them out to maintainers, or spot trends with developers and point them out to devrel.Now, devrel does need to take input from QA very seriously. If devrel isn’t doing so, the proper place to complain is the devrel lead followed by the council. If the council doesn’t do a good job dealing with the situation feel free to blog about it and get people to run for election with a platform to fix the issue.Of course, in an emergency ANY developer who spots a serious problem should notify infra/etc to have it taken care of. By emergency I mean somebody doing something that will cause serious harm to users, like putting rootkits in ebuilds or even something less intentional that will cause real damage.Rob – some good points in your post. There is always conflict between getting more done or doing less better.