public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* Re: NEW vs. UNCONFIRMED
@ 2003-06-01 4:21 Dara Hazeghi
2003-06-02 15:53 ` Wolfgang Bangerth
0 siblings, 1 reply; 9+ messages in thread
From: Dara Hazeghi @ 2003-06-01 4:21 UTC (permalink / raw)
To: gcc-bugs; +Cc: bangerth
--- 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NEW vs. UNCONFIRMED
2003-06-01 4:21 NEW vs. UNCONFIRMED Dara Hazeghi
@ 2003-06-02 15:53 ` Wolfgang Bangerth
0 siblings, 0 replies; 9+ messages in thread
From: Wolfgang Bangerth @ 2003-06-02 15:53 UTC (permalink / raw)
To: Dara Hazeghi; +Cc: gcc-bugs
> 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,
Certainly. Use common sense.
> 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
Not quite. We've got a number of PRs for windows specific things. But in
general true.
> > 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.
That _is_ almost everything else :-)
> Looks like the main missing ones are MIPS/IRIX, Alpha/Tru64 and the
> small embedded ones (SH, Arm, etc.).
I've got an old mips/irix machine, but it took 3 days to bootstrap 3.2.3,
and 3.3 didn't build at all...
> P.S. Could somebody take a look at 10922 sometime? I definitely should
> have taken a C++ course earlier this year, but until then...
We're already pretty well staffed in the C++ area. You're doing great in
others. So why generate overlap :-)
Can you send me preprocessed sources for the 3.4 failure, and how that one
line originally looked like?
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NEW vs. UNCONFIRMED
2003-06-01 1:01 Dara Hazeghi
@ 2003-06-02 7:32 ` Ben Elliston
0 siblings, 0 replies; 9+ messages in thread
From: Ben Elliston @ 2003-06-02 7:32 UTC (permalink / raw)
To: gcc-bugs
Dara Hazeghi <dhazeghi@yahoo.com> writes:
> I guess I agree with you in principle, I just feel you standards are
> a bit too stringent. Especially for runtime bugs, I'm not certain
> whether it's necessarily fair to ask the submitter to try multiple
> compiler versions, particularly if the failing one is the current
> release. I think I find Joseph's proposal perhaps more practical:
There is obviously a happy medium that divides the responsibilities of
bug reporters/users and the body of GCC volunteers. I know for a fact
(having done it before) that there is a lot of bug verification and
cleaning work to be done to keep the bug tracking database in a useful
state. If we asked more of our bug reporters, we would have a lot
less of that kind of work to do and it's probably safe to say that it
scales better with increased numbers of bug reports.
However, there comes a point at which a bug reporter reads the bug
reporting guidelines, decides "I don't know how to do that" or "I
don't have enough time for this" and don't submit their bug report at
all. I think that's a _worse_ situation than having a bug report that
needs more first-line analysis.
Cheers, Ben
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NEW vs. UNCONFIRMED
@ 2003-06-01 4:25 Dara Hazeghi
0 siblings, 0 replies; 9+ messages in thread
From: Dara Hazeghi @ 2003-06-01 4:25 UTC (permalink / raw)
To: timothyprince; +Cc: gcc-bugs
[-- Attachment #1: Type: text/plain, Size: 480 bytes --]
> I've been put on the CC: list for all bugs, according to the
> bugzilla messages. If this happened for many people, no wonder your
> server gets behind.
Really? When Daniel migrated us to bugzilla, everybody in the audit
trail of a bug got added to the CC: list for that bug, and that
certainly has increased traffic, but I hope you're not on the CC: list
for every PR! Note that you can change your bugzilla preferences to
block such mailings even if you are...
Dara
[-- Attachment #2: Type: text/enriched, Size: 540 bytes --]
<fontfamily><param>Courier</param><bigger>> I've been put on the CC:
list for all bugs, according to the
> bugzilla messages. If this happened for many people, no wonder your
> server gets behind.
Really? When Daniel migrated us to bugzilla, everybody in the audit
trail of a bug got added to the CC: list for that bug, and that
certainly has increased traffic, but I hope you're not on the CC: list
for every PR! Note that you can change your bugzilla preferences to
block such mailings even if you are...
Dara</bigger></fontfamily>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NEW vs. UNCONFIRMED
2003-06-01 1:15 ` Wolfgang Bangerth
2003-06-01 1:32 ` Andrew Pinski
@ 2003-06-01 3:56 ` Tim Prince
1 sibling, 0 replies; 9+ messages in thread
From: Tim Prince @ 2003-06-01 3:56 UTC (permalink / raw)
To: Wolfgang Bangerth, Dara Hazeghi; +Cc: gcc-bugs
On Saturday 31 May 2003 18:15, Wolfgang Bangerth wrote:
> > Finally, a question about maintainers and bugs. Is there a consensus as
> > to when it is okay to assign a bug to someone, and when it is okay to
> > add someone (who's responsible for the relevant portion of the
> > compiler) to the cc: list of a bug? Thanks,
>
I've been put on the CC: list for all bugs, according to the bugzilla
messages. If this happened for many people, no wonder your server gets
behind.
--
Tim Prince
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NEW vs. UNCONFIRMED
2003-06-01 1:32 ` Andrew Pinski
@ 2003-06-01 1:38 ` Wolfgang Bangerth
0 siblings, 0 replies; 9+ messages in thread
From: Wolfgang Bangerth @ 2003-06-01 1:38 UTC (permalink / raw)
To: Andrew Pinski; +Cc: Dara Hazeghi, jsm28, Giovanni Bajo, gcc-bugs
> You forgot me:
> Andrew x86-linux, x86-openbsd, ppc-darwin and soon ppc-linux.
I didn't forget you, I just didn't know exactly ;-)
Sorry for that
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NEW vs. UNCONFIRMED
2003-06-01 1:15 ` Wolfgang Bangerth
@ 2003-06-01 1:32 ` Andrew Pinski
2003-06-01 1:38 ` Wolfgang Bangerth
2003-06-01 3:56 ` Tim Prince
1 sibling, 1 reply; 9+ messages in thread
From: Andrew Pinski @ 2003-06-01 1:32 UTC (permalink / raw)
To: Wolfgang Bangerth
Cc: Andrew Pinski, Dara Hazeghi, jsm28, Giovanni Bajo, gcc-bugs
On Saturday, May 31, 2003, at 21:15 US/Eastern, Wolfgang Bangerth wrote:
>> Perhaps then we should set up a list of platforms,
>
> Basically:
> Wolfgang x86-linux only
> Volker same
> Christian sparc
> Giovanni windows stuff
> Falk alpha (and some more)
> Dara seems like everything else :-)
You forgot me:
Andrew x86-linux, x86-openbsd, ppc-darwin and soon ppc-linux.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NEW vs. UNCONFIRMED
[not found] <486DCCCA-93CC-11D7-A14F-000393681B36@yahoo.com>
@ 2003-06-01 1:15 ` Wolfgang Bangerth
2003-06-01 1:32 ` Andrew Pinski
2003-06-01 3:56 ` Tim Prince
0 siblings, 2 replies; 9+ messages in thread
From: Wolfgang Bangerth @ 2003-06-01 1:15 UTC (permalink / raw)
To: Dara Hazeghi; +Cc: jsm28, Giovanni Bajo, gcc-bugs
> I guess I agree with you in principle, I just feel you standards are a
> bit too stringent. Especially for runtime bugs, I'm not certain whether
> it's necessarily fair to ask the submitter to try multiple compiler
> versions, particularly if the failing one is the current release.
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.
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.
> > You should alse make sure that the bug report seems to contain sufficient
> > information for anyone with the right platform to reproduce it (all
> > required sources, compiler options, what is considered to be wrong, ...).
> > Given that information is present, and that what is described as being
> > wrong does indeed look like a bug, I think treating the bug as confirmed on the given
> > version and platform is reasonable.
That sound reasonable for bugs on obscure targets.
> I think something along these lines will provide the necessary
> information, without asking too much of the reporter... Especially
> since for other types bugs, we tend to have a somewhat lower threshold.
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.
> Perhaps then we should set up a list of platforms,
Basically:
Wolfgang x86-linux only
Volker same
Christian sparc
Giovanni windows stuff
Falk alpha (and some more)
Dara seems like everything else :-)
> and people who are
> willing to test code on them? As it is, usually I just end up asking
> whoever seems most likely to have such systems, but I'd be reasonably
> confident that among all the "bugs people" and the regular developers
> we cover most of the platforms. Thoughts?
Well, MAINTAINERS lists who's responsible for a platform. If we can't find
someone with a platform, this would be the person to ask. Except, that
this doesn't seem to work most of the time -- responsible seems to be a
more flexible word than I thought.
> 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?
> Finally, a question about maintainers and bugs. Is there a consensus as
> to when it is okay to assign a bug to someone, and when it is okay to
> add someone (who's responsible for the relevant portion of the
> compiler) to the cc: list of a bug? Thanks,
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.
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: NEW vs. UNCONFIRMED
@ 2003-06-01 1:01 Dara Hazeghi
2003-06-02 7:32 ` Ben Elliston
0 siblings, 1 reply; 9+ messages in thread
From: Dara Hazeghi @ 2003-06-01 1:01 UTC (permalink / raw)
To: gcc-bugs
--- Wolfgang Bangerth <bangerth@ices.utexas.edu> wrote:
>>? One example I'm wondering about is 10403 (Java on mingw32
> > runtime bug). Thanks,
>
> I think whenever I came across something like that, I put the state to
> confirmed(=new) when the original submitter could reproduce the same
> problem again with a different version of gcc on his system, AND if
this
> was a system of which I suspected that there is none of us bugs people
> working with. Ideally, we'd just leave these reports as they are and
leave
> it to the platform maintainers to confirm. However, since this is not
> happening, I thought it would be more useful to flush out a couple of
> reports that were wrong, put some justifiably into confirmed, and a
few
> into confirmed though it was really a user error.
I guess I agree with you in principle, I just feel you standards are a
bit too stringent. Especially for runtime bugs, I'm not certain whether
it's necessarily fair to ask the submitter to try multiple compiler
versions, particularly if the failing one is the current release. I
think I find Joseph's proposal perhaps more practical:
> You should alse make sure that the bug report seems to contain
sufficient
> information for anyone with the right platform to reproduce it (all
> required sources, compiler options, what is considered to be wrong,
...).
> Given that information is present, and that what is described as being
> wrong does indeed look like a bug, I think treating the bug as
confirmed on the given
> version and platform is reasonable.
I think something along these lines will provide the necessary
information, without asking too much of the reporter... Especially
since for other types bugs, we tend to have a somewhat lower threshold.
>
> Things have changed a little since we're now so many more people
working
> on bugzilla, and have a variety of platforms. For example Giovanni
may be
> able to reproduce this bug on his windows box.
Perhaps then we should set up a list of platforms, and people who are
willing to test code on them? As it is, usually I just end up asking
whoever seems most likely to have such systems, but I'd be reasonably
confident that among all the "bugs people" and the regular developers
we cover most of the platforms. Thoughts?
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,
to include the specific platform on which the bug occurred. Also, since
target triplets have a canonical form, this will root out a number of
minor inconsistencies (ie ppc vs powerpc), and make it much easier to
search for specific problems. Any opinions about this? I generally lean
toward the philosophy of one field, one purpose...
Finally, a question about maintainers and bugs. Is there a consensus as
to when it is okay to assign a bug to someone, and when it is okay to
add someone (who's responsible for the relevant portion of the
compiler) to the cc: list of a bug? Thanks,
Dara
P.S. Apologies for sending a copy of this message to everyone without a
title. Too much cutting and pasting...
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-06-02 15:53 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-01 4:21 NEW vs. UNCONFIRMED Dara Hazeghi
2003-06-02 15:53 ` Wolfgang Bangerth
-- strict thread matches above, loose matches on Subject: below --
2003-06-01 4:25 Dara Hazeghi
[not found] <486DCCCA-93CC-11D7-A14F-000393681B36@yahoo.com>
2003-06-01 1:15 ` Wolfgang Bangerth
2003-06-01 1:32 ` Andrew Pinski
2003-06-01 1:38 ` Wolfgang Bangerth
2003-06-01 3:56 ` Tim Prince
2003-06-01 1:01 Dara Hazeghi
2003-06-02 7:32 ` Ben Elliston
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).