This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Suggestion for a new GNATS policy
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Wolfgang Bangerth <bangerth at ices dot utexas dot edu>
- Cc: Christian Ehrhardt <ehrhardt at mathematik dot uni-ulm dot de>,Giovanni Bajo <giovannibajo at libero dot it>,Volker Reichelt <reichelt at igpm dot rwth-aachen dot de>, <S dot Bosscher at student dot tudelft dot nl>, <gcc at gcc dot gnu dot org>
- Date: Mon, 12 May 2003 13:40:50 -0400
- Subject: Re: Suggestion for a new GNATS policy
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/