sjero.net Git - wget/blob - PATCHES

   1 * Guidelines for patch submissions
   2 ==================================
   3
   4 ** Where to send the patches.
   5
   6 Patches intended to be applied to Wget should be mailed to
   7 <wget-patches@sunsite.auc.dk>.  Each patch will be reviewed by the
   8 developers, and will be acked and added to the distribution, or
   9 rejected with an explanation.
  10
  11 If you want to discuss your patch with the community of Wget users and
  12 developers, it is OK to send it to the general list at
  13 <wget@sunsite.auc.dk>.  If the patch is really large (more than 100K),
  14 you may want to put it on the web and post the URL.
  15
  16 If your mail composer or gateway is inclined to munge patches, e.g. by
  17 line-wrapping them, send them out as a MIME attachment.  Otherwise,
  18 patches simply inserted into an email message are fine.
  19
  20 ** How to create patches.
  21
  22 Patches are created using the `diff' utility.  When making patches,
  23 please use the `-u' option, or if your diff doesn't support it, `-c'.
  24 Using ordinary (context-free) diffs are notoriously prone to error,
  25 since line numbers tend to change when others make changes to the same
  26 source file.
  27
  28 An example of the `diff' usage:
  29
  30     diff -u OLDFILE NEWFILE
  31
  32 -or-
  33
  34     diff -c OLDFILE NEWFILE
  35
  36 Also, it is helpful if you create the patch in the top level of
  37 the Wget source directory:
  38
  39 $ cp -p src/http.c src/http.c.orig
  40 ...hack, hack, hack....
  41 $ diff -u src/http.c.orig src/http.c
  42
  43 If your patch changes more than one file, the output of all the diff
  44 invocations should be concatenated to form a single patch.
  45 Alternatively, you can use the `-r' option to compare entire
  46 directories.  If you do that, be careful not to include the
  47 differences to automatically generated files, such as `.info*'.
  48
  49 If you run on Windows and don't have `diff' handy, please get one.
  50 It's extremely hard to review changes to files unless they're in the
  51 form of a patch.  If you really cannot use a variant of `diff', then
  52 mail us the whole new file and specify which version of Wget you
  53 changed; that way we will be able to generate the diff ourselves.
  54
  55 ** Standards and coding style.
  56
  57 Wget abides by the GNU coding standards, available at:
  58
  59     http://www.gnu.org/prep/standards.html
  60
  61 The most important point in that entire document is "no arbitrary
  62 limits".  Even when Wget's coding is less than exemplary, it respects
  63 that rule.  There should be no exceptions.
  64
  65 Here is a short recap of the indentation/naming rules, borrowed from
  66 XEmacs:
  67
  68 -- Put a space after every comma.
  69 -- Put a space before the parenthesis that begins a function call,
  70    macro call, function declaration or definition, or control
  71    statement (if, while, switch, for). (DO NOT do this for macro
  72    definitions; this is invalid preprocessor syntax.)
  73 -- The brace that begins a control statement (if, while, for, switch,
  74    do) or a function definition should go on a line by itself.
  75 -- In function definitions, put the return type and all other
  76    qualifiers on a line before the function name.  Thus, the function
  77    name is always at the beginning of a line.
  78 -- Indentation level is two spaces.  (However, the first and following
  79    statements of a while/for/if/etc. block are indented four spaces
  80    from the while/for/if keyword.  The opening and closing braces are
  81    indented two spaces.)
  82 -- Variable and function names should be all lowercase, with
  83    underscores separating words, except for a prefixing tag, which may
  84    be in uppercase.  Do not use the mixed-case convention (e.g.
  85    SetVariableToValue ()) and *especially* do not use Microsoft
  86    Hungarian notation (char **rgszRedundantTag).
  87 -- preprocessor and enum constants should be all uppercase, and should
  88    be prefixed with a tag that groups related constants together.
  89
  90 ** ChangeLog policy.
  91
  92 Each patch should be accompanied by an update to the appropriate
  93 ChangeLog file.  Please don't mail patches to ChangeLog because they
  94 have an extremely high rate of failure; just mail us the new part of
  95 the ChangeLog you added.  Patches without a ChangeLog entry will be
  96 accepted, but this creates additional work for the maintainers, so
  97 please do write the ChangeLog entries.
  98
  99 Guidelines for writing ChangeLog entries are also governed by the GNU
 100 coding standards, under the "Change Logs" section.