@c For double-sided printing, uncomment:
@c @setchapternewpage odd
@c This date is automagically updated when you save this file:
-@set lastupdate March 25, 2010
+@set lastupdate September 5, 2011
@c %**end of header
@dircategory GNU organization
Information for maintainers of GNU software, last updated @value{lastupdate}.
Copyright @copyright{} 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
-2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free Software
-Foundation, Inc.
+2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
+2010, 2011 Free Software Foundation, Inc.
@quotation
Permission is granted to copy, distribute and/or modify this document
@menu
* Preface::
+* Getting Help::
+* Getting a GNU Account::
* Stepping Down::
* Recruiting Developers::
* Legal Matters::
* Ethical and Philosophical Consideration::
* Terminology::
* Hosting::
+* Donations::
* Free Software Directory::
* Using the Proofreaders List::
* GNU Free Documentation License::
This file contains guidelines and advice for someone who is the
maintainer of a GNU program on behalf of the GNU Project. Everyone is
entitled to change and redistribute GNU software; you need not pay
-attention to this file to get permission. But if you want to maintain a
-version for widespread distribution, we suggest you follow these
-guidelines. If you would like to be a GNU maintainer, then it is
-essential to follow these guidelines.
+attention to this file to get permission. But if you want to maintain
+a version for widespread distribution, we suggest you follow these
+guidelines. If you are or would like to be a GNU maintainer, then it
+is essential to follow these guidelines.
In addition to this document, please read and follow the GNU Coding
Standards (@pxref{Top, , Contents, standards, GNU Coding Standards}).
-@cindex @code{gnustandards-commit@@gnu.org} mailing list
-If you want to receive diffs for every change to these GNU documents,
-join the mailing list @code{gnustandards-commit@@gnu.org}, via the web
-interface at
-@url{http://lists.gnu.org/mailman/listinfo/gnustandards-commit}.
-Archives are also available there.
-
@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 a suggested new wording for it, to help us consider the
-suggestion efficiently. We prefer a context diff to the Texinfo
-source, but if that's difficult for you, you can make a context diff
-for some other version of this document, or propose it in any way that
-makes it clear. The source repository for this document can be found
-at @url{http://savannah.gnu.org/projects/gnustandards}.
+include suggested new wording if you can. We prefer a context diff to
+the Texinfo source, but if that's difficult for you, you can make a
+diff for some other version of this document, or propose it in any way
+that makes it clear. The source repository for this document can be
+found at @url{http://savannah.gnu.org/projects/gnustandards}.
-@cindex @code{mentors@@gnu.org} mailing list
-If you have general questions or encounter a situation where it isn't
-clear what to do, you can ask @email{mentors@@gnu.org}, which is a
-list of a few experienced GNU contributors who have offered to answer
-questions for new maintainers.
-
-The directory @file{/gd/gnuorg} mentioned throughout this document is
-found on the GNU file server, currently @code{fencepost.gnu.org}; if
-you are the maintainer of a GNU package, you should have an account
-there. See @url{http://www.gnu.org/software/README.accounts.html} if
-you don't have one. (You can also ask for accounts for people who
-help you a large amount in working on the package.)
-
-If on occasion you find that any GNU computer systems
-(@code{fencepost.gnu.org}, @code{ftp.gnu.org},
-@code{savannah.gnu.org}, or others) seem to be down, you can check the
-current status at @url{http://identi.ca/group/fsfstatus}. Most likely
-the problem, if it is at the FSF end, is already being worked on.
+@cindex @code{gnustandards-commit@@gnu.org} mailing list
+If you want to receive diffs for every change to these GNU documents,
+join the mailing list @code{gnustandards-commit@@gnu.org}, for
+instance via the web interface at
+@url{http://lists.gnu.org/mailman/listinfo/gnustandards-commit}.
+Archives are also available there.
@cindex Piercy, Marge
This document uses the gender-neutral third-person pronouns ``person'',
per new program under the GNU GPL, to let the public benefit from per
work, and to enable per to feel person has done the right thing.''
-This release of the GNU Maintenance Instructions was last updated
+This release of the GNU Maintainer Information was last updated
@value{lastupdate}.
+@node Getting Help
+@chapter Getting Help
+@cindex help, getting
+
+@cindex @code{mentors@@gnu.org} mailing list
+If you have any general questions or encounter a situation where it
+isn't clear how to get something done or who to ask, you (as a GNU
+contributor) can always write to @email{mentors@@gnu.org}, which is a
+list of a few experienced GNU folks who have volunteered to answer
+questions. Any GNU-related question is fair game for the
+@code{mentors} list.
+
+@cindex advisory committee
+The GNU Advisory Committee helps to coordinate activities in the GNU
+project on behalf of RMS (Richard Stallman, the Chief GNUisance). If
+you have any organizational questions or concerns you can contact the
+committee at @email{gnu-advisory@@gnu.org}. See
+@url{http://www.gnu.org/contact/gnu-advisory.html} for the current
+committee members. Additional information is in
+@file{/gd/gnuorg/advisory}.
+
+@cindex down, when GNU machines are
+@cindex outage, of GNU machines
+@cindex @url{http://identi.ca/group/fsfstatus}
+If you find that any GNU computer systems (@code{fencepost.gnu.org},
+@code{ftp.gnu.org}, @code{www.gnu.org}, @code{savannah.gnu.org},
+@dots{}) seem to be down, you can check the current status at
+@url{http://identi.ca/group/fsfstatus}. Most likely the problem, if
+it can be alleviated at the FSF end, is already being worked on.
+
+@cindex sysadmin, FSF
+@cindex FSF system administrators
+@cindex GNU system administrators
+The FSF system administrators are responsible for the network and GNU
+hardware. You can email them at @email{sysadmin@@fsf.org}, but please
+try not to burden them unnecessarily.
+
+
+@node Getting a GNU Account
+@chapter Getting a GNU Account
+@cindex shell account, on fencepost
+@cindex @code{fencepost.gnu.org} GNU machine
+
+@c We want to repeat this text later, so define a macro.
+@macro gdgnuorgtext
+The directory @file{/gd/gnuorg} mentioned throughout this document is
+available on the general GNU server, currently
+@code{fencepost.gnu.org}. If you are the maintainer of a GNU package,
+you should have an account there. If you don't have one already,
+@url{http://www.gnu.org/software/README.accounts.html}. You can also
+ask for accounts for people who significantly help you in working on
+the package.
+@end macro
+
+@gdgnuorgtext{}
+
+
@node Stepping Down
@chapter Stepping Down
+@cindex stepping down as maintainer
+@cindex resigning as maintainer
With good fortune, you will continue maintaining your package for many
decades. But sometimes for various reasons maintainers decide to step
We need to know that the package no longer has a maintainer, so we can
look for and appoint a new maintainer.
+@cindex @email{maintainers@@gnu.org}
If you have an idea for who should take over, please tell
@email{maintainers@@gnu.org} your suggestion. The appointment of a new
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
@cindex @file{/gd/gnuorg} directory
@c This paragraph intentionally duplicates information given
@c near the beginning of the file--to make sure people don't miss it.
-The directory @file{/gd/gnuorg} is found on the GNU machines,
-currently @code{fencepost.gnu.org}; if you are the maintainer of a GNU
-package, you should have an account on them. Contact
-@email{accounts@@gnu.org} if you don't have one. (You can also ask
-for accounts for people who help you a large amount in working on the
-package.)
+@gdgnuorgtext{}
In order for the contributor to know person should sign papers, you need
to ask per for the necessary papers. If you don't know per well, and you
@quotation
Would you be willing to assign the copyright to the Free Software
-Foundation, so that we could install it in @var{program}?
+Foundation, so that we could install it in @var{package}?
@end quotation
@noindent
@quotation
Would you be willing to sign a copyright disclaimer to put this change
-in the public domain, so that we can install it in @var{program}?
+in the public domain, so that we can install it in @var{package}?
@end quotation
-If the contributor wants more information, you can send per
+If the contributor then wants more information, you can send per the file
@file{/gd/gnuorg/conditions.text}, which explains per options (assign
vs.@: disclaim) and their consequences.
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 about two weeks--mostly waiting for letters to go back and
+takes a couple of weeks---mostly waiting for letters to go back and
forth.
For less common cases, we have template files you should send to the
For a translation of a manual, use @file{assign.translation.manual}.
For translations of program strings (as used by GNU Gettext, for
-example; @pxref{Internationalization,,,standards,GNU Coding
+example; @pxref{Internationalization,,, standards, GNU Coding
Standards}), use @file{disclaim.translation}. If you make use of the
Translation Project (@url{http://translationproject.org}) facilities,
please check with the TP coordinators that they have sent the
don't need to distinguish work done at different times, only different
people. They don't need describe changes in more detail than which
files or parts of a file were changed. And they don't need to say
-anything about the function or purpose of a file or change--the
+anything about the function or purpose of a file or change---the
Register of Copyrights doesn't care what the text does, just who wrote
or contributed to which parts.
extend copyright. If you copy a file into the package from some other
program, keep the copyright years that come with the file.
-Do not abbreviate the year list using a range; for instance, do not
-write @samp{1996--1998}; instead, write @samp{1996, 1997, 1998}.
+You can use a range (@samp{2008-2010}) instead of listing individual
+years (@samp{2008, 2009, 2010}) if and only if: 1)@tie{}every year in
+the range, inclusive, really is a ``copyrightable'' year that would be
+listed individually; @emph{and} 2)@tie{}you make an explicit statement
+in a @file{README} file about this usage.
For files which are regularly copied from another project (such as
@samp{gnulib}), leave the copyright notice as it is in the original.
copy of its plain text version also (conventionally in a file named
@file{COPYING.LESSER}).
-If you have questions about license issues for your GNU package,
+If you have questions about licensing issues for your GNU package,
please write @email{licensing@@gnu.org}.
@menu
-* Source: Canonical License Sources.
-* Code: License Notices for Code.
+* Which: Licensing of GNU Packages.
+* Canonical: Canonical License Sources.
+* Code: License Notices for Code.
* Documentation: License Notices for Documentation.
-* Other: License Notices for Other Files.
+* Other: License Notices for Other Files.
@end menu
+@node Licensing of GNU Packages
+@subsection Licensing of GNU Packages
+
+Normally, GNU packages should use the latest version of the GNU GPL,
+with the ``or any later version'' formulation. @xref{License Notices
+for Code}, for the exact wording of the license notice.
+
+Occasionally, a GNU library may provide functionality which is already
+widely available to proprietary programs through alternative
+implementations; for example, the GNU C Library. In such cases, the
+Lesser GPL should be used (again, for the notice wording,
+@pxref{License Notices for Code}). If a GNU library provides unique
+functionality, however, the GNU GPL should be used.
+@url{http://www.gnu.org/licenses/why-not-lgpl.html} discusses this
+strategic choice.
+
+Some of these libraries need to work with programs released under
+GPLv2-only; that is, which allow the GNU GPL version 2 but not later
+versions. In this case, the GNU package should be released under a
+dual license: GNU GPL version 2 (or any later version) and the GNU
+Lesser GPL version 3 (or any later version). Here is the notice for
+that case:
+
+@smallexample
+This file is part of GNU @var{package}.
+
+GNU @var{package} is free software: you can redistribute it and/or
+modify it under the terms of either:
+
+ * the GNU Lesser General Public License as published by the Free
+ Software Foundation; either version 3 of the License, or (at your
+ option) any later version.
+
+or
+
+ * the GNU General Public License as published by the Free
+ Software Foundation; either version 2 of the License, or (at your
+ option) any later version.
+
+or both in parallel, as here.
+
+GNU @var{package} is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received copies of the GNU General Public License and
+the GNU Lesser General Public License along with this program. If
+not, see @url{http://www.gnu.org/licenses/}.
+@end smallexample
+
+For small packages, you can use ``This program'' instead of ``GNU
+@var{package}''.
+
+
@node Canonical License Sources
@subsection Canonical License Sources
The official Texinfo sources for the licenses are also available in
those same places, so you can include them in your documentation. A
GFDL-covered manual should include the GFDL in this way. @xref{GNU
-Sample Texts,,,texinfo,Texinfo}, for a full example in a Texinfo
+Sample Texts,,, texinfo, Texinfo}, for a full example in a Texinfo
manual.
configure files and makefiles) should cite the GPL, like this:
@quotation
-This file is part of GNU @var{program}.
+This file is part of GNU @var{package}.
-GNU @var{program} is free software: you can redistribute it and/or
+GNU @var{package} is free software: you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.
-GNU @var{program} is distributed in the hope that it will be useful,
+GNU @var{package} is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
along with this program. If not, see @url{http://www.gnu.org/licenses/}.
@end quotation
+In either case, for those few packages which use the Lesser GPL
+(@pxref{Licensing of GNU Packages}), insert the word ``Lesser'' before
+``General'' in @emph{all three} places.
+@url{http://@/www.gnu.org/@/licenses/@/gpl-howto.html} discusses application
+the GPL in more detail.
+
@node License Notices for Documentation
@subsection License Notices for Documentation
If your manual is not published by the FSF, and under 400 pages, you
can omit both cover texts.
-@xref{GNU Sample Texts,,,texinfo,Texinfo}, for a full example in a
+@xref{GNU Sample Texts,,, texinfo, Texinfo}, for a full example in a
Texinfo manual, and see
@url{http://www.gnu.org/licenses/fdl-howto.html} for more advice about
how to use the GNU FDL.
You will naturally want to keep the program running on all the platforms
it supports. But you personally will not have access to most of these
-platforms--so how should you do it?
+platforms---so how should you do it?
Don't worry about trying to get access to all of these platforms. Even
if you did have access to all the platforms, it would be inefficient for
It is important to test the program personally on GNU or GNU/Linux,
because these are the most important platforms for a GNU package. If
-you don't have access to one of these platforms, please ask
-@email{maintainers@@gnu.org} to help you out.
+you don't have access to one of these platforms, as a GNU maintainer
+you can get access to the general GNU login machine; see
+@url{http://www.gnu.org/software/README.accounts.html}.
Supporting other platforms is optional---we do it when that seems like
a good idea, but we don't consider it obligatory. If the users don't
@node Mail
@chapter Dealing With Mail
-@cindex bug reports
+@cindex email
+
+This chapter describes setting up mailing lists for your package, and
+gives advice on how to handle bug reports and random requests once you
+have them.
+
+@menu
+* Standard Mailing Lists:: @samp{bug-pkg@@gnu.org} and other standard names.
+* Creating Mailing Lists:: The best way is to use Savannah.
+* Replying to Mail:: Advice on replying to incoming mail.
+@end menu
+
+
+@node Standard Mailing Lists
+@section Standard Mailing Lists
+
+@cindex standard mailing lists
+@cindex mailing lists, standard names of
-@cindex email, for receiving bug reports
@cindex mailing list for bug reports
Once a program is in use, you will get bug reports for it. Most GNU
programs have their own special lists for sending bug reports. The
advertised bug-reporting email address should always be
-@samp{bug-@var{program}@@gnu.org}, to help show users that the program
+@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 for further forwarding. The package distribution should state the
+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.
+@cindex @email{bug-gnu-utils@@gnu.org}
We also have a catch-all list, @email{bug-gnu-utils@@gnu.org}, which is
used for all GNU programs that don't have their own specific lists. But
nowadays we want to give each program its own bug-reporting list and
move away from using @email{bug-gnu-utils}.
-If you wish, you can also have mailing lists such as
-@samp{info-@var{program}} for announcements (@pxref{Announcements}),
-@samp{help-@var{program}} for general help and discussion (see below),
-or any others you find useful.
-
-By far the easiest way to create mailing lists is through
-@code{savannah.gnu.org}. Once you register your program, you can do
-this yourself through the `Mailing Lists' menu, without needing
-intervention by anyone else. Furthermore, lists created through
-Savannah will have a reasonable default configuration for antispam
-purposes (see below).
-
-If you are the maintainer of a GNU package, you should have an account
-on the GNU servers; contact
-@url{http://www.gnu.org/software/README.accounts.html} if you don't
-have one. (You can also ask for accounts for people who help you a
-large amount in working on the package.) With this account, you can
-edit @file{/com/mailer/aliases} to create a new unmanaged list or add
-yourself to an existing unmanaged list. A comment near the beginning
-of that file explains how to create a Mailman-managed mailing list.
+@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.
+If your program has many users, you should create such a list for it.
+For a fairly new program, which doesn't have a large user base yet, it
+is better not to bother with this.
+
+@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.
+
+
+@node Creating Mailing Lists
+@section Creating Mailing Lists
+
+@cindex creating mailing lists
+@cindex mailing lists, creating
+
+Using the web interface on @code{savannah.gnu.org} is by far the
+easiest way to create normal mailing lists, managed through Mailman on
+the GNU mail server. Once you register your package on Savannah, you
+can create (and remove) lists yourself through the `Mailing Lists'
+menu, without needing to wait for intervention by anyone else.
+Furthermore, lists created through Savannah will have a reasonable
+default configuration for antispam purposes (see below).
+
+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}).
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
@email{new-mailing-list@@gnu.org}. You can subscribe to a list managed
by Mailman by sending mail to the corresponding @samp{-request} address.
+@cindex spam prevention
You should moderate postings from non-subscribed addresses on your
mailing lists, to prevent propagation of unwanted messages (``spam'')
to subscribers and to the list archives. For lists controlled by
periodically (daily is best) reviewing the held messages, accepting
the real ones and discarding the junk.
+Lists created through Savannah will have this setting, and a number of
+others, such that spam will be automatically deleted (after a short
+delay). The Savannah mailing list page describes all the details.
+You should still review the held messages in order to approve any that
+are real.
+
+
+@node Replying to Mail
+@section Replying to Mail
+
@cindex responding to bug reports
+@cindex bug reports, handling
+@cindex help requests, handling
+
When you receive bug reports, keep in mind that bug reports are crucial
for your work. If you don't know about problems, you cannot fix them.
So always thank each person who sends a bug report.
time, just ``thanks for the bug report---I will fix it'' is enough
response.
-Some GNU packages, such as Emacs and GCC, come with advice about how to
-make bug reports useful. If you want to copy and adapt that, it could
-be a very useful thing to do.
+Some GNU packages, such as Emacs and GCC, come with advice about how
+to make bug reports useful. Copying and adapting that could be very
+useful for your package.
@node Old Versions
@cindex version control
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 RCS, CVS, Git,
-@dots{}) if you like. The easiest way to use RCS or CVS is via the
-Version Control library in Emacs (@pxref{VC Concepts,, Concepts of
-Version Control, emacs, The GNU Emacs Manual}).
+You can do this using a source control system (such as Bazaar, RCS,
+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}).
The history of previous revisions and log entries is very important for
future maintainers of the package, so even if you do not make it
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}.
-You don't have to use this repository, but if you plan to allow public
-read-only access to your development sources, it is convenient for
-people to be able to find various GNU packages in a central place.
-Savannah is managed by @email{savannah-hackers@@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}.
-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.
+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 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, it is a good idea to subscribe to the
+If you do use Savannah, please subscribe to the
@email{savannah-announce@@gnu.org} mailing list
(@url{http://lists.gnu.org/mailman/listinfo/savannah-announce}). This
is a very low-volume list to keep Savannah users informed of system
@node Distribution on ftp.gnu.org
@section Distribution on @code{ftp.gnu.org}
@cindex GNU ftp site
-@cindex @code{ftp.gnu.org}, the GNU ftp site
+@cindex @code{ftp.gnu.org}, the GNU release site
-GNU packages are distributed through directory @file{/gnu} on
-@code{ftp.gnu.org}. Each package should have a subdirectory
-named after the package, and all the distribution files for the package
-should go in that subdirectory.
+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.
@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
@cindex beta releases
@cindex pretest releases
-@cindex @code{alpha.gnu.org}, ftp site for test releases
+@cindex @code{alpha.gnu.org}, test release site
When you release a greatly changed new major version of a program, you
might want to do so as a pretest. This means that you make a tar file,
but send it only to a group of volunteers that you have recruited. (Use
a suitable GNU mailing list/newsgroup to recruit them.)
-We normally use the FTP server @code{alpha.gnu.org} for pretests and
+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}.
@item
Create an account for yourself at @url{http://savannah.gnu.org}, if
you don't already have one. By the way, this is also needed to
-maintain the web pages at @url{www.gnu.org} for your project
+maintain the web pages at @url{http://www.gnu.org} for your project
(@pxref{Web Pages}).
@item
In the @samp{My Account Conf} page on @code{savannah}, upload the GPG
-key you will use to sign your packages.
+key you will use to sign your packages. If you haven't created one
+before, you can do so with the command @code{gpg --gen-key} (you can
+accept all the default answers to its questions).
-You can create a key with the command @code{gpg --gen-key}. It is
-good to also send your key to the GPG public key server: @code{gpg
---keyserver keys.gnupg.net --send-keys @var{keyid}}, where @var{keyid}
-is the eight hex digits reported by @code{gpg --list-public-keys} on
-the @code{pub} line before the date. For full information about GPG,
-see @url{http://www.gnu.org/software/gpg})
+Optional but recommended: Send your key to a GPG public key server:
+@code{gpg --keyserver keys.gnupg.net --send-keys @var{keyid}}, where
+@var{keyid} is the eight hex digits reported by @code{gpg
+--list-public-keys} on the @code{pub} line before the date. For full
+information about GPG, see @url{http://www.gnu.org/software/gpg}.
@item
Compose a message with the following items in some @var{msgfile}.
@enumerate
@item
-Name of package(s) that you are the maintainer for, and your
-preferred email address.
+Name of package(s) that you are the maintainer for, your
+preferred email address, and your Savannah username.
@item
-An ASCII armored copy of your GnuPG key, as an attachment. (@samp{gpg
+An ASCII armored copy of your GPG key, as an attachment. (@samp{gpg
--export -a @var{your_key_id} >mykey.asc} should give you this.)
@item
don't make all releases yourself).
@item
-ASCII armored copies of GnuPG keys for any individuals listed in (3).
+ASCII armored copies of GPG keys for any individuals listed in (3).
@end enumerate
@end enumerate
Detached GPG binary signature file for (1); for example,
@file{foo.tar.gz.sig}. Make this with @samp{gpg -b foo.tar.gz}.
-
@item
A clearsigned @dfn{directive file}; for example,
@file{foo.tar.gz.directive.asc}. Make this by preparing the plain
version: 1.1
directory: bar/v1
archive: foo-1.1.tar.gz
-comment: archive an old file; it will not be available through FTP anymore
+comment: archive an old file; it will not be
+comment: available through FTP any more.
@end example
@noindent
version: 1.1
directory: bar/v1
archive: foo
-comment: archive an old directory; it will not be available through FTP anymore
+comment: archive an old directory; it and its entire
+comment: contents will not be available through FTP anymore
@end example
@noindent
@cindex @url{http://planet.gnu.org}
@cindex Savannah, news area
Please also post release announcements in the news section of your
-Savannah project site. It is fine to also write news entries for test
-releases and any other newsworthy events. The news feeds from all GNU
-projects at savannah are aggregated at @url{http://planet.gnu.org}
-(GNU Planet). You can also post items directly, or arrange for feeds
-from other locations; see contact information on the GNU Planet web
-page.
+Savannah project site. Here, it is fine to also write news entries
+for test releases and any other newsworthy events. The news feeds
+from all GNU projects at savannah are aggregated at
+@url{http://planet.gnu.org} (GNU Planet). You can also post items
+directly, or arrange for feeds from other locations; see information
+on the GNU Planet web page.
@cindex announcement mailing list, project-specific
You can maintain your own mailing list (typically
-@email{info-@var{program}@@gnu.org}) for announcements as well if you
+@email{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 more suggestions on
-handling mail for your package.)
+events are worth announcing. (@xref{Mail}, for setting this up, and
+more suggestions on handling mail for your package.)
@cindex contents of announcements
When writing an announcement, please include the following:
@item
Your package's download location (normally
@indicateurl{http://ftp.gnu.org/gnu/@var{package}/}). It is also
-useful to mention the FTP mirror list at
+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
redirect to a nearby mirror.
@item
-The NEWS (@pxref{NEWS File,,, standards, GNU Coding Standards}) for
+The @t{NEWS} (@pxref{NEWS File,,, standards, GNU Coding Standards}) for
the present release.
@end itemize
@chapter Web Pages
@cindex web pages
-Please write web pages about your package for installation on
+Please write web pages about your package, and install them on
@code{www.gnu.org}. They should follow our usual standards for web
-pages (see @url{http://www.gnu.org/server/fsf-html-style-sheet.html}).
+pages (see @url{http://www.gnu.org/server/@/fsf-html-style-sheet.html}).
The overall goals are to support a wide variety of browsers, to focus
on information rather than flashy eye candy, and to keep the site
simple and uniform.
+We encourage you to use the standard @code{www.gnu.org} template as
+the basis for your pages:
+@url{http://www.gnu.org/server/@/standards/@/boilerplate-source.html}.
+
Some GNU packages have just simple web pages, but the more information
you provide, the better. So please write as much as you usefully can,
and put all of it on @code{www.gnu.org}. However, pages that access
-databases (including mail logs and bug tracking) are an exception; set
-them up on whatever site is convenient for you, and make the pages on
-@code{www.gnu.org} link to that site.
+databases (including mail archives and bug tracking) are an exception;
+set them up on whatever site is convenient for you, and make the pages
+on @code{www.gnu.org} link to that site.
@menu
* Hosting for Web Pages::
* CVS Keywords in Web Pages::
@end menu
+
@node Hosting for Web Pages
@section Hosting for Web Pages
instance, you can mail them pages to install, if necessary. But that
is more work for them, so please use Savannah if you can.
-If you use Savannah, you can use a special @file{.symlinks} file in
-order to create symbolic links, which are not supported in CVS. For
-details, see
+If you use Savannah, you can use a special file named @file{.symlinks}
+in order to create symbolic links, which are not supported in CVS.
+For details, see
@url{http://www.gnu.org/server/standards/README.webmastering.html#symlinks}.
See the section below for details on a script to make the job of
creating all these different formats and index pages easier.
-We would like to include links to all GNU manuals on the page
-@url{http://www.gnu.org/manual}, so if yours isn't listed, please send
-mail to @code{webmasters@@gnu.org} telling them the name of your
-package and asking them to edit @url{http://www.gnu.org/manual}, and
-they will do so based on the contents of your @file{manual} directory.
+We would like to list all GNU manuals on the page
+@url{http://www.gnu.org/manual}, so if yours isn't there, please send
+mail to @code{webmasters@@gnu.org}, asking them to add yours, and they
+will do so based on the contents of your @file{manual} directory.
@menu
* Invoking gendocs.sh::
cvs add -ko @var{file1} @var{file2} ...
@end example
-@xref{Keyword substitution,,,cvs,Version Management with CVS}.
+@c The CVS manual is now built with numeric references and no nonsplit
+@c form, so it's not worth trying to give a direct link.
+See the ``Keyword Substitution'' section in the CVS manual, available
+at @url{http://ximbiot.com/cvs/manual}.
In Texinfo source, the recommended way to literally specify a
``dollar'' keyword is:
are some patents which we know are likely to be used to threaten free
software, so we make an effort to avoid the patented techniques. If
you are concerned about the danger of a patent and would like advice,
-write to @email{maintainers@@gnu.org}, and we will try to help you get
+write to @email{licensing@@gnu.org}, and we will try to help you get
advice from a lawyer.
Sometimes the GNU project takes a strong stand against a particular
@node Free Software and Open Source
@section Free Software and Open Source
-@cindex free software
+@cindex free software movement
@cindex open source
-@cindex movements, Free Software and Open Source
-
-The terms ``free software'' and ``open source'' are the slogans of two
-different movements which differ in their basic philosophy. The Free
-Software Movement is idealistic, and raises issues of freedom, ethics,
-principle and what makes for a good society. The Open Source Movement,
-founded in 1998, studiously avoids such questions. For more explanation,
-see @url{http://www.gnu.org/philosophy/open-source-misses-the-point.html}.
-
-The GNU Project is aligned with the Free Software Movement. This
+@cindex movement, free software
+@cindex development method, open source
+
+The terms ``free software'' and ``open source'', while describing
+almost the same category of software, stand for views based on
+fundamentally different values. The free software movement is
+idealistic, and raises issues of freedom, ethics, principle and what
+makes for a good society. The term open source, initiated in 1998, is
+associated with a philosophy which studiously avoids such questions.
+For a detailed explanation, see
+@url{http://www.gnu.org/philosophy/open-source-misses-the-point.html}.
+
+The GNU Project is aligned with the free software movement. This
doesn't mean that all GNU contributors and maintainers have to agree;
your views on these issues are up to you, and you're entitled to express
them when speaking for yourself.
-However, due to the much greater publicity that the Open Source
-Movement receives, the GNU Project needs to overcome a widespread
-mistaken impression that GNU is @emph{and always was} an activity of
-the Open Source Movement. For this reason, please use the term ``free
+However, due to the much greater publicity that the term ``open source''
+receives, the GNU Project needs to overcome a widespread
+mistaken impression that GNU is @emph{and always was} an ``open
+source'' activity. For this reason, please use the term ``free
software'', not ``open source'', in GNU software releases, GNU
documentation, and announcements and articles that you publish in your
role as the maintainer of a GNU package. A reference to the URL given
above, to explain the difference, is a useful thing to include as
well.
+
@node GNU and Linux
@section GNU and Linux
@cindex Linux
@cindex source repository
@cindex version control system
@cindex FTP site
+@cindex release site
@cindex hosting
We recommend using @code{savannah.gnu.org} for the source code
-repository for your package, and, even more so, using
-@code{ftp.gnu.org} as the standard distribution site. Doing so makes
-it easier for developers and users to find the latest GNU releases.
-@xref{Old Versions}, for more information about Savannah.
-
-However, it is ok to use other machines if you wish. 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:
+repository for your package, but that's not required. @xref{Old
+Versions}, for more information about Savannah.
+
+We strongly urge you to use @code{ftp.gnu.org} as the standard
+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 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
information, see http://www.gnu.org/philosophy/free-sw.html.
If you are looking for service or support for GNU software, see
-http://www.gnu.org/help/gethelp.html for suggestions of where to ask.
+http://www.gnu.org/gethelp/ for suggestions of where to ask.
If you would like to contribute to the development of one of these
packages, contact the package maintainer or the bug-reporting address
@end smallexample
+@node Donations
+@chapter Donations
+@cindex Donations, for packages
+@cindex Money, donated to packages
+
+As a maintainer, you might want to accept donations for your work,
+especially if you pay for any of your own hosting/development
+infrastructure. Following is some text you can adapt to your own
+situation, and use on your package's web site, @file{README}, or
+in wherever way you find it useful:
+
+@smallexample
+We appreciate contributions of any size -- donations enable us to spend
+more time working on the project, and help cover our infrastructure
+expenses.
+
+If you'd like to make a small donation, please visit @var{url1} and do
+it through @var{payment-service}. Since our project isn't a
+tax-exempt organization, we can't offer you a tax deduction, but for
+all donations over @var{amount1}, we'd be happy to recognize your
+contribution on @var{url2}.
+
+We are also happy to consider making particular improvements or
+changes, or giving specific technical assistance, in return for a
+substantial donation over @var{amount2}. If you would like to discuss
+this possibility, write to us at @var{address}.
+
+Another possibility is to pay a software maintenance fee. Again,
+write to us about this at @var{address} to discuss how much you want
+to pay and how much maintenance we can offer in return. If you pay
+more than @var{amount1}, we can give you a document for your records.
+
+Thanks for your support!
+@end smallexample
+
+We don't recommend any specific payment service. However, GNU
+developers should not use a service that requires them to sign a
+proprietary software license, such as Google's payment service.
+
+Of course, it is also good to encourage people to join or contribute
+to the FSF (@url{http://www.fsf.org}), either instead of or as well as
+package-specific donations.
+
+
@node Free Software Directory
@chapter Free Software Directory
@cindex Free Software Directory
projects / gnulib.git / blobdiff