This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gcc development schedule [Re: sharing libcpp between GDB and GCC]
- From: Tom Lord <lord at emf dot net>
- To: gcc at gcc dot gnu dot org
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 26 Mar 2002 22:45:29 -0800 (PST)
- Subject: Re: gcc development schedule [Re: sharing libcpp between GDB and GCC]
- References: <Pine.SUN.3.91.1020327081456.5838F-100000@is>
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.)