That makes total sense. I imagine trying to track down a submitter from 1996 to ask for a re-test on NetBSD 10.x feels a bit more like digital archaeology than standard bug triage!
I can definitely see why they get stuck in limbo. Making a judgment call to close an ancient, sparsely documented bug sounds like a headache, especially when everyone's limited time is much better spent on active, modern issues. Thank you for peeling back the curtain and explaining the reality of it. It gives me a much better appreciation for the overhead involved in managing GNATS. Out of pure curiosity, I think I'll still browse through a few of those top 10 just to see what kind of edge cases managed to survive the turn of the millennium, but I completely understand why they are left to rest. Thanks again for the insight, and keep up the great work! Regards, Arya On Mon, 15 Jun, 2026, 11:17 pm Greg Troxel, <[email protected]> wrote: > Aryabhata <[email protected]> writes: > > > Thank you for the response, and my apologies if my initial email came > > across as a request for someone else to do the heavy lifting! That > > definitely wasn't my intention. > > > > My question was driven purely out of curiosity regarding how the project > > manages deep legacy PRs. I wasn't sure if there was a specific project > > policy to keep them open as historical documentation, or if they just > > simply hadn't been touched in a while due to more pressing priorities. > > > > I completely understand that bug triage takes a massive amount of > effort. I > > am more than happy to read through the list myself and see if there are > any > > I can assess or test on my end, though my expertise might be limited on > > issues. > > It is hard, and it often takes the ability to tell the submitter they > need to udpate to the latest version, retest, and file better debug > info. And then it's a judgement call to close as > unfounded/no-longer-reproducible. > > It's not super fun to grovel over bugs, especially if the bug report > doesn't come with substantial investigation from the submitter. That > tends to lead to them just staying open. >
