Re: x86 fpu

[jtc at redback dot com (J.T. Conklin)]

>>>>> "H.J." == H J Lu <hjl@lucon.org> writes:
>> I believe that H.J.'s private versions of the GNU toolchain have been
>> a great disservice to both the GNU/Linux and the larger GNU community.

H.J.> I certainly don't agree :-). It is a pain for me to maintain my
H.J.> private versions. But I hate to see the Linux people nowhere to
H.J.> go for help. Do you really honestly believe that a new official
H.J.> version should be made whenever a serious Linux related bug is
H.J.> fixed or we have to live with the bug which mainly affects Linux?

No, I don't think that there needs to be a new official version when a
serious bug is fixed; nor do I think that Linux users should live with
bugs (Linux specific or not) until the next official release.

I do think development snapshots could be made to serve the purpose of
your private versions, or in the very worst case your private versions
could would contain minimal changes over the most recent snapshot.

I believe this because in my experience it is extremely quick and easy
get a well written patch to fix a bug into GDB, or any other toolchain
component.  While not instantaneous, the week or two between the time
a patch is submitted and the time it shows up in a snapshot is usually
not unacceptable.  In those rare cases, I check the patch into our
production repository at the same time I submit the patch; with full
knowledge that I'll be responsible for tracking that divergence until
the bug is fixed in the repository.

It takes longer for contributions from people who do not have active
copyright assignments, new features, or poorly written or thought out
patches; but not enough to justify a splinter branch.  If there is a
problem causing significant delays, that is a problem that needs to be
fixed.

When I came to RedBack, it took about a week after I had mailed my new
copyright assignments to the FSF before the FSF secretary had e-mailed
notification of the assignment to the mailing lists.  If there is a
delay processing these forms, complain to RMS.

I know that there were problems getting Linux thread support into the
main sources.  I can only assume that some aspects of the changes made
them not acceptable "as-is", but I don't know the details.  I believe
what should have happened is the changes should have been reviewed
promptly; the contributor told what modifications were required to be
made before the patch can be accepted; the contributor making those
changes; perhaps a few iterations of that and the the patch integrated
into the official sources.

I don't know where the process broke down, but by the time I became
aware of it, it appeared to me that one side believed that the code
was not ready, the other that the other was being obstinate and not
integrating code, and that nothing was being done to reconcile the
problem because the splinter version was available.  

There have been messages from many Linux users that appreciate your
version.  But nothing will convince me otherwise that both GDB as a
whole and GDB on Linux would have been better off had there not been 
a splinter version.

If you think the process is still broken, complain to Stan.

        --jtc

-- 
J.T. Conklin
RedBack Networks