31–40 of 314 posts
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
Earlier quoted context omitted.
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)
https://devblogs.microsoft.com/oldnewthing/20241108-00/?p=11...
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…
I've heard this from others before but I really don't understand the mindset.
What's the harm in keeping the bug open?
Earlier quoted context omitted.
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.
In any case I would have said it sounds difficult on every front
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…
In this case the bug wasn't fixed.
> A lot of teams simply close Radars that remain unverified for some amount of time because they are being "graded" on this.
The simple solution here: you should also be graded on closing bugs that get re-opened.
Earlier quoted context omitted.
I was literally just coming in here to comment "in before someone says this is fine and there's no issue." and the first(!) comment is effectively "this is fine and there's no issue." The sentiment feels like software folks are optimizing for the local optimum. It's the programmer equivalent of "if it's important they'll call back." while completely ignoring the real world first and second-order effects of such a pol…
Considering Apple is one of the largest companies in the world, raking in money, what consequential effects are you talking about? It certainly doesn't seem to hurt their bottom line, which is the only thing they care about. As a software developer, I don't have any problem with this. If a bug doesn't bother somebody enough for them to follow up, then spend time fixing bugs for people who will. Apple isn't obligated…
:)
Funny at first but I’m coming around to that perspective
Earlier quoted context omitted.
I was literally just coming in here to comment "in before someone says this is fine and there's no issue." and the first(!) comment is effectively "this is fine and there's no issue." The sentiment feels like software folks are optimizing for the local optimum. It's the programmer equivalent of "if it's important they'll call back." while completely ignoring the real world first and second-order effects of such a pol…
I've seen this in many teams and it always drives me nuts: "hey this ticket is old and we didn't bother, let's delete it to keep the board clean". You feeling accomplished by seeing an empty list is not the goal!
to be fair this is pretty common spring cleaning in any bugzilla...
I was literally just coming in here to comment "in before someone says this is fine and there's no issue." and the first(!) comment is effectively "this is fine and there's no issue." The sentiment feels like software folks are optimizing for the local optimum. It's the programmer equivalent of "if it's important they'll call back." while completely ignoring the real world first and second-order effects of such a pol…
These auto-closing policies usually originate from somewhere else.
to be fair this is pretty common spring cleaning in any bugzilla...
I was literally just coming in here to comment "in before someone says this is fine and there's no issue." and the first(!) comment is effectively "this is fine and there's no issue." The sentiment feels like software folks are optimizing for the local optimum. It's the programmer equivalent of "if it's important they'll call back." while completely ignoring the real world first and second-order effects of such a pol…
Plus, I’ve been in jobs where fixing bugs ends up being implicitly discouraged; if you fix a bug then it invites questions from above for why the bug existed, whether the fix could cause another bug, how another regression will be prevented and so on. But simply ignoring bug reports never triggered attention.