[FFmpeg-devel] [PATCH] doc/patchwork: Document the patchwork states

[Bodecs Bela]

2016.10.22. 18:29 keltezéssel, Stephen Hutchinson írta:
> On 10/22/2016 8:25 AM, Michael Niedermayer wrote:
>> On Sat, Oct 22, 2016 at 02:12:18PM +0200, Clément Bœsch wrote:
>>> On Sat, Oct 22, 2016 at 01:38:47PM +0200, Michael Niedermayer wrote:
>>>> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
>>>> ---
>>>>  doc/patchwork | 9 +++++++++
>>>>  1 file changed, 9 insertions(+)
>>>>  create mode 100644 doc/patchwork
>>>>
>>>> diff --git a/doc/patchwork b/doc/patchwork
>>>> new file mode 100644
>>>> index 0000000..9486e07
>>>> --- /dev/null
>>>> +++ b/doc/patchwork
>>>> @@ -0,0 +1,9 @@
>>>> +Patchwork states
>>>> +
>>>> +NEW:               Initial state of new patches
>>>> +Accepted:          The patch was pushed to the main master repository
>>>> +Rejected:          The patch has been rejected
>>>> +Not Applicable:    The patch does not apply to the main master 
>>>> repository
>>>> +Superseded:        A newer version of the patch has been posted
>>>> +Changes Requested: The patch has been or is under review and 
>>>> changes have been requested
>>>> +RFC:               The patch is not intended to be applied but 
>>>> only for comments
>>>
>>> no "dropped" or "invalid" state? (similar to a self rejected patch)
>>
>> Dropped state added
>>
>> anything else we need ?
>>
>> [...]
>>
>
> The other ones that appear in the list on Patchwork are
> 'Under Review', 'Deferred', and 'Awaiting Upstream'.
>
> 'Under Review' is fairly self-explanatory, but when and why
> a patch should be flagged that way (as opposed to simply
> remaining as 'New' until it gets committed) isn't.
>
> 'Deferred' sounds like either holding off on commit to a
> later date or kicking the can to somebody else, and...
>
> 'Awaiting Upstream' isn't all that clear about its purpose -
> awaiting upstream for what? Review, commit, something else
> I've not thought of?  Is this the state that should be used
> for patches that are queued up for commit?
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
under review: someone marked it because he/she investigate this patch. 
So the patch submitter and other potential reviewers may feel/be_sure 
that this patch is already handled by someone else.
I suggest to use it. This is psychologic aspect that the patch submitter 
may feel more patienty toward review process opposite to mere "new" state.

I think if we will use under_review state it will have an impact for 
community communication:
if a patch remains in under_review state for long period the patch 
submitter may contact directly the specific person who put his/her patch 
into this state.
But if a patch remains in new state for a longer period the submitter 
will ping the whole communitiy.

I think the new->under_review is not a one-way change. The opposite 
direction under_review->new also should be available.

I also suggest to communicate clearly the valid/expected state changes:

new->(under_review|deferred|rejected|accepted|superseed|not_app)
deferred->(new|under_review|deferred|rejected|accepted|superseed|not_app)
under_review->(new||deferred|rejected|accepted|superseed|not_app)

etc.

bb