Changes between Initial Version and Version 1 of SubmittingPatches


Ignore:
Timestamp:
Feb 18, 2012 4:56:42 AM (6 years ago)
Author:
rado
Comment:

migrate wiki.mutt.org

Legend:

Unmodified
Added
Removed
Modified
  • SubmittingPatches

    v1 v1  
     1= Basic Requirements =
     2
     3Please follow the CodingStyle for the project, including proper indentation.
     4
     5Give your patch a filename using the convention: patch-''version''.''initials''.''description''.''revision''
     6where ''version'' is the Mutt version the patch is targetted at, ''initials'' are the initials (first and last) for your name, ''description'' is a short (two words at the max) title for the patch (use underscores if needed), and ''revision'' is the version of the patch starting at 1.
     7
     8An example of the above is ''patch-1.5.1.me.long_qp.1''. Put this into the file PATCHES in the Mutt source code before running diff, so it gets included. The output will look similar to this:
     9 --- PATCHES~    Tue Nov  6 19:59:33 2001
     10 +++ PATCHES     Tue Nov  6 19:59:42 2001
     11 @@ -1,0 +1 @@
     12 +patch-1.5.1.me.long_qp.1
     13This information gets included in the ''mutt -v'' output so that when users complain about bugs, we know who to blame.  :-)
     14
     15= Code Requirements =
     16
     17== Safety Functions ==
     18
     19Mutt contains a number of safety wrappers around standard library functions. Their use can be tested and verified by running the following script from the top-level source directory:
     20
     21 ./check_sec.sh
     22
     23It will run some basic security checks and prints warnings you should fix prior to submitting the patch; a committer will run these checks anyway so ensuring your patch is okay may prevent it from being rejected due to such "violations".
     24
     25A list of insecure or (under certain conditions) problematic functions can be obtained with:
     26
     27 $ grep safe_ lib.h
     28
     29Note that a patch may get rejected if their standard library "equivalents" are used.
     30
     31== safe_free() vs. FREE() ==
     32
     33Mutt contains a safe_free() wrapper for the ordinary free() and a macro around safe_free() named FREE(). To avoid compiler warnings, the safe_free() function though declared as:
     34
     35 safe_free (void* pointer);
     36
     37expects "void**", not "void*" and dereferences its argument. The direct usage hence requires some care so that the FREE() macro was introduced. It is to be used as this:
     38
     39 char* foo = ...
     40 FREE (&foo);
     41
     42so that the check_sec.sh script can properly test whether FREE() gets "void**" instead of "void*".
     43
     44When hacking on mutt (especially for the first time), please double-check the use of FREE() and avoid safe_free().
     45
     46= Submission =
     47
     48Unified diffs (diff -u) are easier to read for those reviewing the patches.  If you are using Mercurial
     49
     50 hg diff
     51
     52will give you a recursive diff of all files that you have changed.
     53
     54Send your patch to mutt-dev@mutt.org.  Prefix the subject of the message with '''[PATCH]''' so that it is easily identifiable in a list of messages.
     55
     56If your patch doesn't get included in vanilla mutt, you might consider adding a pointer to your patch on the PatchList page so others can find it.