Re: PING^2: resubmitted IRA improvement patches

[David Edelsohn <dje dot gcc at gmail dot com>]

Many FOSS projects and companies operate very successfully and
efficiently on a "code review required" basis.  Nothing is perfect,
but I generally have heard good things from projects that implement
that model.  Having a second pair of eyes double-check a patch can
help a lot.

Small patches by developers in their own area of expertise probably
will not gain a lot from a review, but I have witnessed many cases
when someone pointed out an API that the developer should have used or
a problematic corner case the developer missed.

Larger patches, especially ones that change or extend the algorithmic
design of GCC, deserve more care and attention.  Working on GCC
requires multiple types of knowledge: GCC's internals, compiler
optimization algorithms, algorithm implementation details and tuning.
No one knows everything and a marketplace of ideas should produce a
better solution.

The GCC SC current policy for appointing "maintainers" and "reviewers"
broadly can be described as: "maintainers" are for narrow areas, like
GC, OpenMP, language front ends and ports, and "reviewers" for broader
areas, like middle-end, RTL and dataflow.  In other words appointing
maintainers in areas that may not have enough people with expertise to
review each other's patches and avoided by higher-level reviewers who
do not feel qualified to review the patches.  If there are enough
qualified reviewers for a narrower area, "reviewer" is preferred.

A lot of developers were "grandfathered" in to maintainer roles that
should be reviewers.  And a lot of developers who are or were less
active for a period of time never resigned their roles.  These
situations have not caused noticeable problems, other than envy, so
the SC has chosen not to address it.  However, note that all Global
Write Privilege maintainers were converted to Global Reviewers.  The
SC welcomes any other groups of maintainers to voluntarily convert to
reviewers.

If you think some developers or potential reviewers are not aware of
an upcoming patch, why not pro-actively contact them instead of
waiting for them to come to you?  A little bit of extra effort by a
patch developer can go a long way.

More effective GCC developers generally figure out what other
developers are knowledgeable in an area, how those developers prefer
to communicate (private email, public mailing list, IRC, bugzilla,
phone, skype, lunch, conferences) and contact them using the other
developers' preferred communication medium.  They chat, brainstorm,
solicit ideas and experience, and generally ensure that everyone is on
the same page.  They alert the appropriate people ahead of time --
beyond the minimal, official effort.  Communicate early and often.

I think the GCC community should look for ways to attract more
reviewers and how to make reviewers more efficient instead of looking
for ways to allow developers to avoid patch reviews.  How can we
update and improve GCC's patch review work-flow?

- David