[FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[ffmpegagent]

Signed-off-by: softworkz softworkz@hotmail.com

softworkz (5):
  doc/developer: Move checklist into Submitting Patches chapter
  doc/developer: Move codecs/formats checklist into Development Policy
    chapter
  doc/developer: Reorder Submission procedures content
  doc/developer: Merge Review paragraphs and deduplicate
  doc/developer: Add subsection about patch submission via FFstaging

 doc/developer.texi | 234 ++++++++++++++++++++++++---------------------
 1 file changed, 127 insertions(+), 107 deletions(-)


base-commit: 1b643e3f65d75a4e6a25986466254bdd4fc1a01a
Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-76%2Fsoftworkz%2Fsubmit_website_update-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-76/softworkz/submit_website_update-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/76
-- 
ffmpeg-codebot
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@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
-@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.
-
-@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}.
-
-@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:
-
-@verbatim
-git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel@ffmpeg.org -1 1a2b3c4d
-@end verbatim
-
-Now you'll just need to open the eml file with the email application
-and execute 'Send'.
-
-@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.
-
 
-@chapter New codecs or formats checklist
-
-@enumerate
-@item
-Did you use av_cold for codec initialization and close functions?
-
-@item
-Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
-AVInputFormat/AVOutputFormat struct?
-
-@item
-Did you bump the minor version number (and reset the micro version
-number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
-
-@item
-Did you register it in @file{allcodecs.c} or @file{allformats.c}?
-
-@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}.
-
-@item
-If it has a FourCC, did you add it to @file{libavformat/riff.c},
-even if it is only a decoder?
-
-@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.
-
-@item
-Did you add an entry to the table of supported formats or codecs in
-@file{doc/general_contents.texi}?
-
-@item
-Did you add an entry in the Changelog?
-
-@item
-If it depends on a parser or a library, did you add that dependency in
-configure?
-
-@item
-Did you @code{git add} the appropriate files before committing?
-
-@item
-Did you make sure it compiles standalone, i.e. with
-@code{configure --disable-everything --enable-decoder=foo}
-(or @code{--enable-demuxer} or whatever your component is)?
-@end enumerate
-
-
-@chapter Patch submission checklist
+@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
 
+
+@section Submission procedures
+
+Patches should be posted to the
+@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.
+
+@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}.
+
+@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:
+
+@verbatim
+git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel@ffmpeg.org -1 1a2b3c4d
+@end verbatim
+
+Now you'll just need to open the eml file with the email application
+and execute 'Send'.
+
+@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.
+
+
+@chapter New codecs or formats checklist
+
+@enumerate
+@item
+Did you use av_cold for codec initialization and close functions?
+
+@item
+Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
+AVInputFormat/AVOutputFormat struct?
+
+@item
+Did you bump the minor version number (and reset the micro version
+number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
+
+@item
+Did you register it in @file{allcodecs.c} or @file{allformats.c}?
+
+@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}.
+
+@item
+If it has a FourCC, did you add it to @file{libavformat/riff.c},
+even if it is only a decoder?
+
+@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.
+
+@item
+Did you add an entry to the table of supported formats or codecs in
+@file{doc/general_contents.texi}?
+
+@item
+Did you add an entry in the Changelog?
+
+@item
+If it depends on a parser or a library, did you add that dependency in
+configure?
+
+@item
+Did you @code{git add} the appropriate files before committing?
+
+@item
+Did you make sure it compiles standalone, i.e. with
+@code{configure --disable-everything --enable-decoder=foo}
+(or @code{--enable-demuxer} or whatever your component is)?
+@end enumerate
+
+
 @chapter Patch review process
 
 All patches posted to ffmpeg-devel will be reviewed, unless they contain a
-- 
ffmpeg-codebot

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/5] doc/developer: Move codecs/formats checklist into Development Policy chapter

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@hotmail.com>
---
 doc/developer.texi | 104 +++++++++++++++++++++++----------------------
 1 file changed, 53 insertions(+), 51 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 42e42350a5..a723d41f39 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -651,6 +651,59 @@ Removing previously deprecated APIs.
 Performing ABI- but not API-breaking changes, like reordering struct contents.
 @end itemize
 
+
+@section New codecs or formats checklist
+
+@enumerate
+@item
+Did you use av_cold for codec initialization and close functions?
+
+@item
+Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
+AVInputFormat/AVOutputFormat struct?
+
+@item
+Did you bump the minor version number (and reset the micro version
+number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
+
+@item
+Did you register it in @file{allcodecs.c} or @file{allformats.c}?
+
+@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}.
+
+@item
+If it has a FourCC, did you add it to @file{libavformat/riff.c},
+even if it is only a decoder?
+
+@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.
+
+@item
+Did you add an entry to the table of supported formats or codecs in
+@file{doc/general_contents.texi}?
+
+@item
+Did you add an entry in the Changelog?
+
+@item
+If it depends on a parser or a library, did you add that dependency in
+configure?
+
+@item
+Did you @code{git add} the appropriate files before committing?
+
+@item
+Did you make sure it compiles standalone, i.e. with
+@code{configure --disable-everything --enable-decoder=foo}
+(or @code{--enable-demuxer} or whatever your component is)?
+@end enumerate
+
+
 @section Documentation/Other
 @subheading Subscribe to the ffmpeg-devel mailing list.
 It is important to be subscribed to the
