From mboxrd@z Thu Jan  1 00:00:00 1970
From: Joe Buck <jbuck@synopsys.COM>
To: gcc@gcc.gnu.org
Subject: patch tracking
Date: Fri, 14 Sep 2001 12:02:00 -0000
Message-id: <200109141902.MAA15299@atrus.synopsys.com>
X-SW-Source: 2001-09/msg00555.html

The biggest problem facing GCC seems to be that patches aren't getting
reviewed.  I think it's a process problem; we don't have a system for
keeping track of patches, and the load on the people qualified to
approve patches is too high.  As a result, it's very difficult for
people without blanket write privs to effectively contribute to the
project; the turnaround for patch review can be months.  This means
we're not getting the problems fixed and the frustration level is high.

In thinking about what the ideal system should look like, I have the
following ideas (feel free to discard and come up with something better):

First, we want to decrease the number of patches that the overworked
experts must handle, by having a pre-screening process.  So, we have
a team of volunteers who have some experience but are not necessarily
gurus.  These folks would be the first screen for incoming patches.  They
would ask the following questions:

1) Are there papers on file for the patch submitter?  (The volunteers
would need to have a copy of the list to verify this).

(If not, ask submitter to file papers and resubmit the patch when
complete)

2) Does the patch follow the GNU coding guidelines?  If not, ask submitter
to revise.  (not worth nitpicking over extremely tiny violations here,
since this is not the final review)

3) Has the submitter indicated that the patch has been adequately
tested, and that the rules on http://gcc.gnu.org/contribute.html
have been followed?  If not, confirm, ask to resubmit.

4) Does the patch contain obvious bogosities?  If so, kick it back.

Note that these questions apply to code changes, not documentation
changes.  We may want to split off proposed patches to the manual
(that do not accompany code changes) or to the web site onto a separate
list that would run the way we do now, since we don't have the same
problems there. (gcc-doc-patches, say).

Next, we want to carefully track patches that pass the pre-screening
process to make sure that they get a timely review and are added if
appropriate.

If these tests are all passed, then the patch would enter a tracking
system.  Perhaps GNATS can be used, even though the patch is not exactly
a bug.  A new category proposed-patch can be created with the patch
as an attachment.  We can come up with conventions as to how to use
the severity and priority fields, we can keep track of what has been
analyzed, etc.

I realize that GNATS is not ideal for patch-tracking, but it's already
in place.

Thoughts?

Joe