Re: gcc development schedule [Re: sharing libcpp between GDB and GCC]

[Tom Lord <lord@emf.net>]

   From: Eli Zaretskii <eliz@is.elta.co.il>
   On Tue, 26 Mar 2002, Tim Hollebeek wrote:

   > > The approach I am suggesting is an evolutionary step beyond 
   > > the current practices and is quite consistent with the SC 
   > > development goals.
   > 
   > The SC can and will be the judge of that.  Until then, please make
   > sure that your contributions to gcc meet or exceed your contributions
   > to this list.

   Sigh.  Another attempt to shut up discenting opinions instead of dealing 
   with them in a civilized and technical manner.


Thanks.  May I add a few points?

1) It's no secret that I'm not a core maintainer of GCC.  I have done
   some GCC hacking and ran into some practical obstacles while
   looking for ways to see that work wind up in GCC distributions.

   Some of the invective I get in private mail (or in Eli's message)
   seems to suggest that unless you've done 10 ports, have write
   access, or otherwise have a suitable GCC-testosterone certificate
   that, well, you're a valid target for complete disregard or worse.


2) I do have a pretty decent amount of experience in software tools,
   process automation, and related software engineering issues.  I
   have a pretty decent amount experience in the Free Software and
   open source worlds.  These are areas I think a lot about and build
   tools for.  I'm really not talking through my hat here.


3) I've had some chats with a few maintainers and SC members via
   email.  They've corrected me on a few of my perceptions of the
   current processes (as I asked them to).  They've remarked that some
   of my ideas seem like good ones, though overall there's a lot of
   hesitancy to embrace any idea that people don't see immediately how
   to pay for.  I have detected in SC member comments, both privately
   and on the list, insidious conflict-of-interest issues at work: 
   it's not where I want to focus on this list because I think
   people's intentions are rightly oriented -- but there _is_ a
   structural problem with how the project is run, having both tool
   and political components.


4) There is a history, in the GCC/egcs schizm, of people identifying
   practical needs of the project and that turning into improvements
   in project governance, process, infrastructure, and relation to
   commercial activities.  So it really isn't even naive to raise some
   pretty well understood process issues in hopes that the engineers
   can lead the market in this area.


5) The GCC project is larger now than just a few years ago, and vastly
   more important to the entire Free Software and open source worlds.
   This is a critical structural element.  It deserves careful
   attention and input from multiple perspectives.


-t

(And I'll leave gdb on the CC line since these issues are broader in
scope than just GCC.)