Revision 442d1598 doc/ffmpeg-doc.texi

View differences:

doc/ffmpeg-doc.texi
1509 1509
   understanding them on the commit log mailing list easier. This also helps
1510 1510
   in case of debugging later on.
1511 1511
   Also if you have doubts about splitting or not splitting, do not hesitate to
1512
   ask/disscuss it on the developer mailing list.
1512
   ask/discuss it on the developer mailing list.
1513 1513
@item
1514 1514
   Do not change behavior of the program (renaming options etc) without
1515 1515
   first discussing it on the ffmpeg-devel mailing list. Do not remove
......
1620 1620
'replaces lrint by lrintf'), and why (for example '*BSD isn't C99 compliant
1621 1621
and has no lrint()')
1622 1622

  
1623
Also please if you send several patches, send each patch as seperate mail,
1624
dont attach several unrelated patches to the same mail.
1623
Also please if you send several patches, send each patch as separate mail,
1624
do not attach several unrelated patches to the same mail.
1625 1625

  
1626 1626
@section patch submission checklist
1627 1627

  
......
1637 1637
    (the list is subscribers only due to spam)
1638 1638
@item
1639 1639
    Have you checked that the changes are minimal, so that the same cannot be
1640
    achived with a smaller patch and/or simpler final code?
1640
    achieved with a smaller patch and/or simpler final code?
1641 1641
@item
1642 1642
    If the change is to speed critical code did you benchmark it?
1643 1643
@item
1644
    Have you checked that the patch does not intruduce buffer overflows or
1644
    Have you checked that the patch does not introduce buffer overflows or
1645 1645
    other security issues?
1646 1646
@item
1647 1647
    Is the patch made from the root of the source, so it can be applied with -p0?
......
1654 1654
@item
1655 1655
    If the patch fixes a bug did you provide a verbose analysis of the bug?
1656 1656
@item
1657
    If the patch fixes a bug did you provide enough information including
1657
    If the patch fixes a bug did you provide enough information, including
1658 1658
    a sample, so the bug can be reproduced and the fix can be verified?
1659 1659
@item
1660 1660
    Did you provide a verbose summary about what the patch does change?
1661 1661
@item
1662 1662
    Did you provide a verbose explanation why it changes things like it does?
1663 1663
@item
1664
    Did you provide a verbose summary of the user vissible advantages and
1664
    Did you provide a verbose summary of the user visible advantages and
1665 1665
    disadvantages if the patch is applied?
1666 1666
@item
1667 1667
    Did you provide an example so we can verify the new feature added by the
......
1676 1676
clear note that the patch is not for SVN.
1677 1677
Reviews and comments will be posted as replies to the patch on the
1678 1678
mailing list. The patch submitter then has to take care of every comment,
1679
that can be by resubmitting a changed patch or by disscussion. Resubmitted
1679
that can be by resubmitting a changed patch or by discussion. Resubmitted
1680 1680
patches will themselves be reviewed like any other patch. If at some point
1681 1681
a patch passes review with no comments then it is approved, that can for
1682 1682
simple and small patches happen immediately while large patches will generally

Also available in: Unified diff