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: "Christian Ehrhardt" <ehrhardt at mathematik dot uni-ulm dot de>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: 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, bangerth at ices dot utexas dot edu
- Date: Mon, 12 May 2003 17:10:47 +0200
- Subject: Re: Suggestion for a new GNATS policy
- References: <20030512105903.2201.qmail@thales.mathematik.uni-ulm.de> <1DA06D5A-8481-11D7-87A1-000A95A34564@dberlin.org>
On Mon, May 12, 2003 at 09:53:31AM -0400, Daniel Berlin wrote:
> >How am I supposed to store the fact that I reconfirmed a bug with a
> >two day old cvs-Snapshot? Also unsetting and resetting a flag
> >to achieve this is just plain ugly. This information is just
> >fundamentally
> >NOT a flag. Actually it is not even a timestamp of some bugzilla
> >action,
> >it is the date of a CVS-Snapshot.
>
> BTW, this is not what i was told at the beginning.
> I was told it was simply a timestamp of when the bug was last
> confirmed, not the date of the version it was CVS snapshot it was last
> confirmed with.
I agree that this wasn't perfectly clear from the discussion.
> These are two very different things. In fact, it's not even a
> timestamp in the second case, it's a date-only field (IE no
> hour:minute:secs)
> Can someone please clarify which is correct?
I can't speak for others but hours, minutes and seconds are most
definitely irrelevant wrt. the "last confirmed"-field. Also it just
isn't useful to say, "I reconfirmed this at this date" unless the
date implies something about the snapshot/version used to reconfirm
the bug, hence we can use and IMHO should use the date of the snapshot in
the first place.
> If it's the second, you'll need a new field, i'll add one and make it
> visible only to bug triagers.
That's all I'm asking for.
> You still do *not* need a new field for representing things like "this
> bug has a minimized testcase", however.
I very much like the idea of having a boolean flag for this! Time will
show what other flags we might actually need. The main objections that people
currently have against encoding these as flags as far as I can see is,
that some of the information that is supposed to be in these flags is
now encoded in PR states and that this information would be lost during
conversion. This is unfortunate but not really a reason to continue
encoding boolean information in the states.
Side note: Is there an easy way to have tri-states instead of booleans?
The three states would be
* yes (has small testcase)
* no (needs small testcase)
* inappropriate (doesn't need small testcase (e.g. typos in comments))
If there isn't we should probably document what should be done with
flags if the flag is inappropriate for a certain bug.
regards Christian
--
THAT'S ALL FOLKS!