This class of problem will soon be fixed with LLM agent that can just say "Yes, I can verify this is still not fixed". You just post the issue and then hook it up to your agent and forget about it. It can keep posting that there is an issue. It could even "bump! this is affecting crucial internal workflows" or similar every now and then.
Apple randomly closes bug reports unless you "verify" the bug remains unfixed
241–250 of 314 posts
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#242Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#243Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#244Earlier quoted context omitted.
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.
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.
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#245It’s quite possible (likely, even) for there to be more bugs reported than Apple has capacity to investigate. I assume this is just a filter they use to get the queue down to a more reasonable size and remove bug reports that are especially old (trusting that if they’re still issued they’ll be re-reported). This kind of culling happens all the time with low pri stuff and even sometimes medium pri if there’s a clear w…
This is where a company that categorizes customer feedback like unwrap.ai or enterpret could help with volume and priority
No.
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#246I 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…
> keeping the bug open when realistically I can't really do anything with it might be worse I've heard this from others before but I really don't understand the mindset. What's the harm in keeping the bug open?
Craig shows up under your bed.
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#247> perhaps praying that the bug had magically disappeared on its own, with no effort from Apple. I suspect that this is a common approach. It maybe even works, often enough, to make it standard practice. For myself, I've stopped submitting bug reports. It's not the being ignored, that bothers me; it's when they pay attention, they basically insist that I become an unpaid systems engineering QC person, and go through e…
> they basically insist that I become an unpaid systems engineering QC person Microsoft support is guilty of this, especially for Azure & 365 issues. Like sorry, but you aren't paying me to debug your software. Here's a report, and here's proof of me reproducing the problem & some logs. That's all I'm going to provide. It's your software, you debug it.
And based on my own personal experience, even if you persevere and force them to acknowledge the problematic behaviour, they can turn around and say it's not a problem and working as intended.
For example, when using Azure Front Door, it's apparently absolutely not a problem that as yet un-cached file in their CDN downloads from their own Azure Blob storage have a maximum download speed of around 2MB (16Mb) per second:
Them:
> Hello Jonathan,
> I hope you are doing well!
> I sincerely apologize for the significant delay in our response, which was necessary to conduct further internal testing.
> After a comprehensive review, we have determined that the behavior you are experiencing is typical for this type of operation.
> This is primarily due to the connection not being entirely directly, as it must pass through Azure Front Door. This process also involves distributing the cache among point-of-presence (POP) servers, which inevitably impacts the > operation's speed. Let me provide you with documentation covering that matter:
Me:
> So to be clear, Azure Front Door maxes out at less than 2MB/s (16Mbit/s) for uncached items even when everything is on Microsoft’s own servers?
Them:
> Hello Jonathan,
> Thank you for getting back to me.
> These values may vary by region, but those particular ones apply for South Africa North.
I also tested this behaviour in US and EU regions (from an Azure VM requesting a file from Azure Blob storage in the same region as the VM but via Azure Front Door) and in EU it was also similarly limited while in the US it was only a tiny bit better.
We use Cloudflare now, cheaper, faster, configuration UI which isn't painfully slow. Not without their own recent incidents, but better than Azure Front Door 99.99% of the time.
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#248Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#249All 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…
You're right in that it's unreasonable to expect someone else work for you for free
But I would also say a quality bug report is a contribution in and of itself
Closing it without reason is also, literally, unreasonable
Re: Apple randomly closes bug reports unless you "verify" the bug remains unfixed
#250Earlier 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.
> 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. You can triage without closing tickets. So it is nefarious. It is metric hacking If you're having trouble reproducing, tag "needs verification" or something else. But closing a ticket isn't triaging, it is sweeping problems under the rug
Exactly. Thank you for saying this.