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

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

[Wolfgang Bangerth]

The following reply was made to PR c/7654; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Subject: Subjective opinion about PRs (Was: Re: c/7654: -Wenum-assignment :
 Warn if an enum is being assigned a non enum value)
Date: Fri, 3 Jan 2003 17:06:35 -0600 (CST)

 On Thu, 2 Jan 2003, Andrew Cagney wrote:
 
 > > Synopsis: -Wenum-assignment : Warn if an enum is being assigned a non enum value
 > > 
 > > State-Changed-From-To: open->closed
 > > State-Changed-By: bangerth
 > > State-Changed-Why:
 > >     I think your proposal is not very much in the spirit of the
 > >     C language, and I doubt that anyone will want to implement
 > >     it. enums are too much used interchangably with integers
 > >     that such an enum would be useful. Note that enums also
 > >     appear all over the place in system header files!
 > 
 > The above is largely subjective opinion. 
 
 True.
 
 > Subjective opinion is not a 
 > reason for closing an enhancement request.
 
 I'll reopen the report in a minute, but let me give a brief rationale why 
 I closed this in the first place:
 - Given what I assume (indeed a very vague proof) is the opinion of the
   collective of gcc developers, based on the many mails I have read, the
   requested warning will not be implemented since it will not be useful
   except for a very small number of cases (for example, including an
   arbitrary C header file will most likely trigger many messages from this
   warning)
 - 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.
 
   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.
 
 As I said, I'm happy to reopen the report. However, for cases like these, 
 we should have some policy. Since you say that subjective opinion should 
 not be a reason, and objective opinion is not possible (no standard is 
 violated, etc), I see only two possibilities:
 - do a poll what people think about it; experience tells that nobody will
   answer to such requests
 - use common sense; that's what I tried, but that may lead to false 
   decisions.
 
 What do you propose to do with such reports?
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

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

[Wolfgang Bangerth]

The following reply was made to PR c/7654; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Subject: Re: Subjective opinion about PRs (Was: Re: c/7654: -Wenum-assignment
 : Warn if an enum is being assigned a non enum value)
Date: Fri, 3 Jan 2003 19:34:58 -0600 (CST)

 On Fri, 3 Jan 2003, Andrew Cagney wrote:
 
 > 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). 
 
 I just did it. My original way of setting the priority was somewhat more 
 drastic (closing it). I'll use the priority fields more in the future.
 
 
 > > - 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.
 
 My view of things is that the database was more used as a "bug filing 
 system", rather than a bug _tracking_ system. We need to be better a 
 bringing the truly important reports to the attention to those who have 
 the knowledge to fix them.
 
 > 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.
 
 Right. Another argument to finally switch to Bugzilla.
 
 >  Would you be so concerned if all 1000 open bugs were against Ada? :-)
 
 :-) I'm a C++ hacker. I don't think I have ever touched an Ada report...
 
 
 Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

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

[Andrew Cagney]

The following reply was made to PR c/7654; it has been noted by GNATS.

From: Andrew Cagney <ac131313@redhat.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: Subjective opinion about PRs (Was: Re: c/7654: -Wenum-assignment
 : Warn if an enum is being assigned a non enum value)
Date: Fri, 03 Jan 2003 18:40:43 -0500

 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