Re: increasing the number of GCC reviewers

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 9 Jun 2009, Ian Lance Taylor wrote:

> I believe that the most useful immediate thing we could do to speed up
> gcc development would be to move to a distributed version control
> system.

We haven't even finished the last version control system transition 
(wwwdocs is still using CVS), it's not long since we started it and there 
is as yet no one clear winner in the world of DVCSes, so another 
transition would seem rather premature.

> That should make it much easier for people to swap patches
> around.

I don't see what the present difficulty here is supposed to be.  For small 
to moderate-sized self-contained patches the precise system used makes 
little difference.  For large to huge patch series from contributors with 
write access, they are already able to create whatever branches they may 
wish.  Distributed systems would facilitate large series from contributors 
without write access, but in practice I think such contributions from 
non-regular contributors tend to run into other unrelated issues (and 
hosting a public tree the size of GCC isn't really something to consider 
"easy" whatever system is used).

> It should make it possible for reviewers to take a patch, make
> some changes themselves, and send it back to the original submitter for
> more work.

This is already possible, but I don't think difficulties with it are a 
significant problem with patch review at present.  If the original 
submitter is to submit further patches then having them understand the 
deficiencies enough to fix them themselves is generally better than fixing 
them for them.  (The simpler case of fixing the submitted patch and 
committing the fixed version is already quite common.)

> It would make it much simpler for people to reliably test
> other people's patches, singly or in combination.

As I observe it difficulties in dealing with other people's patches arise 
not because of version control choices but because of interactions between 
logical changes expressed textually in patches, especially global 
mechanical changes, and semantic patch tools seem to me to be more 
promising to help in such areas.

I have observed patch review and its failures in action through following 
the main GCC lists since the start of EGCS.  It's not the large and 
complicated patches than in my experience have difficulty getting 
reviewed; those generally come from people with extensive experience of 
GCC development, and if those people cannot approve their own patches 
there are other people with sufficient interest in them who do so.  It's 
smaller patches, and patches from outsiders, that have the greater 
difficulty, while it's complicated patches from sophisticated developers 
that more advanced version control systems help more with.

If a patch does not attract the interest and attention of reviewers when 
posted, there is no system (human or technical) to notice this and to 
track that it still needs review and who might be a suitable reviewer, 
other than the submitter pinging it.  If a patch is submitted by an 
outsider who hasn't followed all the documentation on submitting patches, 
and may not have properly tested it, or described how it was tested, or 
written a proper ChangeLog entry, or formatted it according to the coding 
standards, or followed the correct abstractions, the fact it doesn't look 
like a normal submission and requires greater effort to review makes it 
less likely to be reviewed.  If a patch from an outsider is nevertheless 
approved, the approver will typically say it is OK, and it will be up to 
the outsider to reply that they don't have write access and get someone to 
commit it.

At the human level I suspect it would help to have people who watch for 
submissions from non-regulars (including those attached to Bugzilla) and 
help them prepare patches following all the usual conventions and get them 
reviewed (checking for copyright assignments at an early stage as needed) 
and make sure the submissions don't get lost.  At the technical level, 
while submissions on gcc-patches take a wide variety of forms, approvals 
are more restricted; it ought to be possible for software to do a 
reasonably good job of tracking which submissions have been reviewed / 
approved / committed (including noticing people trying to submit patches 
through Bugzilla), and of identifying the most likely relevant maintainers 
to review patches, aided by humans in keeping the data clean.

-- 
Joseph S. Myers
joseph@codesourcery.com