4 ms·

What do you disagree with, exactly? The bug is in an underlying library, so it should be reported to that library. That all seems correct to me, I don't see wha

What do you disagree with, exactly? The bug is in an underlying library, so it should be reported to that library. That all seems correct to me, I don't see what there is to disagree with there. The problem with the comment is it does not make ownership of the next steps clear. The maintainer should've either taken the ball ("I will report this to...") or made it clear that the reporter should hold the ball ("We can't fix this here. You should report it to..."). Instead they used the passive voice ("The issue should be reported to..."), which means no one owns it, which means it won't be done, which is a bad way to handle a bug report.

snickerbockers 1y ago
>The bug is in an underlying library they didn't test that they just assumed that since they call a library function the library function must be the root-cause. This is classic bug-punting.
- Y_Y 1y ago
  If you can't hunt it, punt it!
  - snickerbockers 1y ago
    you're hired!
dist-epoch 1y ago
Bro is a Microsoft employee. He should say "thank you for the bug report", and open a bug in the underlying library if that is the correct place. Bug reporter might not care that much and not bother opening another bug report, and this looks like a pretty bad bug.
- JohnFen 1y ago
  This. And that's how it should work whether or not it's a Microsoft application. Users report bugs to the team working on the user application. If the bug is actually in a component that application uses, then it's that team's responsibility to report it upstream, not the user's.
  - vlovich123 1y ago
    In theory and definitely how it should be for commercially backed projects. For volunteer OSS though (and commercially backed) maintainers are frequently not going to do that in my experience.
    - JohnFen 1y ago
      I don't think being commercial or volunteer affects this. The end user shouldn't report it upstream, not just because that's putting more burden on the user than is called for, but because the end user likely doesn't know enough about how the component is used in order to make a good bug report or answer questions the upstream component may have. That some OSS devs don't work that way isn't really important in terms of this point. If the project isn't going to address the bug, they should just say so without implying the user did something incorrectly.
      - croon 1y ago
        In this specific case I absolutely agree with you, but if going outside the thread on GPs point, I am way more lenient towards (non commercially backed) OSS projects. I'm usually using the product because no one other than the volunteers are doing it, and if I want something fixed, I might have to put in some work to dig and pinpoint the issue to help a fix along, put in a PR myself, or accept it being broken for a while until someone makes the (unpaid) time. And that's ok, or at least a reality for a lot of OSS.
- coldpie 1y ago
  I agree that's the ideal solution in a vacuum, but I don't know this person's responsibilities regarding the projects in question, so I don't want to make assumptions about what they can or should do.
  - mort96 1y ago
    If their job isn't to handle bug reports against .NET, what are they doing writing confidently about what should happen as a response to a bug report against .NET?
    - coldpie 1y ago
      I am taking no stance about their responsibilities. What I am saying is they should have made the ownership of the next steps clear. Who the owner is depends on their responsibilities, which I don't know.
- EE84M3i 1y ago
  It was clarified on the thread that that person was NOT a Microsoft employee and just a volunteer. That completely changed my perspective on the situation.
wat10000 1y ago
It's going to be interpreted, and is probably meant, as saying that the person who filed the bug should close this report and open a new one in the right place.
- mort96 1y ago
  Since the comment you responded to already complained about use of passive voice... It's going to be interpreted BY WHOM to say that? Other .NET developers? Yeah, maybe, at least some of them. By the submitter of the original bug? No idea, I can't read their mind.
  - wat10000 1y ago
    By approximately everyone. Passive voice saying something should be done differently, in reply to someone doing something, is saying that person should do it differently.
  - kwk1 1y ago
    Apply the "reasonable person" standard. > No idea, I can't read their mind. Mind-reading is not necessary to predict how people will react to certain patterns of behavior.
