Re: patch tracking

[Joe Buck <jbuck at synopsys dot COM>]

I wrote:
> > The biggest problem facing GCC seems to be that patches aren't getting
> > reviewed.

Berndt writes:
> Even if I'm alone on this, let me just say that I also think there's a
> problem that patches are sometimes installed without sufficient review.

Note that the two-level process I proposed is not intended to reduce the
amount of review any patch gets; quite the opposite.  Every patch has to
get through two rounds.  The difference is that we keep track so that
patches aren't lost.  It may still take a long time to get patches
installed, but at least we'll be able to see where each patch is in the
process.

We could perhaps increase the analysis requirements.  There are a few
developers who seem to be in the habit of contributing lots of patches
without much explanation of what problem is being fixed.  Such patches
could be punted back in the first round.  The final reviewer still must
verify that the analysis and patch are correct, of course.

There is one particular category of patch that I am especially eager
to speed up: patches that fix severe breakage (like "won't bootstrap")
on minority platforms.  If we can't find a way to do that, as time
goes on gcc will work on fewer and fewer platforms.  We may need to
have a priority-setting process, and the SC might have to get involved,
meaning that the SC would request developers to treat certain patches
as higher priority (not as pressure to include a possibly bogus patch,
but to actively work with contributors to fix certain problems).  Of
course, we are all volunteers so this prioritization would only be
a strong request.