Patch review process

Andrew Cagney
2001-06-13T10:14:00Z

> 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