Re: GCC 3.0 Release Criteria

[Jeffrey A Law <law at cygnus dot com>]

  In message <200005030639.CAA00481@lop-nor.ihack.net>you write:
  > 
  > I used to make the (apparently incorrect) assumption that submitting a
  > bug report with a fix to gcc-bugs was sufficient.
Not if you're submitting a patch.  That's why we have a patch list!

Speaking strictly for myself, I don't have time to fix bugs anymore, instead
I spend most of my GCC volunteer time trying to resolve patches that
have fallen through the cracks.  WHere do you think I get those patches?  Yes,
from the gcc-patches mailing list.  I don't have time to wander the bugs
list in hopes of finding a couple patches.

  > But I also note that even things sent to gcc-patches usually entail a
  > rather long delay, sometimes even with no acknowledgement at all.
Every patch should be acked in some form or another, sometimes that doesn't
happen, but I believe the vast majority of patches submitted to gcc are
acked.  Yes it can take a while, but if you look at the volume of the
gcc-patches list and realize that people are *volunteering* their time, maybe
you'll understand why.

If you have specific patches that were not acked in some form, please let us
know which ones so that we can investigate what happened and take appropriate
actions to correct it.

Constructive criticism of the project is welcomed and we will do what we
can to address your problem, but it takes some work on your part to help
us investigate the problem.  If you don't feel it's worth your time to help
us investigate the problem, then it is unlikely to be investigated.

  > I forget which patches *specifically*, but I know for a fact that
  > there were several known and well-tested patches that were important
  > to NetBSD that did not go in 1.1.2 because it was specifically slated
  > to support Linux. 
Err, no.  egcs-1.1.2 was a bugfix release to egcs-1.1.1, in no way was it
specifically slated to support Linux.  If you don't know something for a
fact, do not state it as a fact, especially on a public list.  Doing so
makes you look like a fool and ironically, when you look like a fool, your
patches are less likely to be reviewed in a timely manner.

  > patches in our own tree).  I'm almost certain that I brought up a few
  > of these on the list, but I don't have time to go search the archives
  > to find it.
Again, if you think you've been mis-treated in some way, my recommendation is
for you to get a list of patches that were not adequately addressed that we
can use to investigate what is happening.


jeff