Patch review process

[Andrew Cagney <ac131313 at cygnus dot com>]

> I don't have any magic wand to offer, but one way to improve things is to 
> (1) reply to posted patches quickly, even if the reply just says ``noted, 
> will get to it soon''; and (2) review large patches in small chunks and 
> publish any requests to modify the reviewed parts as soon as you can say 
> something useful.  That still leaves the more general design issues that 
> cannot be reviewed without allocating significant time, but at least it 
> gets the minor boring issues such as formatting, ChangeLog entries, etc. 
> out of your way.


It should be possible to take some of these factors out of the equation. 
  For instance, both tracking patches and needing to comment on 
stylistic issues.

Aegis, for instance, handles the adminstrative side of a patch 
submition.  Before a change even surfaces it has been put through some 
basic checking criteria ex: does it compile; does it meet certain 
criteria of the coding standard; if it fixes a bug does it include a 
test case that pass/fails dependant on the change; ... (you could 
quickly get out of control here :-).  Once this basic criteria have been 
met, it is passed on to the relevant maintainer for approval.  Once 
approved, much of the commit phase is also handled automatically.  The 
system always knows what patches are where.

Aegis, in our environment, however won't fly - at a technical level it 
isn't very good at being distributed distributed.

While trying to build an equivalent system on top of CVS might be 
useful, I think we can take a few more basic steps. We could, for 
instance, make:

	o	-Werror a requirement for patches?

	o	a gdbstyle.sh script (a bit like the ari)
		script I have that checks things like
		indentation and stuff like (free vs xfree)

The other one is a way of better tracking patches.  At present, in the 
end, it is still me using my mailbox for manual processing.

	Andrew