On Thu, 2014-02-06 at 13:21 +0100, Michael Schwendt wrote:
Has that been tried before? It sounds like a better approach.
Not while I've been around, at least.
Where is the human to notice "comments after EOL" and act
accordingly?
There are always a minimum of two people active on any ticket who can
change it in any way: the reporter and the assignee.
How many tickets would be affected by a "comment after
EOL"?
Don't know, probably wouldn't be too hard to look.
What is the underlying problem here anyway?
I've never been hugely convinced there is one, but the problem people
*claim* there is is that closing bugs on EOL releases gives a bad
impression to people who report the bugs.
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?
Why do you think they're any more likely to get a response if the bug
stays open?
> 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.
We already don't have enough time to look after all the open bugs we
have. Why are things going to be better if we have more?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net