[illumen]

The reporter didn't provide enough detail to begin with, and was rude as well.

No excuse for rudeness, but I understand why he may have gotten that way.

Can you imagine the number of silly bugs the glibc maintainer has to go through? Year, after year? Especially when people don't give enough evidence.

That is bug twelve thousand seven hundred and one. Developing a way to deal with all of those badly reported bugs quickly would be to do it like this. Just tell the people they are wrong, and have them provide more detail to prove their case. If you say, "Can you please provide more information", often bug reports just sit there.

Again, I don't condone the behaviour personally, since I would put people above the software. But I can see how maintaining glibc for many years would warp a person.

[tptacek]

Not enough detail? scanf(3) returned that 2 matches were made for "0xz" against "%x%c".

If anything, I think the problem is that he provided too much detail, since that detail alone should have been dispositive.

[DanBC]

I am not sure why you've been so heavily downvoted, other than "lots of people disagree".

Perhaps if bug-lists are so awful to read (and I have no doubt that they are) then the people reading them need more [close] buttons.

[close - no ref to standard]; [close - no test example code]; etc, and these provide templated replies that ask people for correct reports.

"We closed this bug. You MUST provide a clear reference to the specification showing how $THING is non-compliant.

AND

you MUST provide a test example code snippet".

This would help de-stress people reading the bugs, and might prompt people providing bugs to provide correct information.

I agree that templates are often hateful nasty things - templates on Wikipedia are really nasty approach. But here the alternative is, well, also pretty unpleasant for some people.

[illumen]

Yeah, the more information you require the less likely people are to fill it in.

I've been a fan of "search" not categorise for bugs for this reason. People are more likely to blog about, or tweet about a bug than put it into a bug tracker.

The role of an issue gardener is a really useful one too. A person whose job it is to go into issues, and make them useful for developers. To communicate with all sides, and enhance the process for everyone.

A great example of this is when @pyalot tested out various webgl implementations on different browsers. Then he went to all the bug trackers, and made notes. Then linked to various specifications, and pointed to test cases.

http://codeflow.org/entries/2014/jun/08/some-issues-with-app...

This one guy through this has done a massive service to WebGL and the web. I've seen too often various bugs and issues go through 2-3 browser iterations because that's how long it takes for people to seriously test out features and report bugs.

The collaboration going on now because of open bug trackers in web browsers is amazing.

[jsmthrowaway]

> The reporter didn't provide enough detail to begin with, and was rude as well.

drepper's skill is in goading that response out of people, sometimes unconsciously, sometimes consciously. Take note of where the rudeness began before spending 143 words apologizing for and defending him.

I struggle to think what additional information could be included in this bug report, as you request, since:

    f(x) -> y    /* erroneous */
    f(x) -> z    /* correct */

...is about the most perfectly-written bug you can ask for and was enough context for drepper to understand.

[illumen]

I don't apologise for him, or defend him. However, I do have some insight into what may have caused this unsettling behaviour.

The bug report does not follow the projects standard for reporting bugs.

The main problem is that it does not link to the specification, and explain why it is not up to spec. This is required by the glibc bug reporting standards.

Later the reporter checks the scanf function against another implementation, as is asked for by the glibc documentation. Later the reporter also explains why it is wrong against the specification. If the reporter had read the guidelines initially and done these things, that would have been an acceptable bug report. To not do so is wasting the maintainers time. It is rude if the reporter knew about the bug reporting guidelines, and decided to waste the maintainers time anyway.

In this particular case, I think the reporter and the maintainer could have done a better job.

[tptacek]

You don't need the spec to see that "0xz" doesn't match "%x%c". The man page for scanf is sufficient, as is having read K&R. This is extremely basic C standard library stuff; it's not an odd corner case.

[illumen]

Sure. A good maintainer would see that, and perhaps ask politely for the missing required information.

That's the main job of a good open source maintainer really. Asking for people to provide more information, test cases, and documentation.

In this case, the maintainer queried the behaviour (in a rude way granted), and was not sure why it was wrong. All that attitude from the maintainer was definitely not needed.

If someone reports a bug to your project, make them feel welcome! Numerous times, I've seen these single bug reporter people turn into long time contributors. All it takes is a bit of attention, giving them credit, and providing a nice environment for them.

Anyway, it's good there is a much more functional team heading glibc these days.