This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: x86 fpu


>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> HJ, what else will have to happen with GDB before you will
Mark> consider dropping your special Linux GDB based on 4.17?  IMHO we
Mark> should make sure that the Linux community starts doing their GDB
Mark> development based on the current CVS version as soom as
Mark> possible.

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.

Whatever short term advantage may be gained by having private versions
is far outweighed by the long term consequences.  All the consequences
may not even be evident to the person or organization that created the
splinter branch.

* Users are not adequately informed that they are using a splinter
  version, and send bug reports, requests for help, etc. to people
  who are unable to help them.

* Users cannot use the most current software when it is released, but
  must wait until it is incorporated into the splinter version.

* Users of the official version of the software do not benefit from
  the enhancements found only in the splinter version.

* Pontential contributors cannot track the development snapshots,
  because support for their (host and/or target) system requires
  changes from the splinter version.

* Less time is available for improving the software because more time
  is necessary for managing divergence.  This is difficult enough when
  all of the changes have been written by one person, or from one org-
  anization, but the recordkeeping burden is even greater when changes
  from many unrelated people (since copyright assignments are required
  for any substantial changes).

  When divergence is carefully managed, it is relatively "easy" to
  isolate individual changes to submit patches.

  The problem is that this feeds on itself.  If there is no time to
  submit changes, refining them when required, etc.; the divergence
  grows and it becomes even more difficult.  Eventually the threshold
  grows so high that it is extremely unlikely that the differences
  will ever be resolved.

I don't want to unfairly single out H.J. or his Linux toolchain
branches.  I've encountered the same problem, perhaps even to a
greater degree, with a commercial vendor that distributes a modifified
version of the GNU toolchain.  But I find it sadly unfortunate that an
open-source project like Linux cannot find it possible to develop
enhancements within the official versions.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]