On Wed, 05 Feb 2014 14:50:59 -0800, Adam Williamson wrote: > On Wed, 2014-02-05 at 22:48 +0000, Colin Macdonald wrote: > > On 05/02/14 22:42, David Timothy Strauss wrote: > > > This is also not the first time this has happened to me. > > > > I'll chime in: when I first switched to Fedora (F14/15 era), I found > > this quite obnoxious, enough that I remember it. > > > > So there is also an issue of being a welcoming community to newcomers. > > The problem is that no-one seems to come up with an alternative that's > any better. Leaving bugs on EOL versions open to rot away and be ignored > is no use. We *could* give everyone privs to re-open closed bugs, I > guess, and I personally don't think that would end terribly, but it's > kind of a radical plan. > > The idea of not closing bugs that have comments after the EOL > notification doesn't necessarily make things better, I don't think; we'd > just have errors in the other direction. Say someone dropped a note 'oh > yeah, this is working now!' - it would be silly not to close the bug, > right? Has that been tried before? It sounds like a better approach. Where is the human to notice "comments after EOL" and act accordingly? How many tickets would be affected by a "comment after EOL"? What is the underlying problem here anyway? Too many unhandled tickets -> EOL auto-close threatening -> too many closed tickets to handle -> how to escape from that loop? In several large upstream bug trackers it is no different. Are developers always informed about what doesn't work even when not responding to tickets? Why should users still take the time to submit problem reports if they don't get a response? > algorithms are never perfect, but we do have to use them, as a > perennially under-resourced project. I've posted about it in 2008 already, and I still think the auto-closing leads to hiding crap under the carpet. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
