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 <mich...@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@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
