Hacker News Reader

Comment by coldpie | Hacker News Reader

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.

View on HN

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.

Of course. They chose to resolve it by saying the underlying software should be fixed. That seems perfectly fine to me.

That's not a resolution, that's ignoring the bug.

No, it isn't. It's directing the bug to the people who are able to fix it.

No its not, stop being obtuse on purpose.

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.

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.

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

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.

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?

The latter

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

If you can't hunt it, punt it!

you're hired!

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

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.

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.

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

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

From the OP:

> It’s not the job of a bug reporter to figure that out

What’s ambiguous about this statement?

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com