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: "Giovanni Bajo" <giovannibajo at libero dot it>
- To: "S. Bosscher" <S dot Bosscher at student dot tudelft dot nl>,"Daniel Berlin" <dberlin at dberlin dot org>
- Cc: "'Volker Reichelt '" <reichelt at igpm dot rwth-aachen dot de>,<gcc at gcc dot gnu dot org>,<bangerth at ices dot utexas dot edu>
- Date: Mon, 12 May 2003 04:00:06 +0200
- Subject: Re: Suggestion for a new GNATS policy
- References: <D18A2D28-8414-11D7-8EDF-000A95A34564@dberlin.org>
Daniel Berlin <dberlin@dberlin.org> wrote:
>> "analyzed" should mean that at least the category is set and
>> that a reduced test case is available.
> Why?
> you can mark them with a keyword or bug status flags.
> Stop overloading bug states for this functionality.
> Geez.
No, in my opiniton it's totally the contrary. "Confirmed" should be just a
flag. I don't care if a bug is confirmed or not: confirming is a no-brain
action: it means I downloaded the PR, run GCC on it, and verified the bug.
To push it, it could even be automated for c++/c/middle-end/optimization
bugs (especially ICEs). I don't think anybody really cares if it's been
confirmed that a 300K file ICEs the compiler: the real problem is an
effective analysys of the bug, which means testcase reduction, code forming
check, and such.
This is what it's really important. I don't really mind about the name, but
if Bugzilla doesn't have "analyzed" but only "uncorfimed" and "new", we
should use "new" as analyzed.
Otherwise, please explain us what is a state and what is a flag. Usually, a
bug which is not properly analyzed will not be considered for bugfixing, so
this is where the stress should go. I call this a bug state. Confirmation is
not necessary a state (it's mostly useless), so I'm ok with it being just a
flag.
Giovanni Bajo