Re: GCC 3.0 Release Criteria

[Mike Stump <mrs at windriver dot com>]

[ disclaimer, these are my opinions, and other people won't
  necessarily share them, I don't speak for others, even though it
  seems like I might try   :-) ]

> Date: Wed, 3 May 2000 00:59:21 -0400 (EDT)
> From: "Charles M. Hannum" <root@ihack.net>
> To: gcc@gcc.gnu.org

Your views are very unfortunate.  They in part happen out of
misunderstanding and miscommunications.  gcc has always works a
certain way, and basically, will always work a certain way, these I
call the facts of life.  The fact is, there are people that donate
linux work and linux testing.  The fact is, they have been doing it so
long for whatever reason that motivates them, that _we_ can count on
them to continue the work.  That knowledge of the situation lets us
make a claim that linux will be supported and work in the next major
release.  This is the part that is invisible to people that may seem
mysterious.  But literally, that is about all it is.  People willing
to donate.  They have their reasons for their donation, that they have
to be free to control and decide upon.  The only thing the FSF can do,
is accept it, if it _is_ a worthwhile donation, or place additional
requirements on the donation before acceptance.  The canonical example
of an additional require would be that no other port be regressed,
either in functionality or performance.  While the FSF could try and
mandate that a person that fixes a linux problem, must also fix an
FreeBSD problem, would that be fair?

The other component, which is a real, is that a release of gcc that
doesn't work on systems where we have major installed bases, hurts gcc
reputation more than a release that doesn't work on a minor platfrom.
It is best for gcc, if we don't release until those problems are
fixed.  This is one slant on the minimum requirements.  I understand
this does cause some type of favoritism towards those targets, but
this isn't actually all bad.  What we get, is a better reputation.
This reputation is tradable for additional work on gcc.  This
additional work benefits more than just the few most popular
platforms.  It is for this additional benefit that we try and maintain
and enhance gcc reputation.  For example, you'll notice that gcc is
way better on the x86, you got this improvement, in part because of
Linux.


Often discussions, other issues, bugfixing swamp people that review
and accept patches.  Always has, always will, I know exactly how
frustrating it can be, more than most I would say.  Sometimes patches
are not clear and that causes them to fall by the wayside, however the
person reviewing it may not even tell you they are not clear.
Likewise for patches that contain more than one patch in them.
Likewise for patches that don't fit the model of gcc well.  Likewise
for patches that are just wrong.  In short quite a few things can
cause patches to not get it, but, keep trying, keep learning, keep
refining them and keep submitting them.

> the NetBSD project has been forced to maintain our own GCC branch,
> because no release of the compiler has ever worked well enough on
> all the platforms we support.

That's unfortunate.  Only the donation of work to make gcc work well
can cure it.  I'd would be nice if that work were donated and
integrated in before release.  I'd recommend soliciting people to help
work on the issue, and keep trying to make process against it.  I'd
put the tag line `this bug cases gcc to not support FreeBSD, this fix
cures that bug, without it, FreeBSD cannot work' on all such patch
submission to try and raise awareness of the issue.

> no NetBSD platforms are considered `interesting' enough to even rate
> on the `second tier' list.

See my other email.  You can sign up for the donation and the
responsibility, if you want.

> This suggests to me that no matter how much we contribute in good
> faith, that the GCC steering committee is interested only in

Actually, the GCC steering committee doesn't review or accept patches.
This isn't their role.  They don't even control what gets donated.
They can hardly even control where gcc may wonder.  There is more
power in controlling that, if you're willing to role up your sleeves
and do work.  Mark I am sure in part got the job, not because he waves
a linux flag (which I don't think he does), but because all the hard
work he has put into gcc.  This allowed him to put in some very risky
code, like GC, which would have been impossible for most contributors.

> where it perceives the money to be.

?  They don't see any money from the donation of their time and effort
to gcc.  The whores (I mean that in a nice way) are the companies and
people that contract work on gcc for hire.  These entities you might
rightful accuse of following the money.  I think it is unfair to say
this of the steering committee.  In fact, their job, is to not let the
people following the money, do things that are bad for gcc.


Anyway, sorry to hear you're not getting enough out of the process.
:-(