Hacker News new | ask | show | jobs
by CoolGuySteve 84 days ago
That the ~50000 engineers at Apple are conspiring to close your tickets in the exact same way. It's ridiculous
2 comments

> 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 who promised it would get looked at, but that I wouldn't hear back.

Microsoft wouldn't fix my issues either, but at least they got back to me in a timely fashion. Usually telling me it was a known issue that they weren't going to fix.

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 wrong or some subtly different issue so they ask you if it still reproduces in whatever version contains the fix before closing it.

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.

Not my tickets specifically. I don't think they're out to get me individually. On the contrary, this is a common practice, which affects many developers. I just happen to be relatively loud, as far as blogging is concerned.
Yes I understand that. ~50000 engineers aren't conspiring to close all tickets that way. It's a stupid line of thinking.

More than likely your steps to reproduce are too laborious to receive attention relative to the value fixing the bug would provide. That's why they're asking you to verify it still happens. Seems pretty simple right?

There's also a strong chance your ticket was linked as a duplicate of some other issue that was fixed in the beta and they want you to verify that's the case but they won't expose their internal issue to you for a variety of reasons.

> ~50000 engineers aren't conspiring to close all tickets that way.

I didn't say that either. It's happened to me only sporadically, but multiple times.

I agree with you that teams within Apple manage their own tickets. Perhaps some individual teams are declaring bug bankruptcy at some point, so only their bugs would go out for verification. I don't really know. I wish I did. What I do know is that multiple teams have done this at different points.

There's indisputably a company-wide DevBugs canned response for this. It's the same exact language every time. You can even Google it.

> It's a stupid line of thinking.

Please respect the HN guidelines: https://news.ycombinator.com/newsguidelines.html

> More than likely your steps to reproduce are too laborious to receive attention. That's why they're asking you to do it.

It was much more laborious for me, because I do not install the macOS betas.

> Seems pretty simple right?

No, it doesn't explain why specifically, after 3 years, they were suddenly asking me to verify with macOS 26.4 beta 4.