Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lapcatsoftware.com

Post reply on HN
Print view View original

261–270 of 314 posts

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

#261

Post by watwut »

nradov wrote: post #177
BrenBarn wrote: post #122

All kinds of open source projects do this too. It's really annoying. It's one thing if the authors actually try and fail to verify the bug, but these days it seems like most projects just close "stale" bugs as a matter of course. This is equivalent to assuming that any given bug is automatically fixed after X amount of time, which is pretty absurd.

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 is not about "priorities". Putting work into writing bug is utterly useless, because if the maintainer does not fix it in 2 months, the bug will be closed as stale. I am actually fine with open source project maintainer to prioritize stuff and hey, maybe that bug will be fixed in 6 months when they have time. But I am not fine being told "we did not had time for 2 moths, therefore we are closing your bug" as is standard on github now.

Do not throw the ball back with "this happens because bugs are not well written". Stalebot closes bug regardless of whether they are well written and ensures no one will put effort into writing another well written bug again.

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

#262

Post by grey-area »

kurtis_reed wrote: post #257
grey-area wrote: post #244

Earlier quoted context omitted.

Closed reports are not lost, they are still searchable/linkable, they are just not in the list of work to do. This is entirely up to the maintainer, who puts in the work and gives up their time/money to do so. If you want to be in charge on a given repo, put in the work and become a real contributor, if not accept the rules the maintainers choose.

You know what I mean. If the issue is closed, it looks like it's been solved. A new issue may be created that duplicates it, etc. Obviously it's up to the maintainer. I'm saying what the maintainer should do, not what they can do.

Dupe reports are a signal all by themselves, that's really not harmful, nor does something being closed implied solved.

You shouldn't presume to know what is best for an open source maintainer of any given project - projects vary, reports vary in quality, and the job of maintenance is not an easy one.

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

#264

Post by annie511266728 »

ImPostingOnHN wrote: post #123
SchemaLoad wrote: post #105

Earlier quoted context omitted.

There's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned. You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.

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…

Right. The problem isn’t closing the ticket, it’s pretending more work is happening than actually is.

“Needs verification” is fine if someone has actually tried to reproduce it. Otherwise it’s just a nicer way of saying “we’re not going to look at this.”

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

#265

Post by account42 »

nerdile wrote: post #165
rkagerer wrote: post #162

Earlier quoted context omitted.

That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability. They would not remain employed in my company. When I developed software I would jump right on top of any bug reports immediately, and work until they were fixed. I was grateful to my customers for bringing them to my attention.

It is different when you have a billion customers, all with different setups. At that scale, you notice real defects through product telemetry, support ticket volume, or trusted channels. You receive a high volume of bug reports that are due to user confusion, misconfiguration, or misbehavior of other software on the device - where solving an issue for one customer doesn't result in improvements for the other billion…

It should be the other way around - at billion customer scale you should be responsible for how your product interacts with other software whose developers have less resources than you.

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

#266

Post by account42 »

PunchyHamster wrote: post #149
SchemaLoad wrote: post #105

Earlier quoted context omitted.

There's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned. You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.

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.

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

#267

Post by account42 »

ImPostingOnHN wrote: post #123
SchemaLoad wrote: post #105

Earlier quoted context omitted.

There's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned. You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.

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.

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

#268

Post by butlike »

Neywiny wrote: post #254
Natsu wrote: post #99

Earlier quoted context omitted.

I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eite…

I hate that so much. It's everywhere. An example is a bug with discord. They wanted me to restart my phone, reinstall the app, what are my versions, what phone am I on, what settings, etc. After all of that they go "oh that's a known issue." Whyyyyyyyyyyy. I get that multiple things can have the same symptom, but maybe start with that. Not like I signed any NDA so they aren't hiding it's an issue from the public.

puts on paranoid hat It could be to demoralize you so you subconsciously decide to not file a bug next time, knowing all the rigamarole you'd have to go through. takes off paranoid hat

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

#269

Post by account42 »

nijave wrote: post #160
beembeem wrote: post #78

Earlier quoted context omitted.

Yep. On the other side of the curtain this often isn't nefarious. It's a simple cost/benefit analysis of spending time on something that one user is complaining about versus a backlog of higher business priorities. I've seen this in my work and it makes me sad for the user, but it often does take a bit of effort to spear these bug reports through.

I can sort of back that for desktop apps but telemetry is so trivial for webapps needing a reproducer is almost an embarrassing admission the operator has no clue what they're doing. Error tracking and tracing make it fairly straight forward to retroactively troubleshoot unreproducible issues.

And total 24/7 surveillance also makes police work easier, but it's still wrong.

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

#270

Post by account42 »

fendy3002 wrote: post #179
MiddleEndian wrote: post #129

Earlier quoted context omitted.

Or even non-software tickets at large corporations. I reported a water dispenser filling too slowly at my office because it took me a few tries just to fill my 1L water bottle. They said it was fixed and closed it. It was not fixed. So I took a video of myself refilling my water bottle, attached it to the ticket, and re-opened it. They actually fixed it after that. The video was 2m12s long (and I spent god knows how…

this is actually a good example of how a more detailed issue will have a higher chance to be addressed. I don't know what information that's your previous report is lacking, but the video certainly give more information that the maintainer can pinpoint the cause and act on it. The ability to pinpoint the cause from the report is a godsent for maintainers, it drastically reduce the time to investigate the cause, thus…

More importantly it shows how the reporter actually used the system to trigger the undesired behavior. Just because something is obvious to you doesn't mean it will be obvious to whoever is looking at the bug report.
Post reply on HN