Fwd: closing out old bugs of unmaintained releases

[John Poelstra]

Till Maas said the following on 01/08/2008 07:36 AM Pacific Time:
> On Sun January 6 2008, Jon Stanley wrote:
>> On Jan 6, 2008 12:39 PM, Bruno Wolff III <bruno at wolff.to> wrote:
>>> Is there a preference on which version number(s) should be used if a
>>> problem exists in more than one version? Is it documented somewhere?
>> One bug == one problem with one version.  Use the clone feature of
>> Bugzilla (IMO, we need to solidify this at FUDcon - adding to my list
>> at [1].  Anyone should feel free to edit this.
> 
> Imho having a bug cloned up to four times is too obfuscating / unclear, but 
> having another mechanism to track for which releases a bug is there would be 
> nice, e.g. additional flags:

You mean "fixed in rawhide" doesn't help? ;-)

> fixedF7
> fixedF8
> fixedRawhide
> 

An interesting idea, but I think it would be better to be able to have 
more specific "closed--resolved in" information vs. more flags.

> "?" unfixed
> "-" wontfix
> "+" fixed
> " " unclear, whether it needs to be fixed.
> 

This is redundant and the same as the closed states we already have.

> Then when F9 is released and the bug is still open:
> copy status from fixedRawhide to fixedF9
> One month later, when F7 is EOL:
> remove fixedF7 flag.
> In case now all flags are "+" or "-", e.g. because the issue was fixed in F8 
> and F9 / Rawhide, close the bug with an explanation, that one needs to update 
> the release to fix the bug.

Who is going to be the flag person--more triagers?

> Opposite to cloning bugs, this would keep the discussion of the bug in one bug 
> reports instead of possibly splitting it through differen reports. Another 
> possibility would be to use keywords, e.g. FixedF7 UnfixedF7 WontfixF7.
> This would even work without someone needing to reconfigure Bugzilla.
> 

This seems like the most sane idea to me :)  Or one of the whiteboard 
fields, except that whiteboard fields do not do any data validation.

John