Live data from Hacker News

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

lapcatsoftware.com

291–300 of 314 posts

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

#291
post #194
post #161

Earlier quoted context omitted.

just bc everyone is calling you insane: you are being extremely reasonable.

Flagging isn't supposed to be used as a super downvote. There's a term for the bizarre behavior and thought processes (read: justification) by the person you're responding to. https://en.wikipedia.org/wiki/Occupational_psychosis > > you are being extremely reasonable They're not. If there's nothing wrong with it, one could ask whether the person here would be okay sitting in a room with their supervisor, the head of…

[dead]

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

#292
post #99

Earlier quoted context omitted.

I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eite…

I hate that so much. It's everywhere. An example is a bug with discord. They wanted me to restart my phone, reinstall the app, what are my versions, what phone am I on, what settings, etc. After all of that they go "oh that's a known issue." Whyyyyyyyyyyy. I get that multiple things can have the same symptom, but maybe start with that. Not like I signed any NDA so they aren't hiding it's an issue from the public.

You know what was the saddest thing? After all that effort, I got some blow-back for the fix taking so long.

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

#293
post #99

Earlier quoted context omitted.

I recompiled OpenSSL to make s_server -www return the correct, static XML blob for a .NET application that was buggy to make a reproducer for them that didn't rely on our product at all and which could be self-contained on a very barren windows VM they could play with to their heart's content and which didn't even care about the network because everything was connecting via loopback, so they couldn't blame that, eite…

I hate that so much. It's everywhere. An example is a bug with discord. They wanted me to restart my phone, reinstall the app, what are my versions, what phone am I on, what settings, etc. After all of that they go "oh that's a known issue." Whyyyyyyyyyyy. I get that multiple things can have the same symptom, but maybe start with that. Not like I signed any NDA so they aren't hiding it's an issue from the public.

The actual soln is to use oss stuff and aggressively send claude code into the weeds whenever you find a big, then upstream the fixes.

I switched from IntelliJ to emacs for this reason and it’s been great

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

#294

Earlier quoted context omitted.

There's also going to be mountains of bugs resulting from cosmic rays hitting the computer, defective ram chips, weird modifications of the system the reporter hasn't mentioned. You could sink an infinite amount of time investigating and find nothing. At some point you have to cut off the time investment when only one person has reported it and no devs have been able to reproduce it.

If bug contains instructions for reproduction most of that will be eliminated.

Quite often reproduction information will only reproduce the bug in the customers environment, hence there is a lot of incomplete state on what is actually causing the problem.

It's pretty terrible in enterprise because there is so much 3rd party crap touching things it shouldn't that love to cause fun problems.

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

#295
post #85

Earlier quoted context omitted.

I also hate this pressure of it being on the user to come up with a minimal reproducing example. That means that any bug of any moderate complexity will never get fixed because you can't always reduce them to a few steps and they may be statistical. A bug is a bug, no matter the developers' opinion or the complexity of the bug.

However there are "bugs" that actually do turn out to be just cosmic rays flipping bits or plain user error. If you as the reporter don't provide enough information for the developer to be sure they are not going on a wild goose chase then it's fair for the developer to not invest too much time.

Sure. But I'm biased because I was a "customer" of a former (large) company's products while also working at that company. So the bugs I would file were the type that a customer would file, but since I was inside, I saw how they were handled. The tactics that my fellow R&D developers would do to claim something wasn't a bug or reproducible were nearly endless.

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

#297

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

I filed an issue, they told me to get in GitHub, fix it and file a PR myself O_o. In fairness they bugged me and cajoled me and offered to help until I actually did it, which I actually appreciated in the end because the experience was useful. (Give a man a fish, etc...)

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

#298

Earlier quoted context omitted.

With a popular open source project, you'll quickly get to a number of bug reports that you have no chance of ever solving. You will have to focus on the worst ones and ones affecting most users. At the same time, you want to communicate to users that this is the case so they don't have wrong expectation. But also, psychologically it is demotivating to have a 1000+ open bugs queue with no capacity to re-triage and onl…

The problem is that your users also have limited time and if it's clear you're not even looking at issues where someone has put in lots of effort to help you then you're only going to get lazy issues and it will actually take more effort from you to do all that work yourself if you want to reach the same software quality.

I think you are missing the point: a user putting in a lot of effort into a bug report is usually trying to help themselves get the bug fixed.

As a maintainer, you will obviously look at that bug with more appreciation: but if you estimate it will take you 3 months of active development to fix it that you will have to spread over a full year of your weekends (which you can't afford), what would you do?

And what would a reasonable user rather see? Yes, this is an issue, but very hard to fix, and I don't have the time, or just letting the bug linger?

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

#299

Earlier quoted context omitted.

That kind of attitude disgusts me. Like it's someone else's job to have a sense of accountability. They would not remain employed in my company. When I developed software I would jump right on top of any bug reports immediately, and work until they were fixed. I was grateful to my customers for bringing them to my attention.

It is different when you have a billion customers, all with different setups. At that scale, you notice real defects through product telemetry, support ticket volume, or trusted channels. You receive a high volume of bug reports that are due to user confusion, misconfiguration, or misbehavior of other software on the device - where solving an issue for one customer doesn't result in improvements for the other billion…

I got a lot of those too, it meant I inevitably did a little bit of free tech support for my customers. In the end I felt it was worth it as they raved about the quality of support and it was a real differentiator - not to mention built a lot of brand loyalty (and internal staff loyalty too once I grew enough to build out a team - they derived real satisfaction from actually solving problems instead of playing ping-pong).

I agree regarding the need to triage at scale, unfortunately most large companies I've encountered fail to do this well and seem ill-equipped to accept high quality bug reports of edge case defects generated by expert users (save for the odd exception that arrives by social media from someone who happens to have enough followers to get their attention outside the regular support pipeline).

In my experience this doesn't usually boil down to a systems issue (the ticketing systems etc. exist that should theoretically allow for eventual escalation to the right engineer/developer) but a corporate culture thing (the company just doesn't prioritize customer feedback especially at the level where staff who actually deal with customers interface with the teams that write/maintain the software). Often it's genuinely valued at the C-level (the Bezos story of calling Amazon"s tech support line during an exec meeting is a fun example) but diluted somewhere between them and the rank-and-file.

(Ps. I'm not arguing with you and appreciate you took the time to craft a thoughtful reply)

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

#300

Earlier quoted context omitted.

Bug reports are not known defects, at any kind of scale half of them will be already fixed, misunderstandings, bad data in, or related to an unusual setup. Closing the bug is a way of saying: sorry this doesn’t look too important and we don’t have time to look at this given the other more important things (bugs/features) we plan to work on. If it’s closed as stale after 6-12 months (multiple humans will have seen it)…

> at any kind of scale half of them will be already fixed, misunderstandings, bad data in, Here you're referring to a class of bug reports that's uninteresting for this discussion, because they're invalid (i.e. they don't represent an actual bug). We're talking about valid bugs that have not been fixed. > or related to an unusual setup Unusual, but ostensibly supported? Then there exists a bug.

These rules are in place because that first class of 'bugs' is the majority of bug reports when you are at scale.
Post reply on HN