From 442d1598a3bcd170db9229384edcb4a782758087 Mon Sep 17 00:00:00 2001 From: Reimar Döffinger Date: Tue, 17 Apr 2007 14:06:08 +0000 Subject: Fix the most obvious typos in the development policy doc section Originally committed as revision 8746 to svn://svn.ffmpeg.org/ffmpeg/trunk --- doc/ffmpeg-doc.texi | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/ffmpeg-doc.texi b/doc/ffmpeg-doc.texi index 52460492cd..a33ab56caf 100644 --- a/doc/ffmpeg-doc.texi +++ b/doc/ffmpeg-doc.texi @@ -1509,7 +1509,7 @@ please use av_log() instead. understanding them on the commit log mailing list easier. This also helps in case of debugging later on. 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 Do not change behavior of the program (renaming options etc) without 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 and has no lrint()') -Also please if you send several patches, send each patch as seperate mail, -dont attach several unrelated patches to the same mail. +Also please if you send several patches, send each patch as separate mail, +do not attach several unrelated patches to the same mail. @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) @item 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 If the change is to speed critical code did you benchmark it? @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? @item 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 If the patch fixes a bug did you provide a verbose analysis of the bug? @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? @item Did you provide a verbose summary about what the patch does change? @item Did you provide a verbose explanation why it changes things like it does? @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? @item 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. 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 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 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 -- cgit v1.2.3