4 ms·

to be fair this is pretty common spring cleaning in any bugzilla...

by cozzyd 7mo ago

jeffbee 7mo ago
It's very common but it's still a poor practice.
- methodical 7mo ago
  Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
  - jeffbee 7mo ago
    Closing bugs because they can no longer be reproduced: obviously fine. Closing bugs automatically after a cron job demanded that the user verify reproducibility for the 11th time: obviously bad.
  - convolvatron 7mo ago
    the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion. if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it. otherwise you're just throwing away useful information. edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem
    - jeffbee 7mo ago
      Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.
  - eszed 7mo ago
    Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.
    - Barbing 7mo ago
      >creates the user expectation that "no one looks at these Apple has done the best job of creating this expectation. Apple Feedback = compliments (and ideas) Public Web = complaints & bug reports Apple Support = important bug reports (can create feedback first then call immmediately) — Prev comment w/link (2mo ago): https://news.ycombinator.com/item?id=46591541 https://news.ycombinator.com/item?id=46591541
    - tetromino_ 7mo ago
      > try to reproduce on a current build Good luck doing that when the bug report (like virtually all bug reports in nature) doesn't provide sufficient reproduction steps.
      - eszed 7mo ago
        I agree with you about that, but why would an ill-defined report be kept open in the first place? It shouldn't be. Give the user an opportunity to provide more detail - for my own use I have some auto-text "scripts" set up, to make prompt questions easy - and then auto-close after a few days. [Edit, answering my own question: they're left open because they were ignored to begin with.] I write excellent bug reports, the vast majority of which (I'm thinking of one service-provider in particular, may they live in shame) get ignored. Or escalated and ignored; somehow that feels worse, though I don't know if it should. I guess it's the hope. It's the hope that kills you.
  - ComputerGuru 7mo ago
    Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.
  - PunchyHamster 7mo ago
    sure. But you can say put "please verify whether it is still present" via bot before doing so. Which apple did and I'm not sure why blogpost author is complaining about that
    - lapcat 7mo ago
      > you can say put "please verify whether it is still present" via bot before doing so. Which apple did No, that's not what Apple did. They said, "Please verify this issue with macOS 26.4 beta 4", a very specific version, implying that they actually fixed the bug in that specific beta version (spoiler: they didn't). And I would have to go out of my way to install that specific beta just to "verify" the bug. Moreover, they gave me only 2 weeks to verify before closing the bug that they hadn't responded to at all in 3 years. They suddenly created artificial urgency for no apparent reason.
    - hrmtst93837 7mo ago
      [flagged]
gortok 7mo ago
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 policy.
- jlarocco 7mo ago
  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 to fix anybody's bug. It's not like they were nagging him about it - it's been years, and they had major releases in the mean time. Quite possible it was fixed as a side effect of something else.
  - Barbing 7mo ago
    >anybody's bug. :) Funny at first but I’m coming around to that perspective
  - Noaidi 7mo ago
    > It certainly doesn't seem to hurt their bottom line …yet
  - eszed 7mo ago
    This is exactly the mindset to which GP and I object.
  - gortok 7mo ago
    > It certainly doesn't seem to hurt their bottom line, which is the only thing they care about. I want to draw out this comment because it's so antithetical to what Apple marketed that it stood for (if you remember, the wonderful 1984 commercial Apple created; which was very much against the big behemoths of the day and the way they operated). We're at the point where we've normalized crappy behavior and crappy software so long as the bottom line keeps moving up and to the right on the graph. Not, "Let's build great software that people love.", but "How much profit can we squeeze out? Let's try to squeeze some more." We've optimized for profit instead of happiness and customer satisfaction. That's why it feels like quality in general is getting worse, profit became the end goal, not the by-product of a customer-centric focus. We've numbed ourselves to the pain and discomfort we endure and cause every single day in the name of profit.
hrmtst93837 7mo ago
[flagged]

to be fair this is pretty common spring cleaning in any bugzilla...

by cozzyd 7mo ago

to be fair this is pretty common spring cleaning in any bugzilla...

jeffbee 7mo ago

It's very common but it's still a poor practice.

methodical 7mo ago
Basically every single old bug report I've ever seen is essentially a red-herring that is usually not able to be reproduced anymore after N years and takes away time from focusing on newer and more solvable issues. I don't see the issue with removing that noise if it's no longer being reported, but to each their own I suppose.
- jeffbee 7mo ago
  Closing bugs because they can no longer be reproduced: obviously fine. Closing bugs automatically after a cron job demanded that the user verify reproducibility for the 11th time: obviously bad.
