Re: proposal for changes to auto-expiring bugs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- 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@xxxxxxxxxxxxxxxxx>
> --
> devel mailing list
> devel@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux