Live data from Hacker News

Apple randomly closes bug reports unless you "verify" the bug remains unfixed

lapcatsoftware.com

271–280 of 314 posts

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#271

Earlier quoted context omitted.

> Author must not have worked in enterprise software before. Or with open source projects. Fucking stalebot.

As an open source maintainer, I feel that statement is really unfair. Yes, we do sometimes close bug reports without evidence they are fixed. But: - We owe you nothing! And the fact that people still expect maintainers to work for them is really sad, IMHO. - Unlike corporate workers, nobody is measuring our productivity therefore we have no incentive to close issues if we believe they are unfixed. That means that whe…

> We owe you nothing! And the fact that people still expect maintainers to work for them is really sad, IMHO.

Users also don't owe you anything either. Auto-closing reports without even looking at them is like asking for donations only to throw 90% of what you get straight into the trash. Not cool. If you don't want bug reports, state that up front or at least leave bugs open for other users to see and talk about. Otherwise, users are free to warn others to stay away from you and your projects.

And that's before getting into more complex issues like what responsibility you have if you take on maintenance of existing software and end up breaking something what was working perfectly for some users.

> Unlike corporate workers, nobody is measuring our productivity therefore we have no incentive to close issues if we believe they are unfixed.

There are plenty incentives, e.g. pride.

> That means that when we close the issue, we believe it has a high chance of being fixed, and also we weigh the cost of having many maybe-fixed open issues against maybe closing a standing issue, and (try to) choose what's best for the project.

That's fine, but bots that auto-close issues unless the reporter dances for them is the opposite of that.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#272
post #170

Earlier quoted context omitted.

Nobody is measuring their productivity, but people definitely look at how many open issues they have and potentially how long those issues have existed. They’re likely incentivized to close issues for appearances.

With a popular open source project, you'll quickly get to a number of bug reports that you have no chance of ever solving. You will have to focus on the worst ones and ones affecting most users. At the same time, you want to communicate to users that this is the case so they don't have wrong expectation. But also, psychologically it is demotivating to have a 1000+ open bugs queue with no capacity to re-triage and onl…

The problem is that your users also have limited time and if it's clear you're not even looking at issues where someone has put in lots of effort to help you then you're only going to get lazy issues and it will actually take more effort from you to do all that work yourself if you want to reach the same software quality.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#273

Earlier quoted context omitted.

What if no devs even tried to reproduce it, and they have no reason to believe they've fixed the bug with any other changes? That seems to be the case described in the article. In such a situation, I think it's dishonest to ask the reporter to expend even more effort when you've spent zero. Just close it if you don't want to do it, you don't have to be a jerk to your customers, too, by sending them off on a wild goos…

Most of the time there is some reason to believe that the bug could be fixed though, i.e. there were non-trivial code changes around that area.

Most of the time, there isn't any reason to believe it could be fixed, i.e. there were not any non-trivial changes around that area. What you're describing happens less frequently, and in such cases, the devs should discuss that with the reporter.

In this specific example, it looks like Apple gave no indications that such changes had happened, and no indications they had even spent a nonzero amount of effort following the reproduction instructions with either the old code or the new code.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#274
post #85

Author must not have worked in enterprise software before. That's a classic trick where the developer will push back on the bug author and say "I can't reproduce this, can you verify it with the latest version?" without actually doing anything. And if it doesn't get confirmed then they can close it as User Error or Not Reproducible. Of course, the only way to counter this is by saying "Yes I verified it" without actu…

I also hate this pressure of it being on the user to come up with a minimal reproducing example. That means that any bug of any moderate complexity will never get fixed because you can't always reduce them to a few steps and they may be statistical. A bug is a bug, no matter the developers' opinion or the complexity of the bug.

However there are "bugs" that actually do turn out to be just cosmic rays flipping bits or plain user error. If you as the reporter don't provide enough information for the developer to be sure they are not going on a wild goose chase then it's fair for the developer to not invest too much time.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#275
post #207

Earlier quoted context omitted.

> That the ~50000 engineers at Apple are conspiring to close your tickets in the exact same way. It's ridiculou It's pretty clear from experience that the organization policy is to not provide feedback on bug submissions. Getting a 'check it if still reproduces or we'll close it in two weeks' message after 3 years is actually a fast turnaround. Best I've gotten was on an issue I routed to a friend who worked at Apple…

You don’t hear back because almost always your bug is a duplicate of some other one. They can’t share the original with you because it contains data from another customer or from inside the company. Almost nobody is the first reporter in an OS with billions of users. The only useful thing about those long dupe lists was being able to scan them for one with easier repro steps. But sometimes that duplicate marking is w…

That makes sense. But when you take 3-5 years to respond to my bug report, I'm going to take at least 3 months to respond to your response. And I'm probably not filing more bugs, because chances are I won't be at my current employer by the time you reply.

When you consitently burn bug reporters, sooner or later there's nobody to file bugs.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#276

Earlier quoted context omitted.

If bug contains instructions for reproduction most of that will be eliminated.

99.99% of bug reports do not You're lucky if there is an accurate description of what produced the bug on the customers' specific setup at the time of reporting.

well then closing it with inactivity is fine.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#277
post #194
post #161

Earlier quoted context omitted.

just bc everyone is calling you insane: you are being extremely reasonable.

Flagging isn't supposed to be used as a super downvote. There's a term for the bizarre behavior and thought processes (read: justification) by the person you're responding to. https://en.wikipedia.org/wiki/Occupational_psychosis > > you are being extremely reasonable They're not. If there's nothing wrong with it, one could ask whether the person here would be okay sitting in a room with their supervisor, the head of…

Did I say it's how it should be, or did I say this is how it is?

It's a reasonable request given the unreasonable nature of my working conditions, a thing I have no power to change.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#278
post #181
post #177

Earlier quoted context omitted.

It's rather unreasonable to be annoyed. The maintainers may have entirely different priorities, which is fine. They're also likely being spammed with low-effort bug reports (not yours necessarily but from others). The great thing about open source projects you can just fix the bug yourself and submit a PR, or fork the whole project if the maintainers won't merge your changes. If you don't have the time or skills your…

> It's rather unreasonable to be annoyed. I disagree. If you discover that a bug that makes an open source library unusable to you, after spending time on learning and using that library, and the authors close the bug as a wontfix, I think being annoyed is quite reasonable, even expected.

It's open source software. If you discover the bug, have written a failing test that demonstrates it, and a proposed solution to it, then maybe you can be annoyed when the authors close it as wontfix.

Otherwise OSS is pretty much as-is, where-is, with the exception of very widely used and corporately supported projects.

Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed

#280
post #275

Earlier quoted context omitted.

You don’t hear back because almost always your bug is a duplicate of some other one. They can’t share the original with you because it contains data from another customer or from inside the company. Almost nobody is the first reporter in an OS with billions of users. The only useful thing about those long dupe lists was being able to scan them for one with easier repro steps. But sometimes that duplicate marking is w…

That makes sense. But when you take 3-5 years to respond to my bug report, I'm going to take at least 3 months to respond to your response. And I'm probably not filing more bugs, because chances are I won't be at my current employer by the time you reply. When you consitently burn bug reporters, sooner or later there's nobody to file bugs.

Because that's probably how long it took for someone to prioritize it.

Even if it's not fixed by the dupe ticket, the volume of bug reports makes it almost certain another ticket for the same issue will come up. And if it doesn't then it probably wasn't that relevant to anyone.

Post reply on HN