On Tue, Jun 28, 2011 at 2:32 PM, Vladimir Makarov <vmaka...@redhat.com> wrote: > 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.
We discussed the maintainer appointing process at the London GCC Gathering event, a summary can be looked up at the pdf attached to http://gcc.gnu.org/wiki/GCCGathering2011 (the "Community" section). Richard.