Sankozi 1y ago
Unless the documentation says that Math.Pow just returns the result of calling some other code (it doesn't do that), the bug is both in the Math.Pow and underlying library. It should be reported and tracked in both.
- dylan604 1y ago
  But should it be the responsibility of the person reporting the bug in Math.Pow, or the devs maintaining Math.Pow sees it is part of the underlying library and makes the report?
  - scott_w 1y ago
    The latter
scott_w 1y ago
> What do you disagree with, exactly? OP said it quite clearly and so did you: that it's the reporter's job. It's the maintainer's job to put in the bug report now.
- coldpie 1y ago
  > OP said it quite clearly and so did you: that it's the reporter's job. I don't agree that it was stated clearly. That's the whole point of my comment. Leaving it unclear is bad, tasks should always have an unambiguous owner.
  - scott_w 1y ago
    From the OP: > It’s not the job of a bug reporter to figure that out What’s ambiguous about this statement?
nkrisc 1y ago
If your software has a bug, it’s your bug. If the root cause of the bug in your software comes from a direct call into some dependency, that’s immaterial to the users of your software. Your software is incorrect, so your software has a bug. How you choose to resolve it is up to you. You might implement a fix in your code to handle the bug case until the dependency is fixed.
- coldpie 1y ago
  Of course. They chose to resolve it by saying the underlying software should be fixed. That seems perfectly fine to me.
  - Symbiote 1y ago
    That's not a resolution, that's ignoring the bug.
    - coldpie 1y ago
      No, it isn't. It's directing the bug to the people who are able to fix it.
      - aydyn 1y ago
        No its not, stop being obtuse on purpose.
      - croon 1y ago
        You can fix it by handling the erroneous output from your dependency, or switching out your dependency, or submit a fix to the dependency, or asking them to fix it.
  - fasterik 1y ago
    The responsible thing to do would be to report the bug to the upstream project and keep the issue open pending the underlying issue's resolution. This is a broader cultural thing. In large organizations there is a tendency toward deflecting as much responsibility as possible onto other teams. In part it's a lack of resources, but it's also a result of individual contributors not being willing to take ownership of the product they work on.
mdemare 1y ago
If a library has a flaw that big, it is a bug to use that library.
- coldpie 1y ago
  You are going to have a very short, frustrating career in software if that's your position. Bugs happen, report them, get them fixed, chill out, and don't be a dick.
  - rmilk 1y ago
    I’m going to give a HARD disagree with this type of hand waving for a bug in pow(). First, how was a change allowed in such a fundamental function without significant justification and validation. It’s exponentiation. That’s like saying you want to fix multiplication. Sure, but it better get higher scrutiny that a higher-level function. Second, where is regression testing. It’s a trivial function to write tests for, which means MS never created real test plans for basic UCRT functions. This is where the outrage should placed.
blueplanet200 1y ago
This issue is the word "instead". Instead means "this isn't our bug, it's the underlying library." The libraries you rely on are part of your product. You own the issues that bubble up from them. A much much better reply for the maintainer would've been: "The root cause looks to be X, I'll submit a ticket and make sure a fix makes it into our build."

snickerbockers 1y ago

>The bug is in an underlying library they didn't test that they just assumed that since they call a library function the library function must be the root-cause. This is classic bug-punting.

Y_Y 1y ago
If you can't hunt it, punt it!
- snickerbockers 1y ago
  you're hired!

dist-epoch 1y ago

Bro is a Microsoft employee. He should say "thank you for the bug report", and open a bug in the underlying library if that is the correct place. Bug reporter might not care that much and not bother opening another bug report, and this looks like a pretty bad bug.

JohnFen 1y ago
This. And that's how it should work whether or not it's a Microsoft application. Users report bugs to the team working on the user application. If the bug is actually in a component that application uses, then it's that team's responsibility to report it upstream, not the user's.
- vlovich123 1y ago
  In theory and definitely how it should be for commercially backed projects. For volunteer OSS though (and commercially backed) maintainers are frequently not going to do that in my experience.
  - JohnFen 1y ago
    I don't think being commercial or volunteer affects this. The end user shouldn't report it upstream, not just because that's putting more burden on the user than is called for, but because the end user likely doesn't know enough about how the component is used in order to make a good bug report or answer questions the upstream component may have. That some OSS devs don't work that way isn't really important in terms of this point. If the project isn't going to address the bug, they should just say so without implying the user did something incorrectly.
    - croon 1y ago
      In this specific case I absolutely agree with you, but if going outside the thread on GPs point, I am way more lenient towards (non commercially backed) OSS projects. I'm usually using the product because no one other than the volunteers are doing it, and if I want something fixed, I might have to put in some work to dig and pinpoint the issue to help a fix along, put in a PR myself, or accept it being broken for a while until someone makes the (unpaid) time. And that's ok, or at least a reality for a lot of OSS.
coldpie 1y ago
I agree that's the ideal solution in a vacuum, but I don't know this person's responsibilities regarding the projects in question, so I don't want to make assumptions about what they can or should do.
- mort96 1y ago
  If their job isn't to handle bug reports against .NET, what are they doing writing confidently about what should happen as a response to a bug report against .NET?
  - coldpie 1y ago
    I am taking no stance about their responsibilities. What I am saying is they should have made the ownership of the next steps clear. Who the owner is depends on their responsibilities, which I don't know.
EE84M3i 1y ago
It was clarified on the thread that that person was NOT a Microsoft employee and just a volunteer. That completely changed my perspective on the situation.

wat10000 1y ago

It's going to be interpreted, and is probably meant, as saying that the person who filed the bug should close this report and open a new one in the right place.

mort96 1y ago
Since the comment you responded to already complained about use of passive voice... It's going to be interpreted BY WHOM to say that? Other .NET developers? Yeah, maybe, at least some of them. By the submitter of the original bug? No idea, I can't read their mind.
- wat10000 1y ago
  By approximately everyone. Passive voice saying something should be done differently, in reply to someone doing something, is saying that person should do it differently.
- kwk1 1y ago
  Apply the "reasonable person" standard. > No idea, I can't read their mind. Mind-reading is not necessary to predict how people will react to certain patterns of behavior.

Sankozi 1y ago

Unless the documentation says that Math.Pow just returns the result of calling some other code (it doesn't do that), the bug is both in the Math.Pow and underlying library. It should be reported and tracked in both.

dylan604 1y ago
But should it be the responsibility of the person reporting the bug in Math.Pow, or the devs maintaining Math.Pow sees it is part of the underlying library and makes the report?
- scott_w 1y ago
  The latter

scott_w 1y ago

> What do you disagree with, exactly? OP said it quite clearly and so did you: that it's the reporter's job. It's the maintainer's job to put in the bug report now.

coldpie 1y ago
> OP said it quite clearly and so did you: that it's the reporter's job. I don't agree that it was stated clearly. That's the whole point of my comment. Leaving it unclear is bad, tasks should always have an unambiguous owner.
- scott_w 1y ago
  From the OP: > It’s not the job of a bug reporter to figure that out What’s ambiguous about this statement?

nkrisc 1y ago

If your software has a bug, it’s your bug. If the root cause of the bug in your software comes from a direct call into some dependency, that’s immaterial to the users of your software. Your software is incorrect, so your software has a bug. How you choose to resolve it is up to you. You might implement a fix in your code to handle the bug case until the dependency is fixed.

coldpie 1y ago
Of course. They chose to resolve it by saying the underlying software should be fixed. That seems perfectly fine to me.
- Symbiote 1y ago
  That's not a resolution, that's ignoring the bug.
  - coldpie 1y ago
    No, it isn't. It's directing the bug to the people who are able to fix it.
    - aydyn 1y ago
      No its not, stop being obtuse on purpose.
    - croon 1y ago
      You can fix it by handling the erroneous output from your dependency, or switching out your dependency, or submit a fix to the dependency, or asking them to fix it.
- fasterik 1y ago
  The responsible thing to do would be to report the bug to the upstream project and keep the issue open pending the underlying issue's resolution. This is a broader cultural thing. In large organizations there is a tendency toward deflecting as much responsibility as possible onto other teams. In part it's a lack of resources, but it's also a result of individual contributors not being willing to take ownership of the product they work on.

mdemare 1y ago

If a library has a flaw that big, it is a bug to use that library.

coldpie 1y ago
You are going to have a very short, frustrating career in software if that's your position. Bugs happen, report them, get them fixed, chill out, and don't be a dick.
- rmilk 1y ago
  I’m going to give a HARD disagree with this type of hand waving for a bug in pow(). First, how was a change allowed in such a fundamental function without significant justification and validation. It’s exponentiation. That’s like saying you want to fix multiplication. Sure, but it better get higher scrutiny that a higher-level function. Second, where is regression testing. It’s a trivial function to write tests for, which means MS never created real test plans for basic UCRT functions. This is where the outrage should placed.

blueplanet200 1y ago

This issue is the word "instead". Instead means "this isn't our bug, it's the underlying library." The libraries you rely on are part of your product. You own the issues that bubble up from them. A much much better reply for the maintainer would've been: "The root cause looks to be X, I'll submit a ticket and make sure a fix makes it into our build."