This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: NEW vs. UNCONFIRMED
- From: Dara Hazeghi <dhazeghi at yahoo dot com>
- To: gcc-bugs at gcc dot gnu dot org
- Cc: bangerth at ices dot utexas dot edu
- Date: Sat, 31 May 2003 21:20:52 -0700
- Subject: Re: NEW vs. UNCONFIRMED
--- Wolfgang Bangerth <bangerth@ices.utexas.edu> wrote:
> I think I left out something: I wouldn't have closed the report if I
> didn't get feedback, or if it wasn't sufficient. I would just have
left
> the PR open.
Yes, that makes more sense. I think the general policy should be that
bugs get closed only when there's good evidence that they've been
fixed, and lack of feedback, save under very special circumstances,
doesn't fall in that category (the special circumstances being for
example, that a patch for the particular problem was installed, but
nobody has he configuration in question, and no feedback is obtainable
from anybody who does).
>
> We're presently having a problem with PRs in WAITING: you guys have
been
> putting lots of PRs into WAITING, for which I have the feeling that
> there's already enough info in the PR. We shouldn't be closing these
> reports if we don't get feedback in 3 months. We
> should review each of them again then.
I agree that we shouldn't close bugs willy-nilly. But I think the vast
majority of bugs in feedback really should be in feedback. Looking at
the two biggest categories in feedback, we've got bootstrap and target,
and both of those are the type which generally require a fair bit of
information...
> That sound reasonable for bugs on obscure targets.
Good.
> For example? For C/C++/Optimization, we do not put PRs into NEW just
> because it "looks like this could indeed happen". I would be very much
> opposed if we would adopt this as sufficient.
No, but what I mean is that C/C++ bugs are _generally_ reproducible
across targets, meaning you don't need a specific machine to test them
(usually). I certainly hope I haven't been marking bugs as NEW for
those reasons :-)
> Basically:
> Wolfgang x86-linux only
> Volker same
> Christian sparc
> Giovanni windows stuff
> Falk alpha (and some more)
> Dara seems like everything else :-)
Not quite. Right now I have access to PowerPC/Darwin, x86/Linux,
Sparc/Solaris. Hopefully this summer: HPPA/HPUX, IA64/HPUX, and
IA64/Linux.
Looks like the main missing ones are MIPS/IRIX, Alpha/Tru64 and the
small embedded ones (SH, Arm, etc.).
>
> > Another question I have is about including the platform of a bug in
the
> > summary (ie "[powerpc64] blah fails doing foo". Now that Daniel has
> > made it possible to edit the host and target fields (thanks
again!), it
> > seems to me that we should be using those, rather than the bug
summary,
>
> I'm not yet won over -- PR submitters will fill in these fields for
front
> end bugs as well, and then searching will become more difficult again.
> Also, what if a bug exists on multiple targets?
Good point. I concede that in this case the information is useful. I
withdraw that suggestion.
> I do it with a few people who I know are usually responsive to my
> requests. Otherwise only if I contacted them on- or off-list. I
consider
> it as impolite just assigning a bug to someone without asking
beforehand.
>
> I think this is a question for the maintainers to answer.
Right. I guess that pretty much answers all my questions. Now back to
finding out what's going on with Ada on Darwin...
Dara
P.S. Could somebody take a look at 10922 sometime? I definitely should
have taken a C++ course earlier this year, but until then...
P.P.S. Also, my message to the list about cygwin doesn't seem to have
gotten any response. My question was basically: is building with MS
VC++ supported (IMHO no), and if not, should we document this in the
target specific installation instructions.