@c For double-sided printing, uncomment:
@c @setchapternewpage odd
@c This date is automagically updated when you save this file:
-@set lastupdate June 30, 2011
+@set lastupdate March 20, 2012
@c %**end of header
@dircategory GNU organization
Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
-2010, 2011 Free Software Foundation, Inc.
+2010, 2011, 2012 Free Software Foundation, Inc.
@quotation
Permission is granted to copy, distribute and/or modify this document
@menu
* Preface::
* Getting Help::
-* Getting a GNU Account::
+* GNU Accounts and Resources::
* Stepping Down::
* Recruiting Developers::
* Legal Matters::
Standards (@pxref{Top, , Contents, standards, GNU Coding Standards}).
@cindex @code{bug-standards@@gnu.org} email address
-@cindex Savannah repository for gnustandards
-@cindex gnustandards project repository
+@cindex Savannah repository for @code{gnustandards}
+@cindex @code{gnustandards} project repository
Please send corrections or suggestions for this document to
@email{bug-standards@@gnu.org}. If you make a suggestion, please
include suggested new wording if you can. We prefer a context diff to
try not to burden them unnecessarily.
-@node Getting a GNU Account
-@chapter Getting a GNU Account
+@node GNU Accounts and Resources
+@chapter GNU Accounts and Resources
@cindex shell account, on fencepost
-@cindex @code{fencepost.gnu.org} GNU machine
+@cindex @code{fencepost.gnu.org} GNU login host
+@cindex resources for GNU developers
+@cindex development resources
@c We want to repeat this text later, so define a macro.
@macro gdgnuorgtext
@gdgnuorgtext{}
+Other resources available to GNU maintainers are described at
+@url{http://www.gnu.org/software/devel.html}, as well as throughout
+this document. In brief:
+
+@itemize @bullet
+@item Login accounts (see above).
+
+@item Version control (@pxref{Old Versions}).
+
+@item Mailing lists (@pxref{Mail}).
+
+@item Web pages (@pxref{Web Pages}).
+
+@item Mirrored release areas (@pxref{Distributions}).
+
+@cindex Hydra
+@cindex @code{platform-testers} mailing list
+@item Pre-release portability testing, both automated (via Hydra) and
+on request (via volunteers).
+
+@end itemize
+
@node Stepping Down
@chapter Stepping Down
maintainer needs the GNU Project's confirmation, but your judgment that
a person is capable of doing the job will carry a lot of weight.
-As your final act as maintainer, it would be helpful to set up the
-package under @code{savannah.gnu.org} if it is not there already
-(@pxref{Old Versions}). This will make it much easier for the new
-maintainer to pick up where you left off and will ensure that the
-source tree is not misplaced if it takes us a while to find a new
-maintainer.
+As your final act as maintainer, it would be helpful to set up or
+update the package under @code{savannah.gnu.org} (@pxref{Old
+Versions}). This will make it much easier for the new maintainer to
+pick up where you left off and will ensure that the source tree is not
+misplaced if it takes us a while to find a new maintainer.
@node Recruiting Developers
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
@url{http://www.gnu.org/licenses/fdl-howto.html} for more advice about
how to use the GNU FDL.
+If you write a manual that people might want to buy on paper, please
+write to @email{maintainers@@gnu.org} to tell the FSF about it. We
+might want to publish it.
+
If the manual is over 400 pages, or if the FSF thinks it might be a
good choice for publishing on paper, then please include the GNU GPL,
as in the notice above. Please also include our standard invariant
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 create and maintain simple aliases and unmanaged lists, you can
edit @file{/com/mailer/aliases} on the main GNU server. If you don't
have an account there, please read
-@url{http://www.gnu.org/software/README.accounts.html} (@pxref{Getting
-a GNU Account}).
+@url{http://www.gnu.org/software/README.accounts.html} (@pxref{GNU
+Accounts and Resources}).
But if you don't want to learn how to do those things, you can
alternatively ask @email{alias-file@@gnu.org} to add you to the
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
It is very important to keep backup files of all source files of GNU.
You can do this using a source control system (such as Bazaar, RCS,
-CVS, Git, Subversion, @dots{}) if you like. The easiest way to use
-RCS or CVS is via the Version Control library in Emacs
+CVS, Git, Subversion, @dots{}) if you like. An easy way to use
+many such systems is via the Version Control library in Emacs
(@pxref{Introduction to VC,, Introduction to Version Control, emacs,
The GNU Emacs Manual}).
some day.
@cindex @code{savannah-hackers@@gnu.org}
-The GNU Project provides a server that GNU software packages can use
+The GNU Project provides a server that GNU packages can use
for source control and other package needs: @code{savannah.gnu.org}.
Savannah is managed by @email{savannah-hackers@@gnu.org}. For more
details on using and contributing to Savannah, see
@url{http://savannah.gnu.org/maintenance}.
-It's not a requirement, but all GNU maintainers are strongly
+It's not an absolute requirement, but all GNU maintainers are strongly
encouraged to take advantage of Savannah, as sharing such a central
-point can serve to foster a sense of community among GNU developers
-and help in keeping up with project management.
+point can serve to foster a sense of community among GNU developers as
+well as help in keeping up with project management. Please don't mark
+Savannah projects for GNU packages as private; that defeats a large
+part of the purpose of using Savannah in the first place.
@cindex @code{savannah-announce@@gnu.org} mailing list
If you do use Savannah, please subscribe to the
@node Distributions
@chapter Distributions
-It is important to follow the GNU conventions when making GNU software
+Please follow the GNU conventions when making GNU software
distributions.
@menu
@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:
It's wise to test your patch by applying it to a copy of the old
version, and checking that the result exactly matches the new version.
+
@node Distribution on ftp.gnu.org
@section Distribution on @code{ftp.gnu.org}
@cindex GNU ftp site
@cindex @code{ftp.gnu.org}, the GNU release site
-GNU packages are distributed through the directory @file{/gnu} on
-@code{ftp.gnu.org}, via both HTTP and FTP. Each package should have a
-subdirectory named after the package, and all the distribution files
-for the package should go in that subdirectory.
+We strongly recommend using @code{ftp.gnu.org} to distribute official
+releases. If you want to also distribute the package from a site of
+your own, that is fine. To use some other site instead of
+@code{ftp.gnu.org} is acceptable, provided it allows connections from
+anyone anywhere.
-@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 the procedural details of putting
+new versions on @code{ftp.gnu.org}.
-@xref{Automated FTP Uploads}, for procedural details of putting new
-versions on @code{ftp.gnu.org}.
@node Test Releases
@section Test Releases
a suitable GNU mailing list/newsgroup to recruit them.)
We normally use the server @code{alpha.gnu.org} for pretests and
-prerelease versions. @xref{Automated FTP Uploads}, for procedural details
-of putting new versions on @code{alpha.gnu.org}.
+prerelease versions. @xref{Automated FTP Uploads}, for the procedural
+details of putting new versions on @code{alpha.gnu.org}.
Once a program gets to be widely used and people expect it to work
solidly, it is a good idea to do pretest releases before each ``real''
information. Then, you can perform uploads yourself, with no
intervention needed by the system administrators.
-The general idea is that releases should be crytographically signed
+The general idea is that releases should be cryptographically signed
before they are made publicly available.
@menu
@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
@cindex announcement mailing list, project-specific
You can maintain your own mailing list (typically
-@email{info-@var{package}@@gnu.org}) for announcements as well if you
+@indicateurl{info-@var{package}@@gnu.org}) for announcements as well if you
like. For your own list, of course you decide as you see fit what
events are worth announcing. (@xref{Mail}, for setting this up, and
more suggestions on handling mail for your package.)
@indicateurl{http://ftp.gnu.org/gnu/@var{package}/}). It is also
useful to mention the mirror list at
@url{http://www.gnu.org/order/ftp.html}, and that
-@url{http://ftpmirror.gnu.org/@var{package/}} will automatically
+@indicateurl{http://ftpmirror.gnu.org/@var{package/}} will automatically
redirect to a nearby mirror.
@item
@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
terminology and its reasons, you can refer to the URL
@url{http://www.gnu.org/gnu/linux-and-gnu.html}.
+To make it clear that Linux is a kernel, not an operating system,
+please take care to avoid using the term ``Linux system'' in those
+materials. If you want to have occasion to make a statement about
+systems in which the kernel is Linux, write ``systems in which the
+kernel is Linux'' or ``systems with Linux as the kernel.'' That
+explicitly contrasts the system and the kernel, and will help readers
+understand the difference between the two. Please avoid simplified
+forms such as ``Linux-based systems'' because those fail to highlight
+the difference between the kernel and the system, and could encourage
+readers to overlook the distinction.
+
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.
Versions}, for more information about Savannah.
We strongly urge you to use @code{ftp.gnu.org} as the standard
-distribution site. Doing so makes it easier for developers and users
-to find the latest GNU releases. However, it is ok to use another
-server if you wish, provided it allows access from the general public
-without limitation (for instance, without excluding any country).
+distribution site for releases. Doing so makes it easier for
+developers and users to find the latest GNU releases. However, it is
+ok to use another server if you wish, provided it allows access from
+the general public without limitation (for instance, without excluding
+any country).
If you use a company's machine to hold the repository for your
-program, or as its ftp site, please put this statement in a prominent
-place on the site, so as to prevent people from getting the wrong idea
-about the relationship between the package and the company:
+program, or as its release distribution site, please put this
+statement in a prominent place on the site, so as to prevent people
+from getting the wrong idea about the relationship between the package
+and the company:
@smallexample
The programs <list of them> hosted here are free software packages
projects / gnulib.git / blobdiff