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

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.

▲

eszed 5 hours ago | parent | next [-]

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 5 hours ago \| parent \| next [-]
		>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
	▲	tetromino_ 3 hours ago \| parent \| prev [-]
		> 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.

▲

ComputerGuru 5 hours ago | parent | prev | next [-]

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 34 minutes ago | parent | prev | next [-]

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 18 minutes ago \| parent [-]
		> 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.

▲

jeffbee 5 hours ago | parent | prev | next [-]

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 5 hours ago | parent | prev [-]

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 5 hours ago \| parent [-]
		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.