NEW vs. UNCONFIRMED

[Dara Hazeghi]

--- 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...