Do you actually think Ken disagrees with me?

Hint: he doesn't. He wouldn't accept a line of code starting with "rm -rf $VAR" in ~30 minutes on a Sunday morning.

Try not to take offense from things so easily.

I linked Ken's paper because it's related. His conclusion is that it doesn't matter how smart the users or maintainers are if somebody wants to install a clever bug. Smart and clever people can still choose not to accept contributions from people they don't know.

basically they have to earn trust before they can do this i actually have some half solutions, that many use. one of these is code signing (digital signing or simple "signed off by" from an email that you believe belongs to the owner, even thus the first is stronger)

this means, the person may eventually do bad stuff, after earning your trust. OK. But if that's ever detected, at least you can trace back to him.

> Large software systems need to ultimately be in the hands of smart and wise people. Unfortunately, that wasn't the case here.

Wow, it must be awesome to be you.

Didn't say I was one of them. Enjoy your strawman. Personally, I prefer a bit more flavor. Though your implicit ad-hominem tastes a bit juicy.

Writing a package manager is actually really serious business. This package manager runs under user credentials and is expected to modify the filesystem. You can't sandbox around those requirements. No amount of whinging avoids that. This story is one of many examples why you can't take it trivially.

If you're afraid to point out incompetence - and where it is most dangerous - you won't know it when you see it. And it will bite you, hard.

I upvoted your response because on one hand I do think you are correct in all of what you are saying.

But your previous post can be interpreted as an implication that the people themselves are neither smart, nor wise. A somewhat harsh attack. I re-read it with more emphasis on the "here" part of the sentence and it sounded a bit more as though you are saying that in this instance the people were not wise.

Pointing out incompetence is helpful, but it's also very useful to do so in a way that attempts to minimize the chance of an extremely negative interpretation.

I expected an extremely negative interpretation. My criticism is harsh because the failure here was unacceptable.

Look at the pull request they merged in. Any line added to a script which starts with "rm -rf $VARIABLE" cannot be scrutinized enough.

The first commit was created at: 2012-09-30T10:25:44-07:00.

The pull request was accepted at: 2012-09-30T10:59:08-07:00.

34 minutes to accept on a Sunday morning. I suspect that wasn't 34 minutes of review. I suspect it was closer to 34 seconds of review.

Unacceptable.

If virus scanners were common on unices, their primary purpose would be to watch for the string "rm -rf".

shit happens, and then you die. when you have 50+ people that just "+1" an issue for long enough without helping, you tend to limbo-merge

Engineers have responsibility.

Otherwise you're just throwing shit at a wall and seeing what sticks.

Sounds like 99% of software development to me, OSS or otherwise.

Obviously this was an epic fail deserving of your original derision, but I can't help but be struck by the irony in your complaint of ad-hominem after what you wrote.

His comment wasn't an ad hominem. An ad hominem would be 'this person isn't smart and wise, so his decision's are wrong'. The poster's comment was of the following implicitt form:

* These sort of packages should be run by people who are smart and wise * The fact that this happened suggests that this person is not smart and wise * It is unfortunate that he is running a project used by many people.

It's perfectly valid to criticise a person (or a person's fitness for a responsibility) based on their actions. An ad hominem is the opposite - it is criticising a persons actions or arguments based on who the person is (rather than the actions or arguments themselves).