@@ -879,57 +932,6 @@ 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.
 
 
-@chapter New codecs or formats checklist
-
-@enumerate
-@item
-Did you use av_cold for codec initialization and close functions?
-
-@item
-Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
-AVInputFormat/AVOutputFormat struct?
-
-@item
-Did you bump the minor version number (and reset the micro version
-number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
-
-@item
-Did you register it in @file{allcodecs.c} or @file{allformats.c}?
-
-@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}.
-
-@item
-If it has a FourCC, did you add it to @file{libavformat/riff.c},
-even if it is only a decoder?
-
-@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.
-
-@item
-Did you add an entry to the table of supported formats or codecs in
-@file{doc/general_contents.texi}?
-
-@item
-Did you add an entry in the Changelog?
-
-@item
-If it depends on a parser or a library, did you add that dependency in
-configure?
-
-@item
-Did you @code{git add} the appropriate files before committing?
-
-@item
-Did you make sure it compiles standalone, i.e. with
-@code{configure --disable-everything --enable-decoder=foo}
-(or @code{--enable-demuxer} or whatever your component is)?
-@end enumerate
-
 
 @chapter Patch review process
 
-- 
ffmpeg-codebot

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/5] doc/developer: Reorder Submission procedures content

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@hotmail.com>
---
 doc/developer.texi | 48 ++++++++++++++++++++++++----------------------
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index a723d41f39..5a026fff0e 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -752,10 +752,7 @@ We think our rules are not too hard. If you have comments, contact us.
 First, read the @ref{Coding Rules} above if you did not yet, in particular
 the rules regarding patch submission.
 
-When you submit your patch, please use @code{git format-patch} or
-@code{git send-email}. We cannot read other diffs :-).
-
-Also please do not submit a patch which contains several unrelated changes.
+Please do not submit a patch which contains several unrelated changes.
 Split it into separate, self-contained pieces. This does not mean splitting
 file by file. Instead, make the patch as small as possible while still
 keeping it as a logical unit that contains an individual change, even
@@ -768,13 +765,6 @@ The tool is located in the tools directory.
 Run the @ref{Regression tests} before submitting a patch in order to verify
 it does not cause unexpected problems.
 
