This is the mail archive of the
mailing list for the glibc project.
Re: Suggest "Dropped" state for patchwork.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Fri, 28 Nov 2014 21:14:46 -0500
- Subject: Re: Suggest "Dropped" state for patchwork.
- Authentication-results: sourceware.org; auth=none
- References: <5478BA61 dot 1040007 at redhat dot com> <20141129011720 dot GJ24022 at spoyarek dot pnq dot redhat dot com>
On 11/28/2014 08:17 PM, Siddhesh Poyarekar wrote:
> On Fri, Nov 28, 2014 at 01:09:37PM -0500, Carlos O'Donell wrote:
>> While doing more and more patcwork work I noticed a problem
>> I had with the `Rejected` state.
>> The more rejected patches you have the harder it becomes to
>> review the rejected patch list to see which patches you want
>> to do over again with a different approach.
>> I have updated "Patch Review Workflow" with a "Dropped"
>> state that developers can use to indicate they don't plan
>> to do any more work on the patch. Either "Rejected" or
>> "Dropped" are end states, but "Dropped" allows the developer
>> to also use patchwork as a todo list, not just the maintainers.
>> And as maintainers we all have our own patches to track.
>> https://sourceware.org/glibc/wiki/Patch Review Workflow
>> Should we add a "Dropped" state?
> I think you'll have the same problem with the Dropped state - the more
> dropped patches you have, the harder it becomes to review the list to
> see which patches you want to do over again with a different approach.
You never review "Dropped" patches. You review "Rejected" patches and
move the ones you never want to see into "Dropped."
The question I want to answer is: Which of the recently rejected patches
do I need to work on?
Thus you review the "Rejected" patches, moving dropped ones to "Dropped"
and keeping the list of "Rejected" patches small for review.
Does that help clarify my need?