Live data from Hacker News

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

lapcatsoftware.com

21–30 of 314 posts

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

#21
post #5

Earlier quoted context omitted.

It's very common but it's still a poor practice.

Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.

Closing bugs because they can no longer be reproduced: obviously fine.

Closing bugs automatically after a cron job demanded that the user verify reproducibility for the 11th time: obviously bad.

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

#22

I recognize that this is annoying from a user perspective, but I do understand it. Not all bugs are easily reproducible (and even if they are 100% reproducible for the user, it's not always so easy for the developers). Also sometimes you make a change to the code that you think might be in a related area, and so sometimes the most "efficient" thing is just to ask the user to re-test. When I close an old bug that is n…

A company like Apple should have complex enough tools to perfectly capture system state at the time of the bug so that they can reproduce it

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

#23
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 actually verifying it.

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

#24
post #5

Earlier quoted context omitted.

It's very common but it's still a poor practice.

Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.

the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion.

if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it.

otherwise you're just throwing away useful information.

edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem

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

#25

I recognize that this is annoying from a user perspective, but I do understand it. Not all bugs are easily reproducible (and even if they are 100% reproducible for the user, it's not always so easy for the developers). Also sometimes you make a change to the code that you think might be in a related area, and so sometimes the most "efficient" thing is just to ask the user to re-test. When I close an old bug that is n…

A company like Apple should have complex enough tools to perfectly capture system state at the time of the bug so that they can reproduce it

That’s easy enough. The hard part is doing so without capturing a bunch of email, messages, and other private data that happens to be in memory at the time.

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

#26

I recognize that this is annoying from a user perspective, but I do understand it. Not all bugs are easily reproducible (and even if they are 100% reproducible for the user, it's not always so easy for the developers). Also sometimes you make a change to the code that you think might be in a related area, and so sometimes the most "efficient" thing is just to ask the user to re-test. When I close an old bug that is n…

A company like Apple should have complex enough tools to perfectly capture system state at the time of the bug so that they can reproduce it

I don't work at Apple, so I can't comment on that. But that doesn't always help. There's been plenty of times where I have a full HAR file from the user and I can clearly see that something went wrong, but that doesn't always mean I can reproduce the issue. (I recognize a HAR file doesn't represent the complete state of the world, but it's often one of the best things a backend developer can get)

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

#27

Earlier quoted context omitted.

Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.

the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion. if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consid…

Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.

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

#28

Former Apple employee here. This is a deeper quirk of Apple culture than one would guess. Each and every Radar (Apple's internal issue tracker is called Radar, and each issue is called a Radar) follows a state machine, going from the untriaged state to the done state. One hard-coded state in this is Verify. Each and every bug, once Fixed, cannot move to Closed without passing through the Verify state. It seems like a…

I think you're incorrectly assuming two things:

1. Apple engineers actually attempted to fix the bug.

2. Feedback Assistant "Please verify with the latest beta" matches the Radar "Verify" state.

I don't believe either of those are true.

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

#29
post #5

Earlier quoted context omitted.

It's very common but it's still a poor practice.

Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.

Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.

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

#30
post #5

Earlier quoted context omitted.

It's very common but it's still a poor practice.

Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.

Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.
Post reply on HN