From 37978d75e752f98c5b3aa516e99f40e12a077e83 Mon Sep 17 00:00:00 2001 From: hniksic Date: Mon, 6 Nov 2000 02:56:49 -0800 Subject: [PATCH] [svn] New file. --- PATCHES | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 PATCHES diff --git a/PATCHES b/PATCHES new file mode 100644 index 00000000..0057605b --- /dev/null +++ b/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 +. 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 +. 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.