On Wed, Feb 05, 2014 at 02:50:59PM -0800, Adam Williamson wrote:
> 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.
I would like to see one of the following, in order of preference:
1. Step one: when a release hits EOL, move the bugs to NEEDINFO with
a notice similar to the current one. (Essentially moving the current
warning back a little bit.)
Step one point five: I believe pretty much anyone can clear the NEEDINFO
flag.
Step two: when the *next* release hits EOL (and the release under
consideration has been EOL for approximately 6 months), move any bugs
still in NEEDINFO to a new closed resolution like CLOSED:EOL, with a
message similar to the current EOL note.
EOL wouldn't be visibile as an available status for bugzilla users to
select when closing a bug in the interface, so it does not add to UI
clutter, but also makes it easy for us to do reports distinguishing
between intentional and eol closure.
This gives a much longer timeframe where we're waiting for input, so by
the time we actually close, the release has been EOL for a decent while
(rather than now, at the "I just got around to updating!" point).
This does risk some false positives (negatives? whatever) where NEEDINFO
is cleared with "works for me" but the bug not closed, but that seems
like a less serious problem.
2. As #1, but with no new CLOSED:EOL resolution. Instead, use WONTFIX or
and add a ClosedEOL keyword automatically. This is uglier than the above
but requires no bugzilla change.
3. As #1, but just leave bugs in NEEDINFO state forever.
This would possibly require maintainers to update their searches /
filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs from older
releases.
Any of these seem pretty easy and I think would improve the situation for
users and bug reporters without badly increasing maintainer burden or being
dishonest about our ability to fix all the things.
Additionally, but requiring some development, we could add some heuristics
like: don't autoclose bugs with many incoming duplicate pointers, or
possibly (as David suggests) bugs with comments, or bugs which have been
reopened, or (here I get handwavy).
--
Matthew Miller -- Fedora Project -- <mattdm@xxxxxxxxxxxxxxxxx>
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
