Re: Linux vs. libio

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    Jeffrey> Not a bad idea.  On a branch would be fine by me.  We
    Jeffrey> have used that scheme for similar purposes in the past.

If that's what the steering committee, or whoever decides this kind of
thing, wants to do, then that's what we'll do.

But, I think it's really not a good idea.

In practice, this will lead to a lot less testing.

Doing the new ABI work has already spotted bugs in the compiler, and
requires various other cleanups.  We'll lose those advantages in the
mainline, and there will be semi-serious divergence.

We (CodeSourcery) might not have the resources to do the merge which
might mean the community may be unable to profit from the new ABI
until someone volunteers to do it.  Think how long the GC work done on
the branch by Bernd and Richard might have languished had we not
stepped in to integrate it.  This work needs to be done and in
official GCC before IA64 Linux systems go into any kind of serious
use, or there are going to be major headaches down the road -- the
same kind of libc5/libc6 thing will happen all over again.

I think that's perhaps what is still not being understood is:

  o We're not going to break IA32 Linux.

  o We're not going to do stuff willy-nilly without asking the libio
    folks for approval.

  o The only possible breakage will be for -fnew-abi programs,
    which are already not supported -- the new ABI is clearly marked
    as experimental, not for production use, may change, etc.

Branches make sense where there is real risk, or where completion is
uncertain.  For example, the new IA32 back-end branch was an excellent
use of a branch -- had the work been done on the mainline, it probably
would have taken a long time before anything could have been checked
in.  Lots of people would have lost time debugging problems in the new
back-end.  Instead, Richard worked on a branch, interested parties
helped, and finally the result was merged, with minimal impact (except
that our programs run faster now!).  But, the new ABI doesn't affect
anybody -- you only get it if you use -fnew-abi!

What's happenning here is that we're doing open development.

We could keep all our changes locally, give them just to our
customers, prevent the net from helping with the testing and
development load, and prevent people from reaping the benefits of the
new ABI.  Doing them on a branch has many of those same disadvantages.

Up until now we've *never* done any GCC development anywhere but n the
100% open light of day.  We've checked things into GCC when they were
tested and working, and we've fixed problems that arose as quickly as
possible.  We haven't even waited for our customers to pay us for the
work.  We've checked in things as we did the work, allowing everyone
to comment, criticize, test, and improve our efforts.  I'd like to
continue that policy -- I think that's the spirit of open source
development.

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