Clean up state on patchwork

[Carlos O'Donell]

On 09/28/2015 02:42 PM, Mike Frysinger wrote:
> 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.

What use case are you interested in? Looking for the next patch to work on?

I'd rather not loose your interest in patchwork, particularly if a minor
change can help you do your work better.

Cheers,
Carlos.