diff --git a/ChangeLog b/ChangeLog index 4cb4b281..0eb978b6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2007-10-12 Micah Cowan + + * PATCHES: Removed. + * NEWS: Updated info about source repositories, removal of + PATCHES file. + 2007-10-09 Micah Cowan * configure.in: Renamed to configure.ac diff --git a/MAILING-LIST b/MAILING-LIST index 1268cf8e..bab1629c 100644 --- a/MAILING-LIST +++ b/MAILING-LIST @@ -1,48 +1,33 @@ - -*- text -*- +Mailing List +================ - WGET-RELATED MAILING LISTS +There are several Wget-related mailing lists. The general discussion +list is at . It is the preferred place for support +requests and suggestions, as well as for discussion of development. +You are invited to subscribe. -There are several mailing lists related to GNU Wget, all of them -hosted by dotsrc.org, previously known as SunSITE.dk. + To subscribe, simply send mail to and +follow the instructions. Unsubscribe by mailing to +. The mailing list is archived at +`http://www.mail-archive.com/wget%40sunsite.dk/' and at +`http://news.gmane.org/gmane.comp.web.wget.general'. -wget@sunsite.dk: + Another mailing list is at , and is used to +submit patches for review by Wget developers. A "patch" is a textual +representation of change to source code, readable by both humans and +programs. The file `PATCHES' that comes with Wget covers the creation +and submitting of patches in detail. Please don't send general +suggestions or bug reports to `wget-patches'; use it only for patch +submissions. - The mailing list for users and developers. This is the preferred - place to post bug reports and suggestions, as well as discuss - development-related matters. + Subscription is the same as above for , except that +you send to , instead. The mailing +list is archived at `http://news.gmane.org/gmane.comp.web.wget.patches'. - To post to the list, send mail to . To - subscribe, send mail to . - - NOTE: The list allows posts from non-subscribers. This is - intentional; I hate having to subscribe to a list only to ask a - single question. However, to protect the list members from spam, - non-subscribers must confirm messages they send to the list. - - If you're not subscribed to the list and ask something, don't - forget to request that the responses be Cc'ed to you. - - The list is archived at: - - http://www.mail-archive.com/wget%40sunsite.dk/ - http://news.gmane.org/gmane.comp.web.wget.general - -wget-patches@sunsite.dk: - - The mailing list for patch submission. Please see the PATCHES - file for a detailed description of how to send patches to this - list. - - This is list is also open to non-subscribers, but it is *not* a - discussion list. It only ever distribute patches and immediate - responses to a patch. If you wish to take very active part in - development, you might wish to subscribe to it anyway, and receive - the new patches. To do that, send mail to - . - - The list is archived at: - - http://news.gmane.org/gmane.comp.web.wget.patches - -As of this writing, the mail alias is an alias for -. + Finally, there is the mailing list. +This is a non-discussion list that receives commit notifications from +the source repository, and also bug report-change notifications. This +is the highest-traffic list for Wget, and is recommended only for +people who are seriously interested in ongoing Wget development. +Subscription is through the `mailman' interface at +`http://addictivecode.org/mailman/listinfo/wget-notify'. diff --git a/NEWS b/NEWS index e7c854d6..77faebe0 100644 --- a/NEWS +++ b/NEWS @@ -12,6 +12,15 @@ Please send GNU Wget bug reports to . * Changes in Wget 1.11. +** The source code has been migrated to Mercurial. The repositories are +available at http://hg.addictivecode.org/. Prior to this, the source +code was hosted on Subversion (migrated from the original CVS); you can +still get access to older tags and branches for Wget in the Subversion +repository at http://addictivecode.org/svn/wget/. + +** PATCH file removed; see http://wget.addictivecode.org/PatchGuidelines +for current information about producing patches for GNU Wget. + ** TODO file removed: we use a bugtracker now; see http://wget.addictivecode.org/BugTracker. Also, http://wget.addictivecode.org/FeatureSpecifications. @@ -65,11 +74,6 @@ was only used by the passive_ftp .wgetrc setting. If you're running broken scripts or Perl modules that unconditionally specify `--passive-ftp' and your firewall disallows it, you can override them by replacing wget with a script that execs wget "$@" --no-passive-ftp. - -** The source code has migrated from CVS to Subversion. The -repository is available at http://svn.dotsrc.org/repo/wget/; to -checkout the trunk to a directory named `wget', use something like -`svn checkout http://svn.dotsrc.org/repo/wget/trunk/ wget'. * Changes in Wget 1.10. diff --git a/PATCHES b/PATCHES deleted file mode 100644 index b5bb1f61..00000000 --- a/PATCHES +++ /dev/null @@ -1,160 +0,0 @@ -* Guidelines for patch submissions. -=================================== - -** What is a patch? -------------------- - -A patch file, also known as a "diff", is a textual representation of -changes to source code. Patches are readable enough to be reviewed by -humans and at the same time regular enough to be processed by -programs. The `patch' utility is used to change the source code in -the manner that the patch describes, this being called "applying" the -patch. Patches work even on files that have been modified -independently of the modifications in the patch, as long as those -other changes do not conflict with the patch. - -Because of these properties, patches are the preferred means of -distributing the changes to a free software project. If you have made -a change to Wget and would like to contribute it, you will need to -create a patch and send it to the developers; please read on. - -** 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. Unfortunately, the developers are often -busy with their day jobs, so the review process can take a while. - -If you want to discuss your patch with the community of Wget users and -developers, it is OK to send it to the main list at . -If the patch is really huge (more than 100K or so), you may want to -put it on the web and post the URL. - -EVERY patch should be accompanied by an explanation of what the patch -changes, and why the change is desirable or necessary. The -explanation need not be long, but please don't just send a patch -without any accompanying text. - -Normally, a patch can be just inserted into the message, after the -explanation and the ChangeLog entry. However, if your mail composer -or gateway is inclined to munge patches, e.g. by wrapping long lines, -please send them out as a MIME attachment. It is important that the -patch survives the travel unchanged so that we can feed it to the -`patch' utility after reviewing it. - -** How to create patches. -------------------------- - -First, please make sure that you are working with the latest version -of the source -- changing obsolete code is a waste of time. Working -on the latest release is acceptable in most cases, but it is better -yet to download the very latest sources from the public Subversionn -server and work on those. The web page at - explains how to get the source -code from the repository. - -Patches are created using the `diff' program. When making patches, -please use the `-u' option, or if your diff doesn't support it, `-c'. -Ordinary (context-free) diffs are notoriously prone to errors, since -line numbers tend to change when others make changes to the same -source file. - -In the general case, `diff' is used like this: - - diff -u ORIGFILE CHANGEDFILE > patch.txt - -Also, it is helpful if you create the patch in the top level of -the Wget source directory. For example: - - cp src/http.c src/http.c.orig - ... modify src/http.c .... - diff -u src/http.c.orig src/http.c > patch.txt - -If your patch changes more than one file, feel free to simply -concatenate the diffs of different files into a large diff: - - (diff -u foo.orig foo; diff -u bar.orig bar) > patch.txt - -The alternative is to leave the unchanged source lying around and use -the `-r' option to compare entire directories: - - diff -ru wget-1.9.orig wget-1.9 > patch.txt - -If you do that, please be careful not to include the differences to -automatically generated files, such as `.info*'. - -If you are using Subversion, generating diffs is even simpler -- after -changing the files, all you need to do is run the following command -from Wget's top-level directory: - - svn diff > patch.txt - -If you run on Windows and don't have `diff' handy, please obtain it. -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 indicate which version of Wget you -changed; that way we will be able to generate the diff ourselves. - -Finally, if your changes introduce new files, or if they change the -old files past all recognition (e.g. by completely reimplementing the -old stuff), sending a patch might not make sense. In that case, just -attach the files along with an explanation of what is being changed. - -** Standards and coding style. ------------------------------- - -Wget abides by the GNU coding standards, available at: - - http://www.gnu.org/prep/standards.html - -I consider perhaps the most important single point in that entire -document to be the "no arbitrary limits" rule. Even where Wget's -coding is less than exemplary, it respects that rule. There should be -no exceptions. - -Here is a short recap of the GNU formatting and naming conventions, -partly 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 constants and enumerations 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 diffs of ChangeLog files because -they have an extremely high rate of failure; just mail us the new -entries you added to the ChangeLog. Patches without a ChangeLog entry -will be accepted, but this creates additional work for the -maintainers, so please do take the time to write one. - -Guidelines for writing ChangeLog entries are also governed by the GNU -coding standards, under the "Change Logs" section. diff --git a/doc/ChangeLog b/doc/ChangeLog index 42ae9897..daa7006a 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -1,3 +1,8 @@ +2007-10-13 Micah Cowan + + * wget.texi : Replaced mention of no-longer + included PATCHES file with link to relevant Wgiki page. + 2007-10-10 Micah Cowan * wget.texi : Fixed "doewnloads" typo. diff --git a/doc/wget.texi b/doc/wget.texi index 32f59807..967604c4 100644 --- a/doc/wget.texi +++ b/doc/wget.texi @@ -3315,7 +3315,8 @@ and follow the instructions. Unsubscribe by mailing to Another mailing list is at @email{wget-patches@@sunsite.dk}, and is used to submit patches for review by Wget developers. A ``patch'' is a textual representation of change to source code, readable by both -humans and programs. The file @file{PATCHES} that comes with Wget +humans and programs. The +@url{http://wget.addictivecode.org/PatchGuidelines} page covers the creation and submitting of patches in detail. Please don't send general suggestions or bug reports to @samp{wget-patches}; use it only for patch submissions.