-It also helps quite a bit if you tell us what the patch does (for example
-'replaces lrint by lrintf'), and why (for example '*BSD isn't C99 compliant
-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.
-
 
 @section Patch submission checklist
 
@@ -892,23 +882,35 @@ of leaks, out of array accesses, etc.
 
 Patches should be posted to the
 @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.
+mailing list. 
+
+There are several ways how this can be accomplished:
 
-@subheading How to setup git send-email?
+@subsection Using @code{git send-email}: Git sends e-mail directly via SMTP
+
+@code{git send-email} will properly format and send
+send patches without requiring extra care if the required setup is feasible.
 
 Please see @url{https://git-send-email.io/}.
+
 For gmail additionally see @url{https://shallowsky.com/blog/tech/email/gmail-app-passwds.html}.
 
-@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
+
+@subsection With @code{git format-patch}: Sending patches from email clients
+
+You can create patch files via @code{git format-patch} and send them as inline
+text or 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).
+
+If you send several patches, send each patch as a separate mail,
+do not attach several unrelated patches to the same mail.
+
+You can check @url{https://patchwork.ffmpeg.org}, if your patch does not show up, its mime type
+likely was wrong.
+
+
+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.
 
-- 
ffmpeg-codebot

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/5] doc/developer: Merge Review paragraphs and deduplicate

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@hotmail.com>
---
 doc/developer.texi | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 5a026fff0e..145b57b249 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -923,22 +923,15 @@ git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml -
 Now you'll just need to open the eml file with the email application
 and execute 'Send'.
 
-@subheading Reviews
+
+@chapter Patch review process
+
 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.
-
-
-
-@chapter Patch review process
-
-All patches posted to ffmpeg-devel will be reviewed, unless they contain a
-clear note that the patch is not for the git master branch.
 Reviews and comments will be posted as replies to the patch on the
 mailing list. The patch submitter then has to take care of every comment,
 that can be by resubmitting a changed patch or by discussion. Resubmitted
@@ -948,6 +941,9 @@ simple and small patches happen immediately while large patches will generally
 have to be changed and reviewed many times before they are approved.
 After a patch is approved it will be committed to the repository.
 
+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.
+
 We will review all submitted patches, but sometimes we are quite busy so
 especially for large patches this can take several weeks.
 
-- 
ffmpeg-codebot

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 5/5] doc/developer: Add subsection about patch submission via FFstaging

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@hotmail.com>
---
 doc/developer.texi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index 145b57b249..a3ae9e6973 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -923,6 +923,22 @@ git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml -
 Now you'll just need to open the eml file with the email application
 and execute 'Send'.
 
+@subsection FFstaging: Automated GitHub PR to Mailing List submission
+
+This is an easy way which doesn't require writing Git commands or SMTP
+configuration. Basically, it works like this:
+
+@itemize @bullet
+@item
+You make a GitHub Pull Request on https://github.com/ffstaging/FFmpeg
+@item
+You make a comment with "/submit"
+@item
+The PR will be submitted to the FFmpeg Mailing List as regular patches
+@end itemize
+
+More details can be found on the Wiki page of the GitHub repository:
+https://github.com/ffstaging/FFmpeg/wiki
 
 @chapter Patch review process
 
-- 
ffmpeg-codebot
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[softworkz .]

> -----Original Message-----
> From: ffmpegagent <ffmpegagent@gmail.com>
> Sent: Donnerstag, 8. Mai 2025 12:22
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz <softworkz@hotmail.com>
> Subject: [PATCH 0/5] doc/developer: Add subsection about patch submission via
> FFstaging
> 
> Signed-off-by: softworkz softworkz@hotmail.com
> 
> softworkz (5):
>   doc/developer: Move checklist into Submitting Patches chapter
>   doc/developer: Move codecs/formats checklist into Development Policy
>     chapter
>   doc/developer: Reorder Submission procedures content
>   doc/developer: Merge Review paragraphs and deduplicate
>   doc/developer: Add subsection about patch submission via FFstaging
> 
>  doc/developer.texi | 234 ++++++++++++++++++++++++---------------------
>  1 file changed, 127 insertions(+), 107 deletions(-)
> 
> 
> base-commit: 1b643e3f65d75a4e6a25986466254bdd4fc1a01a
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-
> 76%2Fsoftworkz%2Fsubmit_website_update-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> 76/softworkz/submit_website_update-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/76
> --
> ffmpeg-codebot


Forgot so save the cover letter text before submitting:


The https://ffmpeg.org/developer.html (doc/developer.texi) page contains a lot of good information but there's some structural and contentual duplication that is begging for cleanup:

[3 Development Policy](https://ffmpeg.org/developer.html#Development-Policy-1)
[4 Submitting patches](https://ffmpeg.org/developer.html#Submitting-patches-1)
[5 New codecs or formats checklist](https://ffmpeg.org/developer.html#New-codecs-or-formats-checklist)
[6 Patch submission checklist](https://ffmpeg.org/developer.html#Patch-submission-checklist)
[7 Patch review process](https://ffmpeg.org/developer.html#Patch-review-process)

- a Patch submission checklist clearly belongs to the context of  "Submitting Patches"
- a checklist about the requirements for adding new codecs/formats is mostly a matter of policies
- after moving 5 into 3 and 6 into 4,  another duplication can be resolved elegantly as 4 ends with a section about patch reviews which is then adjacent to the current 7 (patch review process)
- inside 4:
  - some duplication between 4's intro and the checklist can be removed
  - the second part becomes "Submission procedures" with three subsections (send-email, format-patch and FFstaging) and the content separated in a more logical way


Thanks
sw
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1102 bytes --]

On 08/05/2025 12:22, ffmpegagent wrote:
> Signed-off-by: softworkz softworkz@hotmail.com
> 
> softworkz (5):
>    doc/developer: Move checklist into Submitting Patches chapter
>    doc/developer: Move codecs/formats checklist into Development Policy
>      chapter
>    doc/developer: Reorder Submission procedures content
>    doc/developer: Merge Review paragraphs and deduplicate
>    doc/developer: Add subsection about patch submission via FFstaging
> 
>   doc/developer.texi | 234 ++++++++++++++++++++++++---------------------
>   1 file changed, 127 insertions(+), 107 deletions(-)
> 
> 
> base-commit: 1b643e3f65d75a4e6a25986466254bdd4fc1a01a
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-76%2Fsoftworkz%2Fsubmit_website_update-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-76/softworkz/submit_website_update-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/76

No.
We're not going to accept patches via github. Not when we're going to 
enable the forgejo instance soon, as there's an agreement.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
> Sent: Donnerstag, 8. Mai 2025 13:20
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about
> patch submission via FFstaging
> 
> On 08/05/2025 12:22, ffmpegagent wrote:
> > Signed-off-by: softworkz softworkz@hotmail.com
> >
> > softworkz (5):
> >    doc/developer: Move checklist into Submitting Patches chapter
> >    doc/developer: Move codecs/formats checklist into Development Policy
> >      chapter
> >    doc/developer: Reorder Submission procedures content
> >    doc/developer: Merge Review paragraphs and deduplicate
> >    doc/developer: Add subsection about patch submission via FFstaging
> >
> >   doc/developer.texi | 234 ++++++++++++++++++++++++---------------------
> >   1 file changed, 127 insertions(+), 107 deletions(-)
> >
> >
> > base-commit: 1b643e3f65d75a4e6a25986466254bdd4fc1a01a
> > Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-
> 76%2Fsoftworkz%2Fsubmit_website_update-v1
> > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> 76/softworkz/submit_website_update-v1
> > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/76
> 
> No.
> We're not going to accept patches via github. Not when we're going to
> enable the forgejo instance soon, as there's an agreement.


This is not about patch acceptance on GitHub. It doesn't stand in contradiction
or competition to ForgeJo (which I do support moving to).

It is simply a tool for sending patches to the mailing list. It has no value
outside of the ML workflow. The service is public, everybody can use it,
patches arrive on the ML - nobody needs to care where they're coming from 
or how they were generated.

All my patches are going this route, btw.

sw 



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2163 bytes --]

On 08/05/2025 13:33, softworkz . wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
>> Sent: Donnerstag, 8. Mai 2025 13:20
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about
>> patch submission via FFstaging
>>
>> On 08/05/2025 12:22, ffmpegagent wrote:
>>> Signed-off-by: softworkz softworkz@hotmail.com
>>>
>>> softworkz (5):
>>>     doc/developer: Move checklist into Submitting Patches chapter
>>>     doc/developer: Move codecs/formats checklist into Development Policy
>>>       chapter
>>>     doc/developer: Reorder Submission procedures content
>>>     doc/developer: Merge Review paragraphs and deduplicate
>>>     doc/developer: Add subsection about patch submission via FFstaging
>>>
>>>    doc/developer.texi | 234 ++++++++++++++++++++++++---------------------
>>>    1 file changed, 127 insertions(+), 107 deletions(-)
>>>
>>>
>>> base-commit: 1b643e3f65d75a4e6a25986466254bdd4fc1a01a
>>> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-
>> 76%2Fsoftworkz%2Fsubmit_website_update-v1
>>> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
>> 76/softworkz/submit_website_update-v1
>>> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/76
>>
>> No.
>> We're not going to accept patches via github. Not when we're going to
>> enable the forgejo instance soon, as there's an agreement.
> 
> 
> This is not about patch acceptance on GitHub. It doesn't stand in contradiction
> or competition to ForgeJo (which I do support moving to).
> 
> It is simply a tool for sending patches to the mailing list. It has no value
> outside of the ML workflow. The service is public, everybody can use it,
> patches arrive on the ML - nobody needs to care where they're coming from
> or how they were generated.
> 
> All my patches are going this route, btw.
You're free to use any tool you like. But this patchset makes it official.
Pointing out that it's just a service or a tool that anyone can run is 
in conflict with the fact that.

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
> Sent: Donnerstag, 8. Mai 2025 14:00
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about
> patch submission via FFstaging
> 
> On 08/05/2025 13:33, softworkz . wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
> >> Sent: Donnerstag, 8. Mai 2025 13:20
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about
> >> patch submission via FFstaging
> >>
> >> On 08/05/2025 12:22, ffmpegagent wrote:
> >>> Signed-off-by: softworkz softworkz@hotmail.com
> >>>
> >>> softworkz (5):
> >>>     doc/developer: Move checklist into Submitting Patches chapter
> >>>     doc/developer: Move codecs/formats checklist into Development Policy
> >>>       chapter
> >>>     doc/developer: Reorder Submission procedures content
> >>>     doc/developer: Merge Review paragraphs and deduplicate
> >>>     doc/developer: Add subsection about patch submission via FFstaging
> >>>
> >>>    doc/developer.texi | 234 ++++++++++++++++++++++++---------------------
> >>>    1 file changed, 127 insertions(+), 107 deletions(-)
> >>>
> >>>
> >>> base-commit: 1b643e3f65d75a4e6a25986466254bdd4fc1a01a
> >>> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> ffstaging-
> >> 76%2Fsoftworkz%2Fsubmit_website_update-v1
> >>> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> >> 76/softworkz/submit_website_update-v1
> >>> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/76
> >>
> >> No.
> >> We're not going to accept patches via github. Not when we're going to
> >> enable the forgejo instance soon, as there's an agreement.
> >
> >
> > This is not about patch acceptance on GitHub. It doesn't stand in
> contradiction
> > or competition to ForgeJo (which I do support moving to).
> >
> > It is simply a tool for sending patches to the mailing list. It has no value
> > outside of the ML workflow. The service is public, everybody can use it,
> > patches arrive on the ML - nobody needs to care where they're coming from
> > or how they were generated.
> >
> > All my patches are going this route, btw.
> You're free to use any tool you like. But this patchset makes it official.
> Pointing out that it's just a service or a tool that anyone can run is
> in conflict with the fact that.

Hey Lynne,

I'm afraid, I can't follow. What do you mean?

"..in conflict with the fact that"

- all my patches are going this route?
- I'm free to use any tool I like?
- this patchset makes it official that an online-version of "send-patch" exists?
- it's just a service or a tool that anyone can run?

And which bad thing exactly does this patchset make official?


From my point of view, I would be concerned about this, if - and only if - there
was a risk (or chance) that a secondary platform of communication or 
collaboration could arise from it. I am totally against that, same like
I'm strongly opposing a side-by-side of ML and ForgeJo. There must be a single 
point of truth and focus for all members. Any kind of "a little here and a little
there" would be the worst possible outcome as far as I see it.

Regarding FFstaging though, there's no such risk (ask me "why" if you wanna know).

Best wishes
sw








_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[Lynne]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 3095 bytes --]

On 08/05/2025 14:26, softworkz . wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
>> Sent: Donnerstag, 8. Mai 2025 14:00
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about
>> patch submission via FFstaging
>>
>> On 08/05/2025 13:33, softworkz . wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Lynne
>>>> Sent: Donnerstag, 8. Mai 2025 13:20
>>>> To: ffmpeg-devel@ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about
>>>> patch submission via FFstaging
>>>>
>>>> On 08/05/2025 12:22, ffmpegagent wrote:
>>>>> Signed-off-by: softworkz softworkz@hotmail.com
>>>>>
>>>>> softworkz (5):
>>>>>      doc/developer: Move checklist into Submitting Patches chapter
>>>>>      doc/developer: Move codecs/formats checklist into Development Policy
>>>>>        chapter
>>>>>      doc/developer: Reorder Submission procedures content
>>>>>      doc/developer: Merge Review paragraphs and deduplicate
>>>>>      doc/developer: Add subsection about patch submission via FFstaging
>>>>>
>>>>>     doc/developer.texi | 234 ++++++++++++++++++++++++---------------------
>>>>>     1 file changed, 127 insertions(+), 107 deletions(-)
>>>>>
>>>>>
>>>>> base-commit: 1b643e3f65d75a4e6a25986466254bdd4fc1a01a
>>>>> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
>> ffstaging-
>>>> 76%2Fsoftworkz%2Fsubmit_website_update-v1
>>>>> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
>>>> 76/softworkz/submit_website_update-v1
>>>>> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/76
>>>>
>>>> No.
>>>> We're not going to accept patches via github. Not when we're going to
>>>> enable the forgejo instance soon, as there's an agreement.
>>>
>>>
>>> This is not about patch acceptance on GitHub. It doesn't stand in
>> contradiction
>>> or competition to ForgeJo (which I do support moving to).
>>>
>>> It is simply a tool for sending patches to the mailing list. It has no value
>>> outside of the ML workflow. The service is public, everybody can use it,
>>> patches arrive on the ML - nobody needs to care where they're coming from
>>> or how they were generated.
>>>
>>> All my patches are going this route, btw.
>> You're free to use any tool you like. But this patchset makes it official.
>> Pointing out that it's just a service or a tool that anyone can run is
>> in conflict with the fact that.
> 
> Hey Lynne,
> 
> I'm afraid, I can't follow. What do you mean?
> 
> "..in conflict with the fact that"
> 
> - all my patches are going this route?
> - I'm free to use any tool I like?
> - this patchset makes it official that an online-version of "send-patch" exists?
> - it's just a service or a tool that anyone can run?
> 
> And which bad thing exactly does this patchset make official?

If its mentioned as part of our documentation, it's official.


[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/5] doc/developer: Add subsection about patch submission via FFstaging

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 1421 bytes --]

On 5/8/2025 7:22 AM, softworkz wrote:
> From: softworkz <softworkz@hotmail.com>
> 
> Signed-off-by: softworkz <softworkz@hotmail.com>
> ---
>   doc/developer.texi | 16 ++++++++++++++++
>   1 file changed, 16 insertions(+)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 145b57b249..a3ae9e6973 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -923,6 +923,22 @@ git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml -
>   Now you'll just need to open the eml file with the email application
>   and execute 'Send'.
>   
> +@subsection FFstaging: Automated GitHub PR to Mailing List submission
> +
> +This is an easy way which doesn't require writing Git commands or SMTP
> +configuration. Basically, it works like this:
> +
> +@itemize @bullet
> +@item
> +You make a GitHub Pull Request on https://github.com/ffstaging/FFmpeg
> +@item
> +You make a comment with "/submit"
> +@item
> +The PR will be submitted to the FFmpeg Mailing List as regular patches
> +@end itemize
> +
> +More details can be found on the Wiki page of the GitHub repository:
> +https://github.com/ffstaging/FFmpeg/wiki
>   
>   @chapter Patch review process

NAK.

This is not part of our infra. We had a meltdown of people complaining 
about stuff like this months ago, citing the xz backdoor and social 
engineering, so this is absolutely not ok.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[Nicolas George]

Lynne (HE12025-05-08):
> If its mentioned as part of our documentation, it's official.

I second your objection to this.

This proposal comes from softworkz, who has been here barely two
minutes, trying to get Andreas to change the way he sends patches.

You are free to use whatever tool you want on your side, but if your
tools deal badly with the workflow of one of our most senior and
productive contributors, fixing it by fixing your tools is your
responsibility, and yours alone.

And if you want to join a team, the way to go at it is to observe how
the senior members are doing things, to take advice and learn. You will
be able to give advice and be listened to progressively as you prove the
quality of said advice and the quality of your contribution to the time.
Which is not going well in this instance as the main quality being
proven is disruption.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/5] doc/developer: Add subsection about patch submission via FFstaging

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of James Almer
> Sent: Donnerstag, 8. Mai 2025 14:40
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 5/5] doc/developer: Add subsection about
> patch submission via FFstaging
> 
> On 5/8/2025 7:22 AM, softworkz wrote:
> > From: softworkz <softworkz@hotmail.com>
> >
> > Signed-off-by: softworkz <softworkz@hotmail.com>
> > ---
> >   doc/developer.texi | 16 ++++++++++++++++
> >   1 file changed, 16 insertions(+)
> >
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index 145b57b249..a3ae9e6973 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -923,6 +923,22 @@ git format-patch -s -o "outputfolder" --add-header "X-
> Unsent: 1" --suffix .eml -
> >   Now you'll just need to open the eml file with the email application
> >   and execute 'Send'.
> >
> > +@subsection FFstaging: Automated GitHub PR to Mailing List submission
> > +
> > +This is an easy way which doesn't require writing Git commands or SMTP
> > +configuration. Basically, it works like this:
> > +
> > +@itemize @bullet
> > +@item
> > +You make a GitHub Pull Request on https://github.com/ffstaging/FFmpeg
> > +@item
> > +You make a comment with "/submit"
> > +@item
> > +The PR will be submitted to the FFmpeg Mailing List as regular patches
> > +@end itemize
> > +
> > +More details can be found on the Wiki page of the GitHub repository:
> > +https://github.com/ffstaging/FFmpeg/wiki
> >
> >   @chapter Patch review process
> 
> NAK.
> 
> This is not part of our infra. We had a meltdown of people complaining
> about stuff like this months ago, citing the xz backdoor and social
> engineering, so this is absolutely not ok.

