This is the mail archive of the
mailing list for the GCC project.
Re: MAINTAINERS policy question
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: MAINTAINERS policy question
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Sun, 16 Sep 2001 17:13:44 -0400
- cc: Andreas Jaeger <aj at suse dot de>, Bernd Schmidt <bernds at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
>>>>> Mark Mitchell writes:
Mark> I would extend it to documentation that affects X, config.foo files
Mark> that affect X, and so forth...
What about collect2.c? What about parts of libstdc++? What about
libtool? What about config.gcc? There is no clear definition of "so
forth". We only have obscured the ambiguity which remains.
Remember that there are a lot of machine-dependent infrastructure
pieces distributed throughout the common files in GCC which were
implemented for just one target or only a few targets. The register
allocator clearly is global, common infrastructure and the config files
clearly are local to a port, but some of GCC falls in the gray area
inbetween. It is fallacious reasoning to generalize from specific
components like the register allocator to all components throughout the
There is a difference between policy and practice. I propose that
the policy should remain liberal while continuing to be implemented more
narrowly in practice. In other words, one waits for approval from the
maintainer of a component or someone with global write privilege as a
I think Bernd's original question is ill-formed and is generating
an inaccurate response. GCC is not implemented with the clear dichotomy
that the question of "any patch affecting port X versus config/X/*"
implies. Simplistic, hasty answers to a complex question intertwined with
GCC's design diverse target support will not help GCC development, IMHO.