Tracking patch pings

[Mike Frysinger]

On Wednesday 15 May 2013 17:41:21 Joseph S. Myers wrote:
> On Wed, 15 May 2013, Mike Frysinger wrote:
> > On Wednesday 15 May 2013 17:20:10 Joseph S. Myers wrote:
> > > To raise more visibly something I mentioned in another thread:
> > > 
> > > Should we have some system for tracking patches that are pending
> > > review, especially those that have been pinged?  For example, there
> > > could be a list on the wiki page for the current release cycle of
> > > patches believed to be ready for review and the contribution checklist
> > > could say to add your patch there when pinging it.  (Ideally we'd have
> > > people who specifically try to keep a lookout for unreviewed patches
> > > and add them to the list after a week even if not pinged.)
> > 
> > or use patchwork ?
> > http://patchwork.ozlabs.org/
> > 
> > looks like they're handling gcc-patches already.  and they have the
> > infrastructure.  all we have to do is ask them to turn it on and see how
> > it goes ? :)
> 
> The GCC list has thousands of patches in it.  To be useful someone would
> need to remove non-patches and reviewed patches promptly, to the extent it
> can't do that automatically.  If someone's interested in doing that, sure,
> setting it up to monitor libc-alpha and libc-ports makes sense.  I guess
> then people who know about older patches pending review should get them
> reposted to enter them in the system.

my point was that the system can clearly handle large and small volumes, and 
can handle any mailing list.  the "overhead" for us to at least try it out for 
glibc is practically nil.

the fact that people aren't updating the status in patchwork of patches isn't 
really a slight against patchwork.  you'll see the exact same behavior in the 
wiki based approach as well as any other: if people aren't maintaining state, 
then things will fill up and go stale.

> (It doesn't seem clear from the documentation ... I assume patchwork will
> do sensible things if e.g. a patch is marked reviewed and then a
> subsequent revision of that patch is posted and so needs to be visible as
> needing review, or if a thread ends up containing discussions of multiple
> different patches.)

when you're signed in, you can modify the state of a single patch (or a bunch 
in one go) to things like New, Rejected, Accepted, Superseded, etc...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20130516/69b02ff5/attachment.sig>