This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up state on patchwork
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>, libc-alpha at sourceware dot org, Florian Weimer <fweimer at redhat dot com>
- Date: Mon, 28 Sep 2015 15:11:04 -0400
- Subject: Re: Clean up state on patchwork
- Authentication-results: sourceware.org; auth=none
- References: <1442410615 dot 2348 dot 19 dot camel at reserved-bit dot com> <alpine dot DEB dot 2 dot 10 dot 1509172302350 dot 2455 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 10 dot 1509252025170 dot 1123 at digraph dot polyomino dot org dot uk> <20150925205526 dot GA1535 at vapier dot lan> <56094872 dot 80102 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1509281535140 dot 31579 at digraph dot polyomino dot org dot uk> <56097AB6 dot 9040206 at redhat dot com> <20150928184251 dot GC5374 at vapier dot lan>
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.