Re: Suggestion for a new GNATS policy

[Daniel Berlin <dberlin at dberlin dot org>]

On Sunday, May 11, 2003, at 10:03  PM, Giovanni Bajo wrote:

> Daniel Berlin <dberlin@dberlin.org> wrote:
>
> > > 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.
>
>
> It's not a boolean flag.

Yes it is. Reconfirmed is either true or false. There is no "kinda 
reconfirmed".
The time when something was reconfirmed is just extra info about *when* 
the state happened, not information stored in the state itself.
>  Either a bug has been confirmed 2 day ago, 2 weeks
> ago, 2 months ago or 2 years go, they're all different situations.

You've just missed the last sentence apparently, or aren't really 
thinking about it.
We know it was reconfirmed (a boolean, since it's only ever true or 
false that something has been reconfirmed)
Bugzilla knows *when* it was reconfirmed.

Thus you *have* a timestamp.
Just not one *you* need to explicitly fill in. You just set the flag or 
not. It records the timestamp on the change for you when you do.
You can query *when* the reconfirmed flag was set, or *whether* it is 
set.
This is what the flag allows you to do.
Hell, you can make the flag requestable if you want, so you can request 
that someone reconfirm the bug on your own.
It can auto-cc someone on requests, too.

>  Since
> GNATS doesn't have a field for this, we're putting it into the 
> synopsis.

Please put it somewhere else, since
1. It is as a temporary measure (since we are moving soon)
2. I can't remove it during conversion easily, and it'll uglify reading 
bug lists since some bugs have them, and others don't. Adding it to the 
front will also cause it to truncate some of the actual description.
Already we have crap like:
"[2003-05-03] [diagnostic] Bug in template type in error m..."

Showing up in queries.

Nobody can even tell what this is a bug about anymore.  The fact that 
it was confirmed 2003-05-03 doesn't help anybody, but the fact that 
[2003-05-03][diagnostic] takes up 33% of the summary line hurts 
everyone.

diagnostic should be a keyword (or component), but i can handle this in 
the converter easily.

I can't easily remove or convert the [2003-05-03] part, because other 
people have dates in summary lines for other reasons.




> I
> would not mind Bugzilla to have such a timestamp.

You already have one when you define the flag.


--Dan