4 ms·

This one too: https://sourceware.org/bugzilla/show_bug.cgi?id=4980 https://sourceware.org/bugzilla/show_bug.cgi?id=4980

by kawsper 12y ago

vezzy-fnord 12y ago
And yet none of these hold a candle to this masterpiece: https://sourceware.org/bugzilla/show_bug.cgi?id=12701 https://sourceware.org/bugzilla/show_bug.cgi?id=12701 I dare you to top that.
- haberman 12y ago
  These are so fantastic, keep them coming! I'm a little bit proud that I one time he told me "That's a good catch" (after verbally abusing someone else previously on the same bug). https://sourceware.org/bugzilla/show_bug.cgi?id=386 https://sourceware.org/bugzilla/show_bug.cgi?id=386
  - rodgerd 12y ago
    I wish I could find his rant about his refusal to add binary coded decimals to the C standard, his refusal to allow anyone to add them to glibc, and his assertion that BCD is useless. Alas, it appears un-googlable.
  - diegocg 12y ago
    I like this one, just because it's so stupid https://www.sourceware.org/bugzilla/show_bug.cgi?id=3266 https://www.sourceware.org/bugzilla/show_bug.cgi?id=3266
- illumen 12y ago
  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.
  - jsmthrowaway 12y ago
    > 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 12y ago
      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 12y 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.
        illumen 12y 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.
- tptacek 12y ago
  Wow. I was feeling squeamish about the Ulrich Drepper pile-on in this thread, but this bug report is amazing.
  - keithpeter 12y ago
    Strikes me that a certain stiffness of attitude will serve Dr Drepper well in his new job. Perhaps people need to find a place/community that fits their cognitive style?
- facorreia 12y ago
  And, surprisingly, it still seems to be not fixed.

This one too: https://sourceware.org/bugzilla/show_bug.cgi?id=4980 https://sourceware.org/bugzilla/show_bug.cgi?id=4980

by kawsper 12y ago

This one too: https://sourceware.org/bugzilla/show_bug.cgi?id=4980 https://sourceware.org/bugzilla/show_bug.cgi?id=4980

And yet none of these hold a candle to this masterpiece: https://sourceware.org/bugzilla/show_bug.cgi?id=12701 https://sourceware.org/bugzilla/show_bug.cgi?id=12701 I dare you to top that.

haberman 12y ago
These are so fantastic, keep them coming! I'm a little bit proud that I one time he told me "That's a good catch" (after verbally abusing someone else previously on the same bug). https://sourceware.org/bugzilla/show_bug.cgi?id=386 https://sourceware.org/bugzilla/show_bug.cgi?id=386
- rodgerd 12y ago
  I wish I could find his rant about his refusal to add binary coded decimals to the C standard, his refusal to allow anyone to add them to glibc, and his assertion that BCD is useless. Alas, it appears un-googlable.
- diegocg 12y ago
  I like this one, just because it's so stupid https://www.sourceware.org/bugzilla/show_bug.cgi?id=3266 https://www.sourceware.org/bugzilla/show_bug.cgi?id=3266
illumen 12y ago
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.
- jsmthrowaway 12y ago
  > 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 12y ago
    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 12y 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.
      - illumen 12y 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.
tptacek 12y ago
Wow. I was feeling squeamish about the Ulrich Drepper pile-on in this thread, but this bug report is amazing.
- keithpeter 12y ago
  Strikes me that a certain stiffness of attitude will serve Dr Drepper well in his new job. Perhaps people need to find a place/community that fits their cognitive style?
facorreia 12y ago
And, surprisingly, it still seems to be not fixed.