Re: GCC 3.0 Release Criteria

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

    Gerald> On Sat, 29 Apr 2000, Mark Mitchell wrote:
    >> I think I would prefer to see FreeBSD as a "second-tier"
    >> platform.  I've added a section to the criteria document, and
    >> will add it there.

    Gerald> Hmm, I don't think that's completely fair:

Here's the problem.  

If we have lots of first-tier platforms, we will face additional
burdens.  All of the tests must work on all of the first tier
platforms.  That will require considerable effort -- not just to fix
bugs in the compiler but also to make sure that the test applications
work on these systems.

When I prepared the list, I thought pretty hard about this.  I know of
probably ten or so major platforms not represented on the list.
Windows NT, Unixware, OpenServer, flavors of BSD, and other flavors of
Linux lead the list, but there are other platforms (like NCR MP-RAS,
for example) that are still pretty actively in use.

I worked hard to get the major chips, and the major OS's on the list.
The reason, for example, for picking IRIX 6.5 is that it is pretty
widely used, GCC works pretty well there already, and, most
importantly, it's a good MIPS testbed.  MIPS chips are widely used in
embedded systems, but it's harder to test there; we test many aspects
of MIPS code-generation on IRIX.

I think support for commercial operating systems is important in GCC;
that is part of the way in which users of those systems become exposed
to free software.  For example, I was first introduced to free
software via the use of GNU Emacs and GCC on Ultrix systems.

The original list did not contain Intel x86 Debian GNU/Linux, but this
platform was suggested strongly because it is, as I understand it, the
official GNU distribution.  RedHat Linux appears twice because I
believe it to be the most widely used distribution of Linux; that
means that failing to work correctly there will affect a lot of
people, that a lot of people can provide testing cycles, and that a
lot of people are incentivized to help fix bugs.

Since the list has gone up, a number of people have posted messages
essentially of the form "But what about target X?  I am willing to
help out with target X."  

I very much appreciate that excellent volunteer spirit.  However, that
volunteerism comes with certain costs:

  - A risk that the volunteer will be unwilling or unable to
    follow-through.  I mean no disrespect to any volunteer; this is
    as true for myself in my capacity as volunteer as it is for anyone
    else.  Sometimes I am too busy, sometimes too lazy, and sometimes
    too incompetent to finish tasks I have set myself.

  - A risk that the volunteer will be able to find bugs, but not fix
    them.  If we have committed to supporting this platform as
    a primary platform, we are committed to fixing the problems.  (See
    below.)

  - A risk that fixing a bug on X will introduce bugs on another
    platform.  Many fixes will require retesting all the other
    platforms.  Some fixes may be confined to target-specific files;
    others may require changes to machine-independent code.

Please bear in mind the following, which I have not had good success
at conveying:

  - The release criteria are *minimum* criteria.  To the extent it
    is up to me, I will not allow GCC 3.0 to go out the door until
    those criteria have been met.

    (That is a contract with the community.  The price the community
    pays is that some "secondary" platforms may not meet
    all of testing criteria.  The benefits the community receives
    is that a) they have strong quality assurances on the primary
    platforms and b) they have a better chance of getting GCC 3.0 
    in the relatively near future.

    The price the developers pay is that we must stick to a particular
    set of guidelines.  The benefit we receive is that we will have
    a relatively clear idea of when we are done, and that we will
    have a better chance of getting our work into the hands of users
    in the relatively near future.)

  - However, again to the extent it is up to me, I can imagine
    a number of other scenarios that would require holding up the
    release.

    For example, if all of the Fortran tests failed for a secondary
    platform, I would likely consider that such a problem.  However,
    if one C++ test, involving a seldom used feature, failed on a
    secondary platform, even though it worked in a previous release,
    and the only reasonable fix was unduly risky, then I might well
    decide that, in my opinion, we should ship the release anyhow.

Thus, at this point, I stand by the current list.  (I think there
should be more secondary platforms, though!)  The SC can, of course,
decide otherwise.  And, I'm willing to be persuaded.  But, I think
that keeping the list of primary platforms relatively short is
essential to making the release a success.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com