Re: Subjective opinion about PRs (Was: Re: c/7654: -Wenum-assignment: Warn if an enum is being assigned a non enum value)

[Andrew Cagney <ac131313 at redhat dot com>]

You've already identified this as low priority.  Just set the priority 
to low (and category to change-request) (I thought I'd done this).  If 
I, or someone else, ever finds the time, we can fix it (although, for my 
part I'd be fixing -Wswitch-fallthrough first)

> - We can leave this report open, but then we end up with _lots_ of such
>   requests that clutter up the data base. I have repeatedly stressed that
>   the number of open reports is so large that nobody seems to care about
>   individual reports anymore (well, this is not exactly true, but it is a
>   fact that until very recently, more than 1000 reports have not even been
>   looked at). If we don't filter the database such that the feature
>   requests that remain in it are few and "useful" (whatever that may be), 
>   then nobody will look at it.
This is normal.  It is how people use bug tracking systems.  Everything 
goes in and is then given a priority.  Only by doing that is it possible 
to see what needs/can be done.

If anything you may want to review the list of GCC bug categories - 
better categorizing bug reports should make it possible for developers 
to better identify which bugs they need to work on.  Would you be so 
concerned if all 1000 open bugs were against Ada? :-)

>   The report in question seemed to me of the type "if left in, it will 
>   remain in this state indefinitely since nobody seems this worth 
>   implementing". I consider these worse than closed reports, since they
>   make working on the database more complicated than if we moved them out
>   of the way of "useful" reports.
You should exclude low priority PR when preparing status reports.  That 
will make your numbers look much better!

Andrew