Re: Suggestion for a new GNATS policy

[Daniel Berlin <dberlin@dberlin.org>]

>> Aieee, please no.  There are so many analyzed PRs that are
>> unassigned, so what you say here would only make things harder.
>
> Me too: Aieee, please no!
> We would lose a *lot* of valuable information and would force much more
> work on the bug fixers, leaving the "bug report preprocessors" 
> unemployed.
>

Use bug flags, not states.
The bug is still fundamentally the same state (around but unfixed), 
regardless of whether verified or the testcase is minimized.
They are boolean flags, not states.

> If we cannot get these states into bugzilla, we could make dummy

We don't *need* these states. You need to add a few boolean flags.

> maintainers called "CONFIRMED" and "ANALYZED" etc. to whom we assign
> the PRs, but that's only an ugly kludge.

>> (Yes that's very much like what we have in GNATS now, but that's 
>> because
>> GNATS is not so bad, really.  It just misses one or two states and 
>> its user
>> interface is very poor.)
>>
>>>> 2) To close the PRs that got fixed silently the PRs have to
>>>> be revisited from time to time. But there should be some way
>>>> to give the PR's a time stamp so that one can easily see
>>>> (without having to read the whole audit-trail) when a PR
>>>> should be revisited again.
>>
>> There's also the "Last-Modified" field, what is wrong with that?
>
> Because a new addition to the audit-trail doesn't mean that the
> PR was really rechecked. Modified doesn't imply reconfirmed.
>
Hence the need for a boolean flag.
I can have it auto-reset them every 30 days a bug isn't touched or 
something, if you like, as a cronjob.
There's still no need for a full timestamp, because it knows when the 
flag was changed anyway.
>>
>> You can do that with GNATS, too.  Just not very user friendly,
>> it _can_ be done.
>
> Once again: "touched" doesn't mean "reconfirmed".
>
I've already addressed this with a flag.