Clean up state on patchwork

[Mike Frysinger]

On 28 Sep 2015 13:36, Carlos O'Donell wrote:
> On 09/28/2015 11:43 AM, Joseph Myers wrote:
> >> will simply grow forever, and that's fine. Aren't we always just looking
> > 
> > It should only grow forever because of patches blocked on something other 
> > than review.  For example: patches needing the submitter to make required 
> > changes (though for inexperienced submitters, it would be helpful for more 
> > experienced developers to pick up such changes as needed if the submitter 
> > appears to have stopped working on the change); patches needing copyright 
> > assignment; patches depending on changes to an external component such as 
> > the Linux kernel; patches requiring the submitter to help lead discussion 
> > to consensus (though if it seems the answer is likely to be that the 
> > proposed feature isn't wanted at all, other people could usefully try to 
> > lead the discussion to that conclusion so the patch can be marked 
> > rejected).
> 
> This is only true if we actually have the resources capable of handling
> the volume of patches submitted? Which I surmise that at present we don't
> otherwise the patch queue would be going down.

from time to time i flip through the backlog and try to focus on the one-offs.
the excessive patches that have been superseded or submitted but not cleaned up
makes this difficult.  to the point where i probably give up simply because i
couldn't easily locate a patch that is actually unreviewed.

if patchwork is going to fill up with patches that have been reviewed/resolved
but not had their status updated, then it seems like kind of a waste of time, at
least for my use case.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150928/3b2c6bed/attachment.sig>