[svn] New file.

PATCHES

@@ -0,0 +1,100 @@
+* Guidelines for patch submissions
+==================================
+
+** Where to send the patches.
+
+Patches intended to be applied to Wget should be mailed to
+<wget-patches@sunsite.auc.dk>.  Each patch will be reviewed by the
+developers, and will be acked and added to the distribution, or
+rejected with an explanation.
+
+If you want to discuss your patch with the community of Wget users and
+developers, it is OK to send it to the general list at
+<wget@sunsite.auc.dk>.  If the patch is really large (more than 100K),
+you may want to put it on the web and post the URL.
+
+If your mail composer or gateway is inclined to munge patches, e.g. by
+line-wrapping them, send them out as a MIME attachment.  Otherwise,
+patches simply inserted into an email message are fine.
+
+** How to create patches.
+
+Patches are created using the `diff' utility.  When making patches,
+please use the `-u' option, or if your diff doesn't support it, `-c'.
+Using ordinary (context-free) diffs are notoriously prone to error,
+since line numbers tend to change when others make changes to the same
+source file.
+
+An example of the `diff' usage:
+
+    diff -u OLDFILE NEWFILE
+
+-or-
+
+    diff -c OLDFILE NEWFILE
+
+Also, it is helpful if you create the patch in the top level of
+the Wget source directory:
+
+$ cp -p src/http.c src/http.c.orig
+...hack, hack, hack....
+$ diff -u src/http.c.orig src/http.c
+
+If your patch changes more than one file, the output of all the diff
+invocations should be concatenated to form a single patch.
+Alternatively, you can use the `-r' option to compare entire
+directories.  If you do that, be careful not to include the
+differences to automatically generated files, such as `.info*'.
+
+If you run on Windows and don't have `diff' handy, please get one.
+It's extremely hard to review changes to files unless they're in the
+form of a patch.  If you really cannot use a variant of `diff', then
+mail us the whole new file and specify which version of Wget you
+changed; that way we will be able to generate the diff ourselves.
+
+** Standards and coding style.
+
+Wget abides by the GNU coding standards, available at:
+
+    http://www.gnu.org/prep/standards.html
+
+The most important point in that entire document is "no arbitrary
+limits".  Even when Wget's coding is less than exemplary, it respects
+that rule.  There should be no exceptions.
+
+Here is a short recap of the indentation/naming rules, borrowed from
+XEmacs:
+
+-- Put a space after every comma.
+-- Put a space before the parenthesis that begins a function call,
+   macro call, function declaration or definition, or control
+   statement (if, while, switch, for). (DO NOT do this for macro
+   definitions; this is invalid preprocessor syntax.)
+-- The brace that begins a control statement (if, while, for, switch,
+   do) or a function definition should go on a line by itself.
+-- In function definitions, put the return type and all other
+   qualifiers on a line before the function name.  Thus, the function
+   name is always at the beginning of a line.
+-- Indentation level is two spaces.  (However, the first and following
+   statements of a while/for/if/etc. block are indented four spaces
+   from the while/for/if keyword.  The opening and closing braces are
+   indented two spaces.)
+-- Variable and function names should be all lowercase, with
+   underscores separating words, except for a prefixing tag, which may
+   be in uppercase.  Do not use the mixed-case convention (e.g.
+   SetVariableToValue ()) and *especially* do not use Microsoft
+   Hungarian notation (char **rgszRedundantTag).
+-- preprocessor and enum constants should be all uppercase, and should
+   be prefixed with a tag that groups related constants together.
+
+** ChangeLog policy.
+
+Each patch should be accompanied by an update to the appropriate
+ChangeLog file.  Please don't mail patches to ChangeLog because they
+have an extremely high rate of failure; just mail us the new part of
+the ChangeLog you added.  Patches without a ChangeLog entry will be
+accepted, but this creates additional work for the maintainers, so
+please do write the ChangeLog entries.
+
+Guidelines for writing ChangeLog entries are also governed by the GNU
+coding standards, under the "Change Logs" section.