- convolvatron 7mo ago
  the right thing to do is to actually ping the original reporter if possible, or a developer that you might assign the bug to and try to drive it to a conclusion. if the answer is 'everything in that part of the code has been rewritten' or 'yeah, that was a dup, we fixed that' or 'there isn't enough information here to try to reproduce it even if we wanted to' or 'this a feature request that we would never even consider' or some other similar thing, then sure delete it. otherwise you're just throwing away useful information. edit: I think this difference of option is due to a cultural difference between (a) the software should be as correct as reasonably possible and (b) if no one is complaining then there isn't a problem
  - jeffbee 7mo ago
    Closing bugs because of a rewrite is probably the most harmful practice in the whole industry. The accumulated unresolved issues of your existing code base are a rich resource of test cases. Writing the new code base without checking to see if it fixes the old bugs is a mistake.
- eszed 7mo ago
  Sure. So try to reproduce on a current build, and close with a "No longer reproduceable on ___". That'd be good practice. Closing silently because no one can be bothered to evaluate at all is horrendous, and creates the user expectation that "no one looks at these, so I'm not going to keep reporting it" which "justifies" developers closing old bugs.
  - Barbing 7mo ago
    >creates the user expectation that "no one looks at these Apple has done the best job of creating this expectation. Apple Feedback = compliments (and ideas) Public Web = complaints & bug reports Apple Support = important bug reports (can create feedback first then call immmediately) — Prev comment w/link (2mo ago): https://news.ycombinator.com/item?id=46591541 https://news.ycombinator.com/item?id=46591541
  - tetromino_ 7mo ago
    > try to reproduce on a current build Good luck doing that when the bug report (like virtually all bug reports in nature) doesn't provide sufficient reproduction steps.
    - eszed 7mo ago
      I agree with you about that, but why would an ill-defined report be kept open in the first place? It shouldn't be. Give the user an opportunity to provide more detail - for my own use I have some auto-text "scripts" set up, to make prompt questions easy - and then auto-close after a few days. [Edit, answering my own question: they're left open because they were ignored to begin with.] I write excellent bug reports, the vast majority of which (I'm thinking of one service-provider in particular, may they live in shame) get ignored. Or escalated and ignored; somehow that feels worse, though I don't know if it should. I guess it's the hope. It's the hope that kills you.
- ComputerGuru 7mo ago
  Every other month I get an email from a legacy pre-GH bug tracker that's either a "me too" or "bug fixed in latest release" a decade after I filed these one-offs you would be so quick to throw away. Bugs with no activity for years on end.
- PunchyHamster 7mo ago
  sure. But you can say put "please verify whether it is still present" via bot before doing so. Which apple did and I'm not sure why blogpost author is complaining about that
  - lapcat 7mo ago
    > you can say put "please verify whether it is still present" via bot before doing so. Which apple did No, that's not what Apple did. They said, "Please verify this issue with macOS 26.4 beta 4", a very specific version, implying that they actually fixed the bug in that specific beta version (spoiler: they didn't). And I would have to go out of my way to install that specific beta just to "verify" the bug. Moreover, they gave me only 2 weeks to verify before closing the bug that they hadn't responded to at all in 3 years. They suddenly created artificial urgency for no apparent reason.
  - hrmtst93837 7mo ago
    [flagged]

gortok 7mo ago

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

jlarocco 7mo ago
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 to fix anybody's bug. It's not like they were nagging him about it - it's been years, and they had major releases in the mean time. Quite possible it was fixed as a side effect of something else.
- Barbing 7mo ago
  >anybody's bug. :) Funny at first but I’m coming around to that perspective
- Noaidi 7mo ago
  > It certainly doesn't seem to hurt their bottom line …yet
- eszed 7mo ago
  This is exactly the mindset to which GP and I object.
- gortok 7mo ago
  > It certainly doesn't seem to hurt their bottom line, which is the only thing they care about. I want to draw out this comment because it's so antithetical to what Apple marketed that it stood for (if you remember, the wonderful 1984 commercial Apple created; which was very much against the big behemoths of the day and the way they operated). We're at the point where we've normalized crappy behavior and crappy software so long as the bottom line keeps moving up and to the right on the graph. Not, "Let's build great software that people love.", but "How much profit can we squeeze out? Let's try to squeeze some more." We've optimized for profit instead of happiness and customer satisfaction. That's why it feels like quality in general is getting worse, profit became the end goal, not the by-product of a customer-centric focus. We've numbed ourselves to the pain and discomfort we endure and cause every single day in the name of profit.

hrmtst93837 7mo ago

[flagged]