[FFmpeg-devel] [PATCH] doc/patchwork: Document the patchwork states
bodecsb at vivanet.hu
Sat Oct 22 20:49:45 EEST 2016
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
>>>> +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
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
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:
More information about the ffmpeg-devel