From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zack Weinberg To: Joe Buck Cc: gcc@gcc.gnu.org Subject: Re: patch tracking Date: Fri, 14 Sep 2001 14:03:00 -0000 Message-id: <20010914140254.F443@codesourcery.com> References: <200109141902.MAA15299@atrus.synopsys.com> X-SW-Source: 2001-09/msg00566.html 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 " 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