[FFmpeg-devel] [PATCH 1/5] doc/developer: Move checklist into Submitting Patches chapter

[softworkz]

From: softworkz <softworkz at hotmail.com>

Signed-off-by: softworkz <softworkz at hotmail.com>
---
 doc/developer.texi | 192 +++++++++++++++++++++++----------------------
 1 file changed, 98 insertions(+), 94 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 108558b9e0..42e42350a5 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -722,101 +722,8 @@ and has no lrint()')
 Also please if you send several patches, send each patch as a separate mail,
 do not attach several unrelated patches to the same mail.
 
-Patches should be posted to the
- at uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
-mailing list. Use @code{git send-email} when possible since it will properly
-send patches without requiring extra care. If you cannot, then send patches
-as base64-encoded attachments, so your patch is not trashed during
-transmission. Also ensure the correct mime type is used
-(text/x-diff or text/x-patch or at least text/plain) and that only one
-patch is inline or attached per mail.
-You can check @url{https://patchwork.ffmpeg.org}, if your patch does not show up, its mime type
-likely was wrong.
-
- at subheading How to setup git send-email?
-
-Please see @url{https://git-send-email.io/}.
-For gmail additionally see @url{https://shallowsky.com/blog/tech/email/gmail-app-passwds.html}.
-
- at subheading Sending patches from email clients
-Using @code{git send-email} might not be desirable for everyone. The
-following trick allows to send patches via email clients in a safe
-way. It has been tested with Outlook and Thunderbird (with X-Unsent
-extension) and might work with other applications.
-
-Create your patch like this:
-
- at verbatim
-git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel at ffmpeg.org -1 1a2b3c4d
- at end verbatim
-
-Now you'll just need to open the eml file with the email application
-and execute 'Send'.
-
- at subheading Reviews
-Your patch will be reviewed on the mailing list. You will likely be asked
-to make some changes and are expected to send in an improved version that
-incorporates the requests from the review. This process may go through
-several iterations. Once your patch is deemed good enough, some developer
-will pick it up and commit it to the official FFmpeg tree.
-
-Give us a few days to react. But if some time passes without reaction,
-send a reminder by email. Your patch should eventually be dealt with.
-
 
- at chapter New codecs or formats checklist
-
- at enumerate
- at item
-Did you use av_cold for codec initialization and close functions?
-
- at item
-Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
-AVInputFormat/AVOutputFormat struct?
-
- at item
-Did you bump the minor version number (and reset the micro version
-number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
-
- at item
-Did you register it in @file{allcodecs.c} or @file{allformats.c}?
-
- at item
-Did you add the AVCodecID to @file{codec_id.h}?
-When adding new codec IDs, also add an entry to the codec descriptor
-list in @file{libavcodec/codec_desc.c}.
-
- at item
-If it has a FourCC, did you add it to @file{libavformat/riff.c},
-even if it is only a decoder?
-
- at item
-Did you add a rule to compile the appropriate files in the Makefile?
-Remember to do this even if you're just adding a format to a file that is
-already being compiled by some other rule, like a raw demuxer.
-
- at item
-Did you add an entry to the table of supported formats or codecs in
- at file{doc/general_contents.texi}?
-
- at item
-Did you add an entry in the Changelog?
-
- at item
-If it depends on a parser or a library, did you add that dependency in
-configure?
-
- at item
-Did you @code{git add} the appropriate files before committing?
-
- at item
-Did you make sure it compiles standalone, i.e. with
- at code{configure --disable-everything --enable-decoder=foo}
-(or @code{--enable-demuxer} or whatever your component is)?
- at end enumerate
-
-
- at chapter Patch submission checklist
+ at section Patch submission checklist
 
 @enumerate
 @item
@@ -927,6 +834,103 @@ Test your code with valgrind and or Address Sanitizer to ensure it's free
 of leaks, out of array accesses, etc.
 @end enumerate
 
+
+ at section Submission procedures
+
+Patches should be posted to the
+ at uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
+mailing list. Use @code{git send-email} when possible since it will properly
+send patches without requiring extra care. If you cannot, then send patches
+as base64-encoded attachments, so your patch is not trashed during
+transmission. Also ensure the correct mime type is used
+(text/x-diff or text/x-patch or at least text/plain) and that only one
+patch is inline or attached per mail.
+You can check @url{https://patchwork.ffmpeg.org}, if your patch does not show up, its mime type
+likely was wrong.
+
+ at subheading How to setup git send-email?
+
+Please see @url{https://git-send-email.io/}.
+For gmail additionally see @url{https://shallowsky.com/blog/tech/email/gmail-app-passwds.html}.
+
+ at subheading Sending patches from email clients
+Using @code{git send-email} might not be desirable for everyone. The
+following trick allows to send patches via email clients in a safe
+way. It has been tested with Outlook and Thunderbird (with X-Unsent
+extension) and might work with other applications.
+
+Create your patch like this:
+
+ at verbatim
+git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel at ffmpeg.org -1 1a2b3c4d
+ at end verbatim
+
+Now you'll just need to open the eml file with the email application
+and execute 'Send'.
+
+ at subheading Reviews
+Your patch will be reviewed on the mailing list. You will likely be asked
+to make some changes and are expected to send in an improved version that
+incorporates the requests from the review. This process may go through
+several iterations. Once your patch is deemed good enough, some developer
+will pick it up and commit it to the official FFmpeg tree.
+
+Give us a few days to react. But if some time passes without reaction,
+send a reminder by email. Your patch should eventually be dealt with.
+
+
+ at chapter New codecs or formats checklist
+
+ at enumerate
+ at item
+Did you use av_cold for codec initialization and close functions?
+
+ at item
+Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
+AVInputFormat/AVOutputFormat struct?
+
+ at item
+Did you bump the minor version number (and reset the micro version
+number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
+
+ at item
+Did you register it in @file{allcodecs.c} or @file{allformats.c}?
+
+ at item
+Did you add the AVCodecID to @file{codec_id.h}?
+When adding new codec IDs, also add an entry to the codec descriptor
+list in @file{libavcodec/codec_desc.c}.
+
+ at item
+If it has a FourCC, did you add it to @file{libavformat/riff.c},
+even if it is only a decoder?
+
+ at item
+Did you add a rule to compile the appropriate files in the Makefile?
+Remember to do this even if you're just adding a format to a file that is
+already being compiled by some other rule, like a raw demuxer.
+
+ at item
+Did you add an entry to the table of supported formats or codecs in
+ at file{doc/general_contents.texi}?
+
+ at item
+Did you add an entry in the Changelog?
+
+ at item
+If it depends on a parser or a library, did you add that dependency in
+configure?
+
+ at item
+Did you @code{git add} the appropriate files before committing?
+
+ at item
+Did you make sure it compiles standalone, i.e. with
+ at code{configure --disable-everything --enable-decoder=foo}
+(or @code{--enable-demuxer} or whatever your component is)?
+ at end enumerate
+
+
 @chapter Patch review process
 
 All patches posted to ffmpeg-devel will be reviewed, unless they contain a
-- 
ffmpeg-codebot