This is the mail archive of the
mailing list for the GCC project.
Re: patch tracking
- To: Joe Buck <jbuck at synopsys dot COM>
- Subject: Re: patch tracking
- From: Bernd Schmidt <bernds at redhat dot com>
- Date: Sat, 15 Sep 2001 11:06:06 +0100 (BST)
- cc: <gcc at gcc dot gnu dot org>
On Fri, 14 Sep 2001, Joe Buck wrote:
> The biggest problem facing GCC seems to be that patches aren't getting
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.
Most people seem to think the constant breakage in the mainline is caused
by insufficient testing and can be avoided by making the check-in criteria
more painful and by resorting to automatic reversion if a patch turns out
to be a dud. I'm of the opinion that sometime, patch review isn't done
as well as it should be done (testing cannot prove correctness, but
The real risk for quality is not getting too few patches reviewed, it's
getting too many patches installed.
When I to review a bugfix patch, I try to make sure I fully understand
the problem - that may involve debugging it myself. For larger patches,
I still try to make sure that I understand it well enough so that I could
quickly fix a bug in it if it gets installed. My opinioin is that if a
patch I reviewed causes breakage, I made a serious mistake. In practice,
this means that I don't get to review very many patches, since anything
nontrivial takes hours to review, and there's a limited supply of those.
Now people may claim that egcs was formed to address this bottleneck. I
know how frustrating it can be not to have a patch reviewed; I was
suffering from it for a long time as well. But we have a lot more
contributors now than in 1997, and the number of experienced developers
doesn't grow as quickly as the number of submissions. I don't think
there's a good solution to this problem.