patch tracking

[Zack Weinberg]

On Fri, Sep 14, 2001 at 12:02:07PM -0700, Joe Buck wrote:
> 
> 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 have been considering a very simple patch tracker which would work
by monitoring the gcc-patches and gcc-cvs mailing lists.  The
principle would be: every time a patch is posted to gcc-patches, it
records the subject line and change log.  (If there is no change log,
it sends an automatic note to the submitter reminding them that they
need to provide change logs.)  When it sees a checkin go by on gcc-cvs
with (nearly) the same change log, it drops the patch from its
database.

Follow-ups to any given patch are detected by subject line, possibly
also References: and In-Reply-To: headers.  As long as a patch is
under active discussion, the tracker does nothing.  However, if a week
goes by with neither discussion nor check-in of any given patch, the
tracker will generate a nag message reminding people to review the
patch.

I have not decided whether the tracker should generate one big nag
message per week, or follow up to each individual thread.  The former
would be less obnoxious, but then obnoxiousness is kind of the point.

There needs to be a way to tell the tracker that a patch has been
dropped or rejected, but I don't know what is appropriate.  I want
it to be hard to do that, because far too often people get discouraged
and withdraw patches that are necessary - they may not have submitted
exactly the right patch for their bug, but we forget that there really
was a bug that needed to get fixed.

There also needs to be a way to indicate that a patch supersedes a
previous one, probably by writing "This patch supersedes <message-id>"
in the text of the new message.

The program needs a way to get the URL of an archived message to
gcc-patches.  Ideally it would be possible to derive that directly
from the message-id; less ideally, the web server could be queried
somehow; even less ideally, the program could run on gcc.gnu.org and
dig through the archive.  (I'd like to run the bot on a machine under
my direct control at least at first.)

zw