Re: Suggestion for a new GNATS policy

[Nathanael Nerode <neroden at twcny dot rr dot com>]

>Yes it is. Reconfirmed is either true or false. There is no "kinda 
>reconfirmed".
Sadly, this isn't actually true.  Explanation follows...

> The time when something was reconfirmed is just extra info about 
>*when* the state happened, not information stored in the state itself. 

The date something was reconfirmed indicates *which snapshot of GCC* it 
was confirmed with.  This turns out to be very important information.  
If I indicate "Reconfirmed on 3.2 branch, not present on 3.3 branch, 
present on mainline", *plus* the date on which I did this, it contains a 
lot of information.  This isn't boolean at all.  Also note that the 
timestamp isn't technically the date I confirmed it, it's the date of 
the CVS sources I confirmed it with, although those are usually the 
same.

Essentially, we're encoding, for each active branch, the state (present 
or not present) on that branch as of a particular date.  There are many 
correct ways to do this, but it's far from being  boolean information.  
I welcome suggestions from the other regular 'bug  managers' as to what 
would be best.

The audit trail entries for confirmations (as of particular dates) are 
useful for tracking *when* a bug was fixed, as well.

The simplest way is the date-in-the-title currently used.  Each time a 
branch dies (for instance, the 3.2 branch will die when 3.3 is 
released), all reports confirmed prior to the branch 'death date' should 
be checked to make sure that they weren't already confirmed fixed on the 
active branches.

--
Here's a more complex proposal, which I think actually gets at the 
heart of the issue:

For each active branch, there's a flag "Confirmed present in this 
branch" and a flag "Confirmed absent in this branch".  (There should 
also be corresponding flags for actual past releases.)  This is 
what maintainers generally will poke, rather than the bug state.  (Two 
flags are necessary because of the third state: uncertain.  Programmatically, 
setting one should unset the other.)

For automated maintenance, do the following.  Maintain a list 
of 'live' branches.  Confirmation on any live branch makes a bug 
confirmed ('NEW' rather than 'UNCONFIRMED').  Confirmation of 
absence from all live branches closes a bug.  When a branch dies, 
run a script through the bug database; any bug confirmed absent on all live
branches is closed as fixed.  When a branch splits, clone the tags from 
the branch it split from (usually mainline).  

It should be easy to query when (and by who!) the 'confirmed in branch 
X' flag was last set, so that you can easily check for:

* Reports never confirmed present or absent on branch X (need testing)
* Reports confirmed present on branch X, but only before date Y (need 
retesting)

This should be easy to combine with other tests, so that I can search 
for (for example) reports not tested or tested prior to date Y on the 
3.3 branch, but confirmed present on mainline as of date Y.

There's no need under this complex scheme for special regression 
markers; reports confirmed absent on an 'old release' and present on 
branch X are regressions for branch X, and it should be easy to do a 
search for that.

Can it be done?  Does it sound good?  :-)

--
Ugh.  I realized an alternative means of implementing the same thing: 
have a bug STATE field for *each* branch, which is unfortunately the 
correct thing, but is probably close to impossible in Bugzilla.

"Analyzed" (i.e. reduced) should certainly be a flag; it's not nearly so 
complicated as 'confirmed'.  :-)

--Nathanael