On 06/27/2011 06:39 PM, Gerald Pfeifer wrote:
It's my pleasure to announce that, also based on the recommendation of
Eric Botcazou as the current maintainer in that area¹, the steering
committee is appointing Richard Sandiford as an additional RTL optimizers
maintainer.
Please adjust the MAINTAINERS file accordingly, and Happy Hacking,
Richard!
Gerald
¹ Hint, hint, we tend to be open to such recommendations by existing
maintainers. :-)
This is a really strange, contradictory, and unclear decision of the
Steering Committee.
First of all about my point of view of Richard's appointment to whom
I have a really great respect. I'd agree if Richard were appointed as
*non-algorithmic* maintainer or just a reviewer of RTL optimizers. I
think that there is a very small probability that a person could be an
*algorithmic* maintainer of such big area of compiler which includes
RA, reload, haifa insn scheduler, selective insn scheduler, swing
modulo insn scheduler (those are area which I believe I know well).
If RTL optimizers (in the email subject *RTL* maintainer) do not include
areas mentioned by me above, I have no objects.
In Richard case, I even could live with the bigger interpretation of
term 'RTL optimizers'.
In any case it would be nice to clarify what do RTL optimizers
or/and RTL maintainer mean. Does it include the area I mentioned
above? Does it include RTL loop optimizers? Does it include
DFA-infrastructure?
The *bigger problem* in this decision is that SC *violates* its
own policy.
When I asked to be IRA maintainer about 10 months ago, I was told
by several SC members that nobody can be appointed as a maintainer of
GCC part common and important for all targets (like optimizing
passes). Only target (or front-end) maintainers can be appointed and
*only reviewers* should be appointed for optimizing passes. Moreover SC
encourages that the current maintainers (which were appointed before
introducing the policy) of such parts to give up their maintainerships
and become only reviewers. And that they would like to see more
reviewers of important parts of the compiler.
I already wrote that I see an inconsistency in this policy (more
accurately in division on important and less important parts). There
are important and less important parts of the compiler and with my
point of view some important targets should be considered as important
parts of the compiler. I could name x86/x86-64, PPC, and ARM. It is
really strange to me, when there are several x86 target maintainers, to
see only one maintainer without even reviewers of PPC target as there
are no people who knows it well. I could easily name Mike Meissner
(who actually wrote the port and has the best knowledge of it) as PPC
target maintainer/reviewer.
Moreover, I already wrote that I disagree with this policy itself
and we still should appoint maintainers for important parts of GCC.
Unfortunately, I can do nothing to reconsider the policy.
Also I already expressed several times that SC somehow monopolized
the decision to appoint maintainers/reviewers which is a technical
decision. That is wrong. IMO, the appointments should be decided by
people who knows particular parts of GCC. And the hint in Gerald's
email is just a confirmation of this.
And the final thought. SC always avoids to inform how the
appointment decision were made and discussed (I understand that there
are serious reasons for this). But for me this decision is a sign of
the quality of the discussion (or absence of it at all) about the
appointments because I hardly can imagine that all SC committee
members forgot about their own policy.
