Re: NEW vs. UNCONFIRMED

[Wolfgang Bangerth <bangerth at ices dot utexas dot edu>]

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