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>
- Cc: 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 13:36:54 -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>
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.
So given the present situation of not enough reviewers, how do we prevent
the NEW queue from growing unbounded?
c.