Okay fine, this isn't worth my time. The service exists for three years
and I didn't have the slightest thought about promoting it until Michael
suggested it yesterday.

But well, let's scratch that patchset, there's no point in fighting for it.

Best regards,
sw

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Donnerstag, 8. Mai 2025 14:47
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about
> patch submission via FFstaging
> 
> Lynne (HE12025-05-08):
> > If its mentioned as part of our documentation, it's official.
> 
> I second your objection to this.
> 
> This proposal comes from softworkz, who has been here barely two
> minutes, trying to get Andreas to change the way he sends patches.
> 
> You are free to use whatever tool you want on your side, but if your
> tools deal badly with the workflow of one of our most senior and
> productive contributors, fixing it by fixing your tools is your
> responsibility, and yours alone.
> 
> And if you want to join a team, the way to go at it is to observe how
> the senior members are doing things, to take advice and learn. You will
> be able to give advice and be listened to progressively as you prove the
> quality of said advice and the quality of your contribution to the time.
> Which is not going well in this instance as the main quality being
> proven is disruption.

It is a misconception that respect would grow by age or membership 
duration. Respect is something that needs to be earned, no matter whether
you want to call yourself "senior" or anything. Every single action,
every response, every sentence and every word can matter.

In this regard, I can only suggest you to keep on trying, but as far as
I'm seeing it, you're totally broke at this time.


