Robert, the moral high ground is all the way up there, and the stream down here is starting to soak through your shoes.

1. Confuse – show dozens of cryptic options and selection the typical bug reporter can’t answer; “select component” – provide a long list of components to make sure the reporter fail. “priority” – the reporter have the big picture and should set the priority of the bug. “severity” – another opportunity to make it harder for the reporter. Yes, I’m pointing at you bugzilla

2. Make it hard to attach files – don’t let the reporter attach files on the same form – that will be too easy, and we would like to waste his time. Make it fill another form to attach a file, and use multiple description fields to make him describe the same thing multiple times.

3. Ignore bug reports. If the reporter want someone to look at the bug, let him manually find the owner of the broken code, and add the owner email to the cc box.

4. Use multiple registration systems; I the user is registered on your wiki, require another login for the bug tracker. We worked hard on that code; the user should work hard too. If possible, apply draconian security measures; force the user to replace his password each month; allow only alpha-numeric characters in the password.

jk, having actually looked at the code and the $PATH, I can say that the solution the reporter stated (putting a weird path in front of /usr/bin) is not the one ever taken.

I certainly understood the bug report and how to fix it, and the “solution” of addings some wierd directory to $PATH is ridiculous.

You just don’t appreciate the fun of insulting people too stupid to be aware of their own ignorance.

as the person behind a lot of software projects (like dietlibc) and an author who even wrote for c’t I would expect a much better behaviour. He made himself look very bad.