Re: SC issues revised

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Tom Lord writes:

Tom> In general, I think that more money ought to be spent on GCC,
Tom> specifically to make improvements that are of a general nature --
Tom> valuable to everyone interested in GCC.  I think that the political
Tom> structure of project governance correlates directly with the
Tom> probability that such spending can occur: the SC has the opportunity
Tom> to define a framework that companies can pay into for general
Tom> improvements.

	The fallacy in your reasoning is assuming that these discussions
do not occur already -- that electing members of the GCC SC through a
popularity contest and/or soliciting formal corporate sponsorship is going
to change or improve this situation.

	All of the companies that use and benefit from the GNU toolchain
(AMD, Apple, ARM, CodeSourcery, Compaq, HP, IBM, Intel, Motorola, Red Hat,
SGI, Sun, SuSE, and Swox, just to name a few) contribute to the toolchain
because of their own business self-interest which can be justified to
their respective owners or shareholders.  All of these companies have
contributed to the GNU toolchain, continue to contribute to the GNU
toolchain, and have more contributions coming down the pike.

	The amount that these companies spend depends on a business term
called "Return on Investment" (ROI), not on membership in the GCC SC or on
the Free Software community shaking them down for money.  If the companies
have the money available in their budgets and think that spending the
money on the GNU toolchain will give them the most benefit, they will
direct the money to that effort.

	All of the companies know about (or should know about) the
advantages and deficiencies in GCC's technology and GCC's development
process.  The companies discuss the issues with members of the GCC SC and
with various GNU toolchain support companies.  I am fairly certain that
none of the companies want to create a new, independent bureaucracy to
administer funding of GNU toolchain development.  The GCC SC can help the
companies understand how best to contribute to common infrastructure
projects, but that is about it.

	Discussions about improving the GNU toolchain and coordinating
that development occur all the time among interested parties.  Electing
the GCC SC or making the GCC SC mailinglist public is not going to make
those discussions public and is not going to improve the pace.  Mid-level
RTL, CFG, AST, and other restructuring optimizations are being developed
-- in public.  Maybe a formal design to which everyone agreed would be
better, but design by committee on a public mailinglist could be the worst
thing to happen to the process.

	Using the GCC mailinglist to discuss these long-term technical
issues is great.  I am glad that you have started that part of the
conversation and I hope that everyone will contribute.  But your proposal
for changing the GCC SC is not going to affect funding of these projects
and is not going to further your goal.

David