And what I can promise you, is that each time you're writing a message 
like above, you'll get a reply like that.
Try harder, it's not that difficult to improve communication skills.

softworkz


_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about patch submission via FFstaging

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Nicolas
> George
> Sent: Donnerstag, 8. Mai 2025 14:47
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 0/5] doc/developer: Add subsection about
> patch submission via FFstaging
> 
> Lynne (HE12025-05-08):
> > If its mentioned as part of our documentation, it's official.
> 
> I second your objection to this.
> 
> This proposal comes from softworkz, who has been here barely two
> minutes

For the record, if we consider the existence of FFmpeg as an hour,
like you are seeming to allude to and look at the first commit as
evidence for being here, then we get to the following results:

+-----------+--------+
| Fabrice   | 60 min |
+-----------+--------+
| Michael   | 58 min |
+-----------+--------+
| Nicolas   | 44 min |
+-----------+--------+
| James     | 32 min |
+-----------+--------+
| softworkz | 22 min |
+-----------+--------+
| Andreas   | 16 min |
+-----------+--------+
| Lynne     | 15 min |
+-----------+--------+

It obviously doesn't say anything about the amount of contribution,
but well - it was _your_ analogy.

sw

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 0/4] doc/developer: Restructure docs about patch submission

[ffmpegagent]

