proposal for changes to auto-expiring bugs
Jaroslav Reznik
jreznik at redhat.com
Thu Feb 6 12:30:44 UTC 2014
----- Original Message -----
> 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.
I'm not sure adding a new EOL status would be ok for Bugzilla guys, as far
as I know, there were some efforts to cut down BZ statuses (ON_DEV for
example), even it would be hidden. So keyword looks like much more easier
solution.
Jaroslav
> 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 at fedoraproject.org>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More information about the devel
mailing list