ffmpeg/FFmpeg
1
0
Fork 0
mirror of https://git.ffmpeg.org/ffmpeg.git synced 2024-09-20 05:16:38 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix the most obvious typos in the development policy doc section

Browse Source 
Originally committed as revision 8746 to svn://svn.ffmpeg.org/ffmpeg/trunk
This commit is contained in:
Reimar Döffinger 2007-04-17 14:06:08 +00:00
parent dd597cd7b0
commit 442d1598a3
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/ffmpeg-doc.texi
View File

@ -1509,7 +1509,7 @@ please use av_log() instead.
understanding them on the commit log mailing list easier. This also helps understanding them on the commit log mailing list easier. This also helps
in case of debugging later on. in case of debugging later on.
Also if you have doubts about splitting or not splitting, do not hesitate to Also if you have doubts about splitting or not splitting, do not hesitate to
ask/disscuss it on the developer mailing list. ask/discuss it on the developer mailing list.
@item @item
Do not change behavior of the program (renaming options etc) without Do not change behavior of the program (renaming options etc) without
first discussing it on the ffmpeg-devel mailing list. Do not remove first discussing it on the ffmpeg-devel mailing list. Do not remove
@ -1620,8 +1620,8 @@ 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 'replaces lrint by lrintf'), and why (for example '*BSD isn't C99 compliant
and has no lrint()') and has no lrint()')
Also please if you send several patches, send each patch as seperate mail, Also please if you send several patches, send each patch as separate mail,
dont attach several unrelated patches to the same mail. do not attach several unrelated patches to the same mail.
@section patch submission checklist @section patch submission checklist
@ -1637,11 +1637,11 @@ dont attach several unrelated patches to the same mail.
(the list is subscribers only due to spam) (the list is subscribers only due to spam)
@item @item
Have you checked that the changes are minimal, so that the same cannot be Have you checked that the changes are minimal, so that the same cannot be
achived with a smaller patch and/or simpler final code? achieved with a smaller patch and/or simpler final code?
@item @item
If the change is to speed critical code did you benchmark it? If the change is to speed critical code did you benchmark it?
@item @item
Have you checked that the patch does not intruduce buffer overflows or Have you checked that the patch does not introduce buffer overflows or
other security issues? other security issues?
@item @item
Is the patch made from the root of the source, so it can be applied with -p0? Is the patch made from the root of the source, so it can be applied with -p0?
@ -1654,14 +1654,14 @@ dont attach several unrelated patches to the same mail.
@item @item
If the patch fixes a bug did you provide a verbose analysis of the bug? If the patch fixes a bug did you provide a verbose analysis of the bug?
@item @item
If the patch fixes a bug did you provide enough information including If the patch fixes a bug did you provide enough information, including
a sample, so the bug can be reproduced and the fix can be verified? a sample, so the bug can be reproduced and the fix can be verified?
@item @item
Did you provide a verbose summary about what the patch does change? Did you provide a verbose summary about what the patch does change?
@item @item
Did you provide a verbose explanation why it changes things like it does? Did you provide a verbose explanation why it changes things like it does?
@item @item
Did you provide a verbose summary of the user vissible advantages and Did you provide a verbose summary of the user visible advantages and
disadvantages if the patch is applied? disadvantages if the patch is applied?
@item @item
Did you provide an example so we can verify the new feature added by the Did you provide an example so we can verify the new feature added by the
@ -1676,7 +1676,7 @@ All patches posted to ffmpeg-devel will be reviewed, unless they contain a
clear note that the patch is not for SVN. clear note that the patch is not for SVN.
Reviews and comments will be posted as replies to the patch on the 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, mailing list. The patch submitter then has to take care of every comment,
that can be by resubmitting a changed patch or by disscussion. Resubmitted that can be by resubmitting a changed patch or by discussion. Resubmitted
patches will themselves be reviewed like any other patch. If at some point patches will themselves be reviewed like any other patch. If at some point
a patch passes review with no comments then it is approved, that can for a patch passes review with no comments then it is approved, that can for
simple and small patches happen immediately while large patches will generally simple and small patches happen immediately while large patches will generally