The https://ffmpeg.org/developer.html (doc/developer.texi) page contains a
lot of good information but there's some structural and contentual
duplication that is begging for cleanup:

3 Development Policy
[https://ffmpeg.org/developer.html#Development-Policy-1] 4 Submitting
patches [https://ffmpeg.org/developer.html#Submitting-patches-1] 5 New
codecs or formats checklist
[https://ffmpeg.org/developer.html#New-codecs-or-formats-checklist] 6 Patch
submission checklist
[https://ffmpeg.org/developer.html#Patch-submission-checklist] 7 Patch
review process [https://ffmpeg.org/developer.html#Patch-review-process]

 * a Patch submission checklist clearly belongs to the context of
   "Submitting Patches"
 * a checklist about the requirements for adding new codecs/formats is
   mostly a matter of policies
 * after moving 5 into 3 and 6 into 4, another duplication can be resolved
   elegantly as 4 ends with a section about patch reviews which is then
   adjacent to the current 7 (patch review process)
 * inside 4:
   * some duplication between 4's intro and the checklist can be removed
   * the second part becomes "Submission procedures" with two subsections
     (send-email and format-patch) and the content separated in a more
     logical way


Versions
========


V2
==

 * Removed the 5th commit due to controversial reception
   The other changes are still worthwhile for review

.

softworkz (4):
  doc/developer: Move checklist into Submitting Patches chapter
  doc/developer: Move codecs/formats checklist into Development Policy
    chapter
  doc/developer: Reorder Submission procedures content
  doc/developer: Merge Review paragraphs and deduplicate

 doc/developer.texi | 218 +++++++++++++++++++++++----------------------
 1 file changed, 111 insertions(+), 107 deletions(-)


base-commit: 1b643e3f65d75a4e6a25986466254bdd4fc1a01a
Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-76%2Fsoftworkz%2Fsubmit_website_update-v2
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-76/softworkz/submit_website_update-v2
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/76

Range-diff vs v1:

 1:  79230103ee = 1:  79230103ee doc/developer: Move checklist into Submitting Patches chapter
 2:  ae47e8bda0 = 2:  ae47e8bda0 doc/developer: Move codecs/formats checklist into Development Policy chapter
 3:  866fd3aa3b = 3:  866fd3aa3b doc/developer: Reorder Submission procedures content
 4:  2e4a47f000 = 4:  2e4a47f000 doc/developer: Merge Review paragraphs and deduplicate
 5:  c8dba13b92 < -:  ---------- doc/developer: Add subsection about patch submission via FFstaging

-- 
ffmpeg-codebot
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@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
-@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.
-
-@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}.
-
-@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:
-
-@verbatim
-git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel@ffmpeg.org -1 1a2b3c4d
-@end verbatim
-
-Now you'll just need to open the eml file with the email application
-and execute 'Send'.
-
-@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.
-
 
-@chapter New codecs or formats checklist
-
-@enumerate
-@item
-Did you use av_cold for codec initialization and close functions?
-
-@item
-Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
-AVInputFormat/AVOutputFormat struct?
-
-@item
-Did you bump the minor version number (and reset the micro version
-number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
-
-@item
-Did you register it in @file{allcodecs.c} or @file{allformats.c}?
-
-@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}.
-
-@item
-If it has a FourCC, did you add it to @file{libavformat/riff.c},
-even if it is only a decoder?
-
-@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.
-
-@item
-Did you add an entry to the table of supported formats or codecs in
-@file{doc/general_contents.texi}?
-
-@item
-Did you add an entry in the Changelog?
-
-@item
-If it depends on a parser or a library, did you add that dependency in
-configure?
-
-@item
-Did you @code{git add} the appropriate files before committing?
-
-@item
-Did you make sure it compiles standalone, i.e. with
-@code{configure --disable-everything --enable-decoder=foo}
-(or @code{--enable-demuxer} or whatever your component is)?
-@end enumerate
-
-
-@chapter Patch submission checklist
+@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
 
+
+@section Submission procedures
+
+Patches should be posted to the
+@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.
+
+@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}.
+
+@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:
+
+@verbatim
+git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml --to ffmpeg-devel@ffmpeg.org -1 1a2b3c4d
+@end verbatim
+
+Now you'll just need to open the eml file with the email application
+and execute 'Send'.
+
+@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.
+
+
+@chapter New codecs or formats checklist
+
+@enumerate
+@item
+Did you use av_cold for codec initialization and close functions?
+
+@item
+Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
+AVInputFormat/AVOutputFormat struct?
+
+@item
+Did you bump the minor version number (and reset the micro version
+number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
+
+@item
+Did you register it in @file{allcodecs.c} or @file{allformats.c}?
+
+@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}.
+
+@item
+If it has a FourCC, did you add it to @file{libavformat/riff.c},
+even if it is only a decoder?
+
+@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.
+
+@item
+Did you add an entry to the table of supported formats or codecs in
+@file{doc/general_contents.texi}?
+
+@item
+Did you add an entry in the Changelog?
+
+@item
+If it depends on a parser or a library, did you add that dependency in
+configure?
+
+@item
+Did you @code{git add} the appropriate files before committing?
+
+@item
+Did you make sure it compiles standalone, i.e. with
+@code{configure --disable-everything --enable-decoder=foo}
+(or @code{--enable-demuxer} or whatever your component is)?
+@end enumerate
+
+
 @chapter Patch review process
 
 All patches posted to ffmpeg-devel will be reviewed, unless they contain a
-- 
ffmpeg-codebot

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 2/4] doc/developer: Move codecs/formats checklist into Development Policy chapter

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@hotmail.com>
---
 doc/developer.texi | 104 +++++++++++++++++++++++----------------------
 1 file changed, 53 insertions(+), 51 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 42e42350a5..a723d41f39 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -651,6 +651,59 @@ Removing previously deprecated APIs.
 Performing ABI- but not API-breaking changes, like reordering struct contents.
 @end itemize
 
+
+@section New codecs or formats checklist
+
+@enumerate
+@item
+Did you use av_cold for codec initialization and close functions?
+
+@item
+Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
+AVInputFormat/AVOutputFormat struct?
+
+@item
+Did you bump the minor version number (and reset the micro version
+number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
+
+@item
+Did you register it in @file{allcodecs.c} or @file{allformats.c}?
+
+@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}.
+
+@item
+If it has a FourCC, did you add it to @file{libavformat/riff.c},
+even if it is only a decoder?
+
+@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.
+
+@item
+Did you add an entry to the table of supported formats or codecs in
+@file{doc/general_contents.texi}?
+
+@item
+Did you add an entry in the Changelog?
+
+@item
+If it depends on a parser or a library, did you add that dependency in
+configure?
+
+@item
+Did you @code{git add} the appropriate files before committing?
+
+@item
+Did you make sure it compiles standalone, i.e. with
+@code{configure --disable-everything --enable-decoder=foo}
+(or @code{--enable-demuxer} or whatever your component is)?
+@end enumerate
+
+
 @section Documentation/Other
 @subheading Subscribe to the ffmpeg-devel mailing list.
 It is important to be subscribed to the
@@ -879,57 +932,6 @@ 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.
 
 
-@chapter New codecs or formats checklist
-
-@enumerate
-@item
-Did you use av_cold for codec initialization and close functions?
-
-@item
-Did you add a long_name under NULL_IF_CONFIG_SMALL to the AVCodec or
-AVInputFormat/AVOutputFormat struct?
-
-@item
-Did you bump the minor version number (and reset the micro version
-number) in @file{libavcodec/version.h} or @file{libavformat/version.h}?
-
-@item
-Did you register it in @file{allcodecs.c} or @file{allformats.c}?
-
-@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}.
-
-@item
-If it has a FourCC, did you add it to @file{libavformat/riff.c},
-even if it is only a decoder?
-
-@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.
-
-@item
-Did you add an entry to the table of supported formats or codecs in
-@file{doc/general_contents.texi}?
-
-@item
-Did you add an entry in the Changelog?
-
-@item
-If it depends on a parser or a library, did you add that dependency in
-configure?
-
-@item
-Did you @code{git add} the appropriate files before committing?
-
-@item
-Did you make sure it compiles standalone, i.e. with
-@code{configure --disable-everything --enable-decoder=foo}
-(or @code{--enable-demuxer} or whatever your component is)?
-@end enumerate
-
 
 @chapter Patch review process
 
-- 
ffmpeg-codebot

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 3/4] doc/developer: Reorder Submission procedures content

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@hotmail.com>
---
 doc/developer.texi | 48 ++++++++++++++++++++++++----------------------
 1 file changed, 25 insertions(+), 23 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index a723d41f39..5a026fff0e 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -752,10 +752,7 @@ We think our rules are not too hard. If you have comments, contact us.
 First, read the @ref{Coding Rules} above if you did not yet, in particular
 the rules regarding patch submission.
 
