[FFmpeg-devel] [PATCH] doc/developer: Fix typos

[Gyan Doshi]

On 2025-06-26 12:16 pm, softworkz wrote:
> From: softworkz <softworkz at hotmail.com>
>
> Signed-off-by: softworkz <softworkz at hotmail.com>
> ---
>      doc/developer: Fix typos
>
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-103%2Fsoftworkz%2Fsubmit_typos-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-103/softworkz/submit_typos-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/103
>
>   doc/developer.texi | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 108558b9e0..f4ae300c2b 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -424,7 +424,7 @@ paste it from a random place, use an existing file as template.
>   @subheading You must not commit code which breaks FFmpeg!
>   This means unfinished code which is enabled and breaks compilation,
>   or compiles but does not work/breaks the regression tests. Code which
> -is unfinished but disabled may be permitted under-circumstances, like
> +is unfinished but disabled may be permitted under circumstances, like
>   missing samples or an implementation with a small subset of features.
>   Always check the mailing list for any reviewers with issues and test
>   FATE before you push.
> @@ -546,7 +546,7 @@ FFmpeg also has a defined scope - your new API must fit within it.
>   
>   @subsubheading Replacing existing APIs
>   If your new API is replacing an existing one, it should be strictly superior to
> -it, so that the advantages of using the new API outweight the cost to the
> +it, so that the advantages of using the new API outweigh the cost to the
>   callers of changing their code. After adding the new API you should then
>   deprecate the old one and schedule it for removal, as described in
>   @ref{Removing interfaces}.

LGTM.

Regards,
Gyan