X-Git-Url: http://erislabs.net/gitweb/?a=blobdiff_plain;f=doc%2Fmaintain.texi;h=8b89c251f7ffa9a06d0ec16d33cf16cb217d8ade;hb=5cc13c0f36d18dd428c7cceebd30ff8de6e2ff1e;hp=a9a27d9213d32c34aa2ab3f179c48680e25d2a69;hpb=a0d72143f3350c955a423ab810cb9dc42c21959b;p=gnulib.git diff --git a/doc/maintain.texi b/doc/maintain.texi index a9a27d921..8b89c251f 100644 --- a/doc/maintain.texi +++ b/doc/maintain.texi @@ -5,7 +5,7 @@ @c For double-sided printing, uncomment: @c @setchapternewpage odd @c This date is automagically updated when you save this file: -@set lastupdate February 6, 2004 +@set lastupdate May 10, 2005 @c %**end of header @dircategory GNU organization @@ -25,7 +25,7 @@ Information for maintainers of GNU software, last updated @value{lastupdate}. Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, -2001, 2002, 2003, 2004 Free Software Foundation, Inc. +2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc. @quotation Permission is granted to make and distribute verbatim copies @@ -184,7 +184,7 @@ as you maintain the program, to avoid legal difficulties. @cindex copyright papers If you maintain an FSF-copyrighted package -certain legal procedures when incorporating legally significant +certain legal procedures are required when incorporating legally significant changes written by other people. This ensures that the FSF has the legal right to distribute the package, and the standing to defend its GPL-covered status in court if necessary. @@ -235,10 +235,10 @@ vs.@: disclaim) and their consequences. Once the conversation is under way and the contributor is ready for more details, you should send one of the templates that are found in -@file{/gd/gnuorg/Copyright}. This section explains which templates -you should use in which circumstances. @strong{Please don't use any -of the templates except for those listed here, and please don't change -the wording.} +the directory @file{/gd/gnuorg/Copyright/}. This section explains +which templates you should use in which circumstances. @strong{Please +don't use any of the templates except for those listed here, and +please don't change the wording.} Once the conversation is under way, you can send the contributor the precise wording and instructions by email. Before you do this, make @@ -263,6 +263,11 @@ file gives per instructions for how to ask the FSF to mail per the papers to sign. The @file{request-} file also raises the issue of getting a copyright 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 about two weeks--mostly waiting for letters to go back and +forth. + 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 of the program in these templates, where it says @samp{NAME OF PERSON} @@ -281,7 +286,7 @@ manual. For smaller changes, use @file{disclaim.changes.manual}; for larger ones, use @file{assign.changes.manual}. To cover both past and future changes to a manual, you can use @file{assign.future.manual}. -For a translation of a manual, use @file{assign.translate.manual}. +For a translation of a manual, use @file{assign.translation.manual}. If a contributor is reluctant to sign an assignment for a large change, and is willing to sign a disclaimer instead, that is acceptable, so you @@ -478,7 +483,12 @@ released, were @emph{completed}. So if you finish a version on Dec 31, of 1994, but doesn't require the inclusion of 1995. Do not abbreviate the year list using a range; for instance, do not -write @samp{1996--1998}; instead, write @samp{1996, 1997, 1998}. +write @samp{1996--1998}; instead, write @samp{1996, 1997, 1998}. Do +write each relevant year as a four-digit number. In the normal course +of maintenance, you may come across copyright notices which omit the +century, as in @samp{1996, 97, 98}---change these to include the +century. However, there is no need to systematically change the +notice in every old file. The versions that matter, for purposes of this list, are versions that were ancestors of the current version. So if you made a temporary @@ -497,8 +507,8 @@ would probably change this (as well as many other aspects). For an FSF-copyrighted package, if you have followed the procedures to obtain legal papers, each file should have just one copyright holder: -the Free Software Foundation, Inc. So the copyright notice should give -that name. +the Free Software Foundation, Inc. You should edit the file's +copyright notice to list that name and only that name. But if contributors are not all assigning their copyrights to a single copyright holder, it can easily happen that one file has several @@ -570,8 +580,8 @@ GNU General Public License for more details. You should have received a copy of the GNU General Public License along with @var{program}; see the file COPYING. If not, write to -the Free Software Foundation, Inc., 59 Temple Place - Suite 330, -Boston, MA 02111-1307, USA. +the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, +Boston, MA 02110-1301 USA. @end quotation But in a small program which is just a few files, you can use @@ -590,7 +600,7 @@ GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., -59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. +51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA @end quotation Documentation files should have license notices also. Manuals should @@ -645,6 +655,11 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. @end smallexample +If your package distributes Autoconf macros that are intended to be +used (hence distributed) by third-party packages under possibly +incompatible licenses, you may also use the above all-permissive +license for these macros. + If you would like help with license issues or with using the GFDL, please contact @email{licensing@@gnu.org}. @@ -803,6 +818,14 @@ bug-reporting list for your program. To set up a new list, contact @email{new-mailing-list@@gnu.org}. You can subscribe to a list managed by Mailman by sending mail to the corresponding @samp{-request} address. +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 +Mailman, you can do this by setting @code{Privacy Options - Sender +Filter - generic_nonmember_action} to @code{Hold}, and then +periodically (daily is best) reviewing the held messages, accepting +the real ones and discarding the junk. + @cindex responding to bug reports 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. @@ -846,7 +869,7 @@ be a very useful thing to do. It is very important to keep backup files of all source files of GNU. You can do this using RCS, CVS or PRCS if you like. The easiest way to use RCS or CVS is via the Version Control library in Emacs; -@ref{Concepts of VC, , Concepts of Version Control, emacs, The GNU Emacs +@ref{VC Concepts,, Concepts of Version Control, emacs, The GNU Emacs Manual}. The history of previous revisions and log entries is very important for @@ -1147,7 +1170,8 @@ your package (in the example above, that is @code{bar}). Your designated upload email addresses (@pxref{Automated Upload Registration}) are sent a message if there are any problems processing -an upload for your package. +an upload for your package. You also receive a message when your ++upload has been successfully processed. If you have difficulties processing an upload, email @email{ftp-upload@@gnu.org}. @@ -1222,6 +1246,7 @@ so based on the contents of your @file{manual} directory. @menu * Invoking gendocs.sh:: +* CVS Keywords in Web Pages:: @end menu @node Invoking gendocs.sh @@ -1292,6 +1317,47 @@ Please email bug reports, enhancement requests, or other correspondence to @email{bug-texinfo@@gnu.org}. +@node CVS Keywords in Web Pages +@section CVS Keywords in Web Pages +@cindex cvs keywords in web pages +@cindex rcs keywords in web pages +@cindex $ keywords in web pages +@cindex web pages, and cvs keywords + +Since @code{www.gnu.org} works through CVS, CVS keywords in your +manual, such as @code{@w{$}Log$}, need special treatment (even if you +don't happen to maintain your manual in CVS). + +If these keywords end up in the generated output as literal strings, +they will be expanded. The most robust way to handle this is to turn +off keyword expansion for such generated files. For existing files, +this is done with: + +@example +cvs admin -ko @var{file1} @var{file2} ... +@end example + +@noindent +For new files: + +@example +cvs add -ko @var{file1} @var{file2} ... +@end example + +@xref{Keyword substitution,,,cvs,Version Management with CVS}. + +In Texinfo source, the recommended way to literally specify a +``dollar'' keyword is: + +@example +@@w@{$@}Log$ +@end example + +The @code{@@w} prevents keyword expansion in the Texinfo source +itself. Also, @code{makeinfo} notices the @code{@@w} and generates +output avoiding the literal keyword string. + + @node Ethical and Philosophical Consideration @chapter Ethical and Philosophical Consideration @cindex ethics @@ -1377,14 +1443,15 @@ 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 -software,'' rather than ``open source,'' in GNU software releases, GNU +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 +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. +above, to explain the difference, is a useful thing to include as +well. @node GNU and Linux @section GNU and Linux