public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernd Schmidt <bernds@redhat.com>
To: Joe Buck <jbuck@synopsys.COM>
Cc: <gcc@gcc.gnu.org>
Subject: Re: patch tracking
Date: Sat, 15 Sep 2001 03:07:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.33.0109151048000.29982-100000@host140.cambridge.redhat.com> (raw)
In-Reply-To: <200109141902.MAA15299@atrus.synopsys.com>

On Fri, 14 Sep 2001, Joe Buck wrote:

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

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
understanding can).

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.


Bernd

  parent reply	other threads:[~2001-09-15  3:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-14 12:02 Joe Buck
2001-09-14 12:21 ` Diego Novillo
2001-09-14 12:24 ` egcs
2001-09-14 12:28 ` Joseph S. Myers
2001-09-14 12:35   ` Phil Edwards
2001-09-14 14:03 ` Zack Weinberg
2001-09-14 14:16   ` Phil Edwards
2001-09-14 14:51     ` Joe Buck
2001-09-14 15:53     ` Zack Weinberg
2001-09-14 14:53   ` Joe Buck
2001-09-14 15:48     ` Zack Weinberg
2001-09-14 14:24 ` Gerald Pfeifer
2001-09-15  3:07 ` Bernd Schmidt [this message]
2001-09-16 14:46   ` Joe Buck
2001-09-18 16:18     ` Marc Espie
2001-09-18  9:49 dewar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.33.0109151048000.29982-100000@host140.cambridge.redhat.com \
    --to=bernds@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jbuck@synopsys.COM \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).