Re: What's gcc-prs for?!?

[Richard Earnshaw <rearnsha at arm dot com>]

> Richard Earnshaw wrote:
> 
> > I *thought* it had been agreed in the last time we went round this
> > discussion loop that gcc-prs is where all the bugzilla dribblings
> > would be forwarded, leaving gcc-bugs for just new reports.
> 
> To what effect? It looks like many new reports are invalid and closed in a
> shot.
> 
To the effect that I would have time to look at the new reports in 
sufficient detail to decide whether they are really worth pursuing.  As 
things stand I take one look at a folder containing 80 odd messages (most 
of which are dross) and my eyes glaze over.  I don't need to know that a 
bug has had a new attachment, I don't need to know that someone else has 
reproduced the problem -- if I need that I can open the full report -- I 
don't even need to know if it's been closed.

> > Anyway, I find gcc-bugs impossible to track these days -- there's
> > just too much noise on it.
> 
> We asked many times on inputs about this. Would you please provide some
> examples of messages that you think are just noise and could be filtered away
> from gcc-bugs?

Go and look at the previous discussion on this topic.  My view hasn't 
changed since then.  As things stand gcc-bugs is pretty much useless to me 
-- I'm even considering unsubscribing.  And if I do that the only bugs 
I'll ever see are the ones that match my bugzilla filters -- and even 
those I'll only look at once in a while.

As an example of why this would be a loss, take a look at PR 14040.  This 
was closed by Mark because he couldn't reproduce it (and I'd missed the 
original message in the noise).  But it turned out that he hadn't 
appreciated that the arm-linux configuration behaves in a slightly 
different manner to arm-elf, so it was necessary to add an extra 
command-line option to provoke the failing conditions.  If I'd seen the 
original report I'd have been able to address this much more promptly.

R.