Live data from Hacker News

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

lapcatsoftware.com

231–240 of 314 posts

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

#231

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.

Stalebot closing is a problem. There's no problem with stalebot adding a stale label (but really, a filter with last update x time ago does the same).

Adding filters so that developers only look at actionable tickets would be much more sane.

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

#232

Earlier quoted context omitted.

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…

IMO closing issues via stale bot is fine, the problem is locking issues so that no further conversation is allowed on the issue. Multiple times, I've encountered multi-year old issues (which is usually not fixed due to the fix not being simple or compatible with the current architecture). There's usually a good amount of conversation between users offering workarounds (and those workarounds updated for newer versions…

This 1000%. Whoever came up with the idea of closing and locking issues because no one has posted on them for awhile is at best not all that bright and at worst downright sinister.

Closing an issue due to staleness is one thing, locking it is another.

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

#233

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…

Is your argument "it's bad everywhere, so it's ok"? As a software developer I do understand how enterprises operate, as a customer and a user I'd put Apple under higher scrutiny and would expect better.

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

#234
post #193
post #181

Earlier quoted context omitted.

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

If that type of thing annoys you then you should restrict your use of open source projects to those backed by corporations with a paid support business model.

For feature requests, sure, but not for bug reports

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

#235
post #181

Earlier quoted context omitted.

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

Not really no, you got the support you were willing to pay for.

If the maintainer merely doesn't fix the bug, then yes. If they close the bug report so it gets lost and other contributors are discouraged from working on it, then no.

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

#236
post #31

I’ve been dealing with ElevenLabs pulling this same garbage. I’ll fill out a bug report, wait a few days to a week to get a response, which are often AI generated, and then 48 hours afterward their bot marks it as stale. Telling me to check if it’s still broken or they assume it’s fixed lol

(I work at ElevenLabs)

Sad to hear this. How are you submitting the bug report? If you submit an issue via any of our open source repos on GitHub you'll get a timely human response.

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

#238

Earlier quoted context omitted.

Companies have no consciences.

Companies are made of humans who do.

I guess that explains why social media companies try to maximize engagement even though it is almost bad for your mental health in every way.

Or does it?

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

#239

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…

From experience with Microsoft (paid) support (after doing 5 tickets because it's never the right team and apparently moving tickets internally is for losers), they will ask for proof of the reproduction. And they will take every opportunity to shift the blame ("Oh I can see in the log you're running an antivirus, open a ticket with them. Closed").

Outsiders can't see the internal ticket, but e.g. https://github.com/microsoft/STL/issues/4448

This is simply a bug, it's an implementation mistake, it's even possible to imagine from what we do know about the implementation inside Windows to imagine how you'd likely write that bug, simply you're writing the "lock stealing" code and you realise you need some context -- are we stealing the write lock or the read lock? You realise that context won't fit in your tiny flag budget (flag bits are hidden in the bottom of a pointer) and you forget that you actually know this context at the exact moment you need it - you were asked for either a write lock or a read lock, that's what you're stealing. So, you write code which does what it can without the context, always steal the write lock. Oops. Bug.

And yet several people insist that this wasn't a bug it's actually the proper way for this to function. Not only in this github ticket, and in the Microsoft internal bug, but I saw several third parties defend the bug as obviously the correct way for this to work.

Fortunately it seems STL understood that and the internal ticket was eventually fixed and (presumably) in Windows 11 today this bug is fixed.

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

#240

In Scotland, they close an issue by taking a vote of "OK", "Broken", or "Not Proven". I believe they also have attorneys. Perhaps that's how Apple could make bug-tracking more effective -- hire a prosecuting attorney and a defending attorney for each bug.

Not any more, 'Not proven' was abolished at the start of this year.
Post reply on HN