-When you submit your patch, please use @code{git format-patch} or
-@code{git send-email}. We cannot read other diffs :-).
-
-Also please do not submit a patch which contains several unrelated changes.
+Please do not submit a patch which contains several unrelated changes.
 Split it into separate, self-contained pieces. This does not mean splitting
 file by file. Instead, make the patch as small as possible while still
 keeping it as a logical unit that contains an individual change, even
@@ -768,13 +765,6 @@ The tool is located in the tools directory.
 Run the @ref{Regression tests} before submitting a patch in order to verify
 it does not cause unexpected problems.
 
-It also helps quite a bit if you tell us what the patch does (for example
-'replaces lrint by lrintf'), and why (for example '*BSD isn't C99 compliant
-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.
-
 
 @section Patch submission checklist
 
@@ -892,23 +882,35 @@ of leaks, out of array accesses, etc.
 
 Patches should be posted to the
 @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.
+mailing list. 
+
+There are several ways how this can be accomplished:
 
-@subheading How to setup git send-email?
+@subsection Using @code{git send-email}: Git sends e-mail directly via SMTP
+
+@code{git send-email} will properly format and send
+send patches without requiring extra care if the required setup is feasible.
 
 Please see @url{https://git-send-email.io/}.
+
 For gmail additionally see @url{https://shallowsky.com/blog/tech/email/gmail-app-passwds.html}.
 
-@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
+
+@subsection With @code{git format-patch}: Sending patches from email clients
+
+You can create patch files via @code{git format-patch} and send them as inline
+text or 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).
+
+If you send several patches, send each patch as a separate mail,
+do not attach several unrelated patches to the same mail.
+
+You can check @url{https://patchwork.ffmpeg.org}, if your patch does not show up, its mime type
+likely was wrong.
+
+
+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.
 
-- 
ffmpeg-codebot

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 4/4] doc/developer: Merge Review paragraphs and deduplicate

[softworkz]

From: softworkz <softworkz@hotmail.com>

Signed-off-by: softworkz <softworkz@hotmail.com>
---
 doc/developer.texi | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 5a026fff0e..145b57b249 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -923,22 +923,15 @@ git format-patch -s -o "outputfolder" --add-header "X-Unsent: 1" --suffix .eml -
 Now you'll just need to open the eml file with the email application
 and execute 'Send'.
 
-@subheading Reviews
+
+@chapter Patch review process
+
 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.
-
-
-
-@chapter Patch review process
-
-All patches posted to ffmpeg-devel will be reviewed, unless they contain a
-clear note that the patch is not for the git master branch.
 Reviews and comments will be posted as replies to the patch on the
 mailing list. The patch submitter then has to take care of every comment,
 that can be by resubmitting a changed patch or by discussion. Resubmitted
@@ -948,6 +941,9 @@ simple and small patches happen immediately while large patches will generally
 have to be changed and reviewed many times before they are approved.
 After a patch is approved it will be committed to the repository.
 
+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.
+
 We will review all submitted patches, but sometimes we are quite busy so
 especially for large patches this can take several weeks.
 
-- 
ffmpeg-codebot
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".