Automated merge.

2024-07-03 16:38:41 -04:00 · 2007-10-13 02:04:14 -07:00 · 2007-10-13 02:04:14 -07:00 · 787ffba182
commit 787ffba182
parent fbe701ce28 289b9674c0
6 changed files with 50 additions and 209 deletions
--- a/6
+++ b/6
@ -1,3 +1,9 @@
 2007-10-12  Micah Cowan  <micah@cowan.name>
 	* PATCHES: Removed.
 	* NEWS: Updated info about source repositories, removal of
 	PATCHES file.
 2007-10-09  Micah Cowan  <micah@cowan.name>
 	* configure.in: Renamed to configure.ac
--- a/71
+++ b/71
@ -1,48 +1,33 @@
-                                                                -*- text -*-
+Mailing List
 ================
-		      WGET-RELATED MAILING LISTS
+There are several Wget-related mailing lists.  The general discussion
 list is at <wget@sunsite.dk>.  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
+   To subscribe, simply send mail to <wget-subscribe@sunsite.dk> and
-hosted by dotsrc.org, previously known as SunSITE.dk.
+follow the instructions.  Unsubscribe by mailing to
 <wget-unsubscribe@sunsite.dk>.  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 <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 `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
+   Subscription is the same as above for <wget@sunsite.dk>, except that
-    place to post bug reports and suggestions, as well as discuss
+you send to <wget-patches-subscribe@sunsite.dk>, instead.  The mailing
-    development-related matters.
+list is archived at `http://news.gmane.org/gmane.comp.web.wget.patches'.
-    To post to the list, send mail to <wget@sunsite.dk>.  To
+   Finally, there is the <wget-notify@addictivecode.org> mailing list.
-    subscribe, send mail to <wget-subscribe@sunsite.dk>.
+This is a non-discussion list that receives commit notifications from
-
+the source repository, and also bug report-change notifications.  This
-    NOTE: The list allows posts from non-subscribers.  This is
+is the highest-traffic list for Wget, and is recommended only for
-    intentional; I hate having to subscribe to a list only to ask a
+people who are seriously interested in ongoing Wget development.
-    single question.  However, to protect the list members from spam,
+Subscription is through the `mailman' interface at
-    non-subscribers must confirm messages they send to the list.
+`http://addictivecode.org/mailman/listinfo/wget-notify'.
    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
    <wget-patches-subscribe@sunsite.dk>.
    The list is archived at:
        http://news.gmane.org/gmane.comp.web.wget.patches
 As of this writing, the mail alias <bug-wget@gnu.org> is an alias for
 <wget@sunsite.dk>.
--- a/14
+++ b/14
@ -12,6 +12,15 @@ Please send GNU Wget bug reports to <bug-wget@gnu.org>.
 * 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.
--- a/160
+++ b/160
@ -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
 <wget-patches@sunsite.dk>.  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 <wget@sunsite.dk>.
 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
 <http://www.gnu.org/software/wget/> 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.
--- a/doc/ChangeLog
+++ b/doc/ChangeLog
@ -1,3 +1,8 @@
 2007-10-13  Micah Cowan  <micah@cowan.name>
 	* wget.texi <Mailing Lists>: Replaced mention of no-longer
 	included PATCHES file with link to relevant Wgiki page.
 2007-10-10  Micah Cowan  <micah@cowan.name>
 	* wget.texi <Wgetrc Commands>: Fixed "doewnloads" typo.
--- 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.