Suggestion for a new GNATS policy

[Daniel Berlin]

On Monday, May 12, 2003, at 10:28  AM, Wolfgang Bangerth wrote:

>
> About the reconfirmed thing:
> - Basically, "reconfirmed" is a list of dates of snapshots.
> - I'd say everybody agrees that a good approximation to this is a list  
> of
>   dates at which it was reconfirmed: we may use snapshots that are a
>   couple of days old, but not more. So let's make it simpler and take  
> the
>   date/time of reconfirmation, since bugzilla can determine that by
>   itself.

So you want a field that is just updated through button clicks,  
basically (IE you click reconfirm, it updates the date). That can be  
visible in queries, and is querieable in terms of "has it changed in  
the past x days " and "has it not changed in the past x days".
Right?

> - Just as much, nobody really cares about previous dates, so it would  
> be
>   ok to just store the last time something was reconfirmed
>
Okeydokey.
Otherwise it requires a new table.

> Why a separate field (and why we store it in the symposis at present):
> - it needs to be visible (see below why); the audit trail is not, at  
> least
>   not in queries

I forgot to mention, you guys can make the full summary line visible.
Click "Change columns" on a bug list.
Check "Full summary", uncheck "Summary (First 60 chars)".
It'll then give you the full summary.
It saves these preferences for you automatically (using cookies).

> - reconfirming should be simple; bumping a date was considered simpler
>   than sending an email
That's fine.

> - by point 3 above, nobody cares about previous reconfirmations, so  
> we'd
>   like not to clutter the audit trails with pages of reconfirmations.
>
That's fine too.

> Given the last point, I would very much dislike reconfirming a bug by
> clearing-resetting the flag, since that would add _two_ more (and above
> that: useless) entries to the audit trail.

That's fine.

>
> My optimal solution would be a button "Reconfirmed" that I could click,
> that bumps the date of a respective (queryable) field, and that  
> otherwise
> leaves no mark in what I will usually see when I look at the audit  
> trail.
>
That's fine too.
Can you guys at least do Minimized and whatnot by flag?
I really don't want to add *too* many fields, and it seems that *most*  
of these things are booleans.
Like the existence of a minimized testcase for a bug or attachment.


>
>> Developers only care the bug is still valid, remember.
>
> That's too simple, Dan. We are talking about different communities, and
> the community that spends the most time with GNATS/bugzilla are what  
> you
> termed bugmasters. I tend to think they do valuable work and it would  
> be
> unfair to neglect their needs. The "reconfirmed date" information is
> clearly important to them (otherwise we wouldn't go to such length to  
> put
> it into the synposis of _every single_ C++ report), so please don't  
> make
> it harder than necessary.

I'm not, i'm just trying to make sure they realize that the bug system  
is not *only* for them, and that the main complaint about GNATS is it's  
interface.
Cluttering the interface is something i don't take lightly.
I'm willing to make it look different for different communities if  
necessary, which is what will happen here (the reconfirm button will  
only appear for people in certain bug groups, for simplicity sake).
We have more than just Developers and bugmasters anyway. We have users  
too, and it needs to be usable for them, too.

I'm just trying to get a concrete set of what you are trying to do, so  
i can figure out the best way to do it.
It's almost never a case that i *won't* do it, it may just entail a  
discussion of what you really need to be able to do vs what is easiest  
to provide (and is it enough).


>
> W.
>
> ----------------------------------------------------------------------- 
> --
> Wolfgang Bangerth              email:             
> bangerth@ices.utexas.edu
>                                www:  
> http://www.ices.utexas.edu/~bangerth/
>
>