undefined | Better HN

0 pointsjsmthrowaway12y ago0 comments

> 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.

0 comments

3 comments · 1 top-level

illumen12y ago· 2 in thread

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.

tptacek12y ago

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.

illumen12y ago

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.

j / k navigate · click thread line to collapse