on patch queues (reply to Joseph S. Myers)

[Joseph S. Myers]

On Tue, 10 Dec 2002, Tom Lord wrote:

> 1) As you say: a simple bot that grabs patches from the gcc-patches
>    list.

I'll add the following requirement for a patch bot (also orthogonal to
revision control - if someone feels like writing a patch bot (and perhaps
that should go on the beginners' projects page, it's a reasonable task for
someone unfamiliar with GCC internals but experienced with programming to
do) they could do one now, add features relating to revision control
later, and it could start entirely unofficial with web page and database
on a private server somewhere (and thus possibly demonstrate usefullness
despite variation from comments here, and indicate what's really useful in
such a system by giving experience).

* Should track follow-ups to patches on the list.  In particular, should
check for stylised comments indicating that a patch is disapproved (needs
changes before commit) or approved.  (Linking in to revision control
allows it to track when a patch is applied as well, so detecting patches
that are approved but not applied.)

The main aim of a patch bot is to avoid patches languishing in the state
where they've neither been approved nor disapproved: each patch should at 
least get reviewed in a reasonably timely manner though the response could 
be that the patch can't be evaluated because some of the contributing 
instructions haven't been followed, or that the feature is unwanted.

(Anyone writing a patch bot will need to work out what other transitions
occur on gcc-patches.  For example, a new patch may supersede an old one;
one maintainer may approve a patch while another disapproves it or insists
that documentation / testcases are added, and a patch may be approved
subject to changes.  All common transitions need some simple command in
messages to effect that transition.  But fancy features like in bug 
tracking databases aren't needed; the main visible list from the bot would 
be one of unreviewed patches, details of rejected patches or those needing 
more work would just be hidden somewhere for when we want to answer the 
"what happened to that patch?" questions.  With linking to revision 
control, unreviewed patches can be marked with whether they still apply; 
the preumption being for reviewed patches the responsibility lies with 
the contributor, with unreviewed ones it's good if we can review them 
before they conflict with other changes.  Your description of how the 
status of unreviewed patches can be tracked seems reasonable, the aim is 
to keep the number of unreviewed patches down.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk