@c For double-sided printing, uncomment:
@c @setchapternewpage odd
@c This date is automagically updated when you save this file:
-@set lastupdate September 5, 2011
+@set lastupdate December 2, 2011
@c %**end of header
@dircategory GNU organization
papers to sign. The @file{request-} file also raises the issue of
getting an employer's disclaimer from the contributor's employer.
-When the contributor emails the form to the FSF, the FSF sends per
-papers to sign. If person signs them right away, the whole process
-takes a couple of weeks---mostly waiting for letters to go back and
-forth.
+When the contributor emails the form to the FSF, the FSF sends per an
+electronic (usually PDF) copy of the assignment. All contributors
+then print the assignment and sign it. Contributors residing outside
+the U.S. must mail the signed form to the FSF via the post.
+Contributors located in the U.S. can then email or fax a scanned copy
+back to the FSF (or use postal mail, if they prefer). (To emphasize,
+the necessary distinction is between US residents and non-residents,
+citizenship does not matter.)
For less common cases, we have template files you should send to the
contributor. Be sure to fill in the name of the person and the name
automatically, if you are careful about the formatting of the change
log entries.
+It is ok to include other email addresses, names, and program
+information in @file{AUTHORS}, such as bug-reporting information.
+@xref{Standard Mailing Lists}.
+
+
@node Copying from Other Packages
@section Copying from Other Packages
advertised bug-reporting email address should always be
@samp{bug-@var{package}@@gnu.org}, to help show users that the program
is a GNU package, but it is ok to set up that list to forward to another
-site if you prefer. The package distribution should state the
-name of the bug-reporting list in a prominent place, and ask users to
-help us by reporting bugs there.
+site if you prefer.
@cindex @email{bug-gnu-utils@@gnu.org}
We also have a catch-all list, @email{bug-gnu-utils@@gnu.org}, which is
nowadays we want to give each program its own bug-reporting list and
move away from using @email{bug-gnu-utils}.
+@xref{Replying to Mail}, for more about handling and tracking bug
+reports.
+
@cindex help for users, mailing list for
Some GNU programs with many users have another mailing list,
@samp{help-@var{package}.org}, for people to ask other users for help.
@cindex announcements, mailing list for
If you wish, you can also have a mailing list
-@samp{info-@var{package}} for announcements (@pxref{Announcements}),
-and any others you find useful.
+@samp{info-@var{package}} for announcements (@pxref{Announcements}).
+Any other mailing lists you find useful can also be created.
+
+The package distribution should state the name of all the package's
+mailing lists in a prominent place, and ask users to help us by
+reporting bugs appropriately. The top-level @file{README} file and/or
+@file{AUTHORS} file are good places. Mailing list information should
+also be included in the manual and the package web pages (@pxref{Web
+Pages}).
+
@node Creating Mailing Lists
to make bug reports useful. Copying and adapting that could be very
useful for your package.
+@cindex @url{http://bugs.gnu.org}
+@cindex bug reports, email tracker for
+@cindex bug reports, web tracker for
+If you would like to use an email-based bug tracking system, see
+@url{http://bugs.gnu.org}; this can be connected with the regular
+bug-reporting address. Alternatively, if you would like to use a
+web-based bug tracking system, Savannah supports this (@pxref{Old
+Versions}), but please don't fail to accept bugs by regular email as
+well---we don't want to put up unnecessary barriers against users
+submitting reports.
+
@node Old Versions
@chapter Recording Old Versions
@cindex time stamp in diffs
If you use GNU @code{diff} to make the patch, use the options
@samp{-rc2P}. That will put any new files into the output as ``entirely
-different.'' Also, the patch's context diff headers should have dates
+different''. Also, the patch's context diff headers should have dates
and times in Universal Time using traditional Unix format, so that patch
recipients can use GNU @code{patch}'s @samp{-Z} option. For example,
you could use the following Bourne shell command to create the patch:
subdirectory named after the package, and all the distribution files
for the package should go in that subdirectory.
-@c If you have an interest in seeing the monthly download logs from the FTP
-@c site at @code{ftp.gnu.org} for your program, that is something that
-@c @email{ftp-upload@@gnu.org} can set up for you. Please contact them if
-@c you are interested.
-
@xref{Automated FTP Uploads}, for procedural details of putting new
versions on @code{ftp.gnu.org}.
@item
Compose a message with the following items in some @var{msgfile}.
Then GPG-sign it by running @code{gpg --clearsign @var{msgfile}}, and
-finally email the resulting @file{@var{msgfile}.asc}), to
+finally email the resulting @file{@var{msgfile}.asc} to
@email{ftp-upload@@gnu.org}.
@enumerate
command line @code{ftp}.
If you have difficulties with an upload, email
-@email{ftp-upload@@gnu.org}.
+@email{ftp-upload@@gnu.org}. You can check the archive of uploads
+processed at
+@url{https://lists.gnu.org/archive/html/ftp-upload-report}.
@node FTP Upload Directive File - v1.1
@end smallexample
@noindent where @var{yourmanual} is the short name for your package
-and @var{yourbuglist} is the email address for bug reports (typically
-@code{bug-@var{package}@@gnu.org}). The script processes the file
-@file{@var{yourmanual}.texinfo} (or @file{.texi} or @file{.txi}). For
-example:
+and @var{yourbuglist} is the email address for bug reports (which
+should be @code{bug-@var{package}@@gnu.org}). The script processes
+the file @file{@var{yourmanual}.texinfo} (or @file{.texi} or
+@file{.txi}). For example:
@smallexample
-cd .../emacs/man
+cd .../texinfo/doc
# download gendocs.sh and gendocs_template
-gendocs.sh --email bug-gnu-emacs@@gnu.org emacs "GNU Emacs manual"
+gendocs.sh --email bug-texinfo@@gnu.org texinfo "GNU Texinfo manual"
@end smallexample
@command{gendocs.sh} creates a subdirectory @file{manual/} containing
precisely, they know about it, but don't realize it is the GNU Project's
accomplishment and reason for existence. Even people who believe they
know the real history often believe that the goal of GNU was to develop
-``tools'' or ``utilities.''
+``tools'' or ``utilities''.
To correct this confusion, we have made a years-long effort to
distinguish between Linux, the kernel that Linus Torvalds wrote, and
@url{http://www.gnu.org/gnu/linux-and-gnu.html}.
To contrast the GNU system properly with respect to GNU/Linux, you can
-call it ``GNU/Hurd'' or ``the GNU/Hurd system.'' However, when that
+call it ``GNU/Hurd'' or ``the GNU/Hurd system''. However, when that
contrast is not specifically the focus, please call it just ``GNU'' or
-``the GNU system.''
+``the GNU system''.
When referring to the collection of servers that is the higher level
-of the GNU kernel, please call it ``the Hurd'' or ``the GNU Hurd.''
+of the GNU kernel, please call it ``the Hurd'' or ``the GNU Hurd''.
Note that this uses a space, not a slash.
projects / gnulib.git / blobdiff