[gfsd]Re: ToutDoux - hOpla

[Philippe Roy]

Hi,

Why ToutDoux's page, hOpla's page, author'entry aren't in FSF web site ?

Philippe


Le dim, 12 nov 2000 01:30:27, Bradley M. Kuhn a écrit :
> 
> > Le jeu, 26 oct 2000 02:39:01, Richard Stallman a écrit :
> > > I hereby dub ToutDoux a GNU package.
> > 
> > Le ven, 27 oct 2000 16:09:30, Richard Stallman a écrit :
> > > I hereby dub hOpla a GNU program.
> 
> Congratulations on becoming a new GNU maintainer!  We are happy to have
> you
> as part of our team!  In this message, there are some final logistical
> issues we need to take care of to set you up as a maintainer.
> 
> Included below is a copy of the maintainer information file, if you
> haven't
> seen it already.  You can always find it on fencepost.gnu.org at
> /gd/gnuorg/maintain.{text,texi} and online at
> http://www.gnu.org/prep/maintain_toc.html.  This document describes the
> responsibilities of maintaining a GNU program.  If you have any
> questions,
> please let us know.
> 
> The most important issues to note right away concerning this are the
> following:
> 
>   (0) For GNU software, we either like to (a) distribute it from
>       ftp://ftp.gnu.org/gnu/, or (b) put a README there to tell users
>       where they can get the program.
> 
>       You mentioned already in another message that you'd like to do (a)
> and
>       upload them yourself to ftp.gnu.org.  I have sent a message to
>       <address@hidden> to ask them to make an account on
> gnudist.gnu.org
>       for you.  If you don't hear from them in a few days, feel free to
> ping
>       them.
> 
> 
>       BTW, when you make major releases, please do send an announcement
> to
>       <address@hidden>.
> 
>   (1) We would like to set up a <address@hidden> right away if it
>       doesn't already exist.  This can be (a) a mailing list on the GNU
>       machines, (b) a mailing list on some other machine, or (c) a simple
>       aliases that forwards to you (and possibly some other interested
>       parties, too).
> 
>       If you'd like (a), let <address@hidden> know, and they'll
>       set it up.  If you'd like (b) or (c), please tell
> <address@hidden>
>       know the pertinent addresses so they can set things up.
> 
>   (2) Also, please consider making a <address@hidden> list where
> users
>       can get informal help (if it doesn't already exist).  If you
> already
>       have such a list, please tell <address@hidden> where so we can
>       forward to it.  If you don't have such a list yet, we can easily
>       create one on the GNU machines---just ask
> <address@hidden>.
> 
>   (3) We are building a Free Software Directory, which is a directory of
> all
>       free software that we have found.  We'd like for you to write an
> entry
>       for your program for the Free Software Directory.  Please contact
>       <address@hidden> to write an entry.
> 
>   (4) We would like to have a web page for your program at
>       http://www.gnu.org/software/PROGRAM/.  Please send a page for this
> to
>       the GNU Web Masters <address@hidden> or ask <address@hidden>
> for
>       an account on gnudist.gnu.org so that you can edit the page
> yourself
>       directly.
> 
> Also, since you are a GNU maintainer, we have added you to the extremely
> low
> traffic <address@hidden> mailing list.  Here is the charter for that
> list:
> 
>      gnu-prog is a moderated list. Traffic is kept to the most essential
>      issues and the number of messages is kept minimal (at most a few a
>      month). The reason is that we wish all active GNU programmers and
>      maintainers to remain on it, including those who are only
> cooperating
>      with the FSF (because their program has been included in GNU. The
> FSF
>      doesn't want anyone unsubscribing because they find volume too
>      high. Many members of this list have indicated they wish the volume
>      kept low.
> 
>      Most inquiries should be directed to address@hidden
>      instead. The members of address@hidden list expect
> discussion
>      and lots of email.
> 
>      This list, address@hidden, is used to update all active GNU
>      programmers and maintainers on changes made in GNU project policy
> and
>      very occasionally query the community of active GNU programmers on
>      programming issues of great importance. Usually, though, a query
>      directly to address@hidden or address@hidden and/or a discussion on
>      address@hidden is sufficient.
> 
>      address@hidden should not be mentioned in other contexts. It is
> meant
>      to be a private mailing list. Please do not include it in mail sent
> to
>      those not on it.
> 
> You are welcome to be on <address@hidden>, if you'd like.  You
> can
> subscribe by sending a message to <address@hidden> or
> visiting http://mail.gnu.org/mailman/listinfo/gnu-prog-disscuss/.  Here's
> the charter for that list:
> 
>    gnu-prog-discuss is for those who would like to discuss issues of
>    programming that affect the GNU Project (e.g coding style or library
>    organization).
> 
>    gnu-prog-discuss should not be mentioned in other contexts. It is
> meant
>    to be an internal mailing list. Do not include it in mail sent to
> those
>    not on it.
> 
>    Also, gnu-prog-discuss automagically receives a unidiff of the GNU
> Coding
>    Standards, GNU Maintainers Guide, and related documents when changes
> are
>    made.
> 
> 
> Please let us know if you have any questions.
> 
> START-INFO-DIR-ENTRY
> * Maintaining: (maintain).        Maintaining GNU software.
> END-INFO-DIR-ENTRY
> 
> Information for maintainers of GNU software.  Copyright (C) 1992, 1993,
> 1994, 1995, 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc.
> 
> Permission is granted to make and distribute verbatim copies of this
> document, provided the copyright notice and this permission notice are
> preserved on all copies.
> 
> Version
> *******
> 
> Last updated November  9, 2000.
> 
> About This Document
> *******************
> 
> 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.
> 
> Please send corrections or suggestions for this document to
> <address@hidden>.  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 `maintain.texi' file, but
> if you don't have that file, you can make a context diff for some other
> version of this document, or propose it in any way that makes it clear.
> 
> This document uses the gender-neutral third-person pronouns "person",
> "per", "pers" and "perself" which were promoted, and perhaps invented,
> by Marge Piercy in `Woman on the Edge of Time'.  They are used just
> like "she", "her", "hers" and "herself", except that they apply equally
> to males and females.  For example, "Person placed 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."
> 
> The directory `/gd/gnuorg' is found on the GNU machines; if you are the
> maintainer of a GNU package, you should have an account on them.
> Contact <address@hidden> 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.)  `/gd/gnu/maintain.tar.gz' is a tar file containing all of
> these files in that directory which are mentioned in this file; it is
> updated daily.
> 
> This release of the GNU Maintenance Instructions was last updated
> November  9, 2000.
> 
> Stepping Down
> *************
> 
> With good forture, you will continue maintaining your package for many
> decades.  But sometimes for various reasons maintainers decide to step
> down.
> 
> If you're the official maintainer of a GNU package and you decide to
> step down, please inform the GNU Project (<address@hidden>).  We
> need to know that the package no longer has a maintainer, so we can
> look for and appoint a new maintainer.
> 
> If you have an idea for who should take over, please tell
> <address@hidden> your suggestion.  The appointment of a new
> maintainer needs the GNU Project's confirmation, but your judgement that
> a person is capable of doing the job will carry a lot of weight.
> 
> Recruiting Helpers
> ******************
> 
> Unless your package is a fairly small, you probably won't do all the
> work on it yourself.  Most maintainers recruit helpers, and often people
> offer to help.
> 
> Some of the people who offer to help will be capable, while others will
> not.  It's up to you to determine who provides useful help, and
> encourage those people to participate more.
> 
> Some of the people who offer to help will support the GNU Project, while
> others may be interested for other reasons.  Some will support the goals
> of the Free Software Movement, but some may not.  They are all welcome
> to help with the work--we don't ask people's views or motivations
> before they contribute to GNU packages.
> 
> As a consequence, you cannot expect all contributors to support the GNU
> Project, or to have a concern for its policies and standards.  So part
> of your job as maintainer is to exercise your authority on these points
> when they arise.  No matter how much of the work other people do, you
> and not they are in charge of what goes in the release.  When a crucial
> point arises, you should calmly state your decision and stick to it.
> 
> Sometimes a package has several co-maintainers who share the role of
> maintainer.  Unlike helpers, co-maintainers have actually been appointed
> jointly as the maintainers of the package, and they carry out the
> maintainer's functions together.  If you would like to propose some of
> your helpers as co-maintainers, please contact <address@hidden>.
> 
> Legal Matters
> *************
> 
> This chapter describes procedures you should follow for legal reasons
> as you maintain the program, to avoid legal difficulties.
> 
> Recording Contributors
> ======================
> 
> *Keep correct records of which portions were written by whom.* This is
> very important.
> 
> These records should say which files, or parts of files, were written by
> each person, and which files or portions were revised by each person.
> 
> But they don't need to be as detailed as a change log.  They 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 Register of Copyrights
> doesn't care what the text does, just who wrote or contributed to which
> parts.
> 
> You need not list someone who has contributed just a few lines (less
> than 15) of minor changes, but keep in mind that a series of minor
> changes can add up to a significant contribution that does need to be
> listed.
> 
> The list should also mention if certain files distributed in the same
> package are really a separate program.
> 
> For example, this would describe an early version of GAS:
> 
>      Dean Elsner   first version of all files except gdb-lines.c and
> m68k.c.
>      Jay Fenlason  entire files gdb-lines.c and m68k.c, most of app.c,
>                    plus extensive changes in messages.c, input-file.c,
> write.c
>                    and revisions elsewhere.
>      
>      Note: GAS is distributed with the files obstack.c and obstack.h, but
>      they are considered a separate package, not part of GAS proper.
> 
> Please keep these records in a file named `AUTHORS' in the source
> directory for the program itself.
> 
> Copyright Papers
> ================
> 
> If you maintain an FSF-copyrighted package, then you should follow
> certain legal procedures when incorporating changes written by other
> people.  This ensures that the FSF has the legal right to distribute the
> package, and the right to defend its free status in court if necessary.
> 
> *Before* incorporating significant changes, make sure that the person
> who wrote the changes has signed copyright papers and that the Free
> Software Foundation has received and signed them.
> 
> To check whether papers have been received, look in
> `/gd/gnuorg/copyright.list'.  If you can't look there directly,
> <address@hidden> can check for you.  Our clerk can also check for
> papers that are waiting to be entered and inform you when expected
> papers arrive.
> 
> The directory `/gd/gnuorg' is found on the GNU machines; if you are the
> maintainer of a GNU package, you should have an account on them.
> Contact <address@hidden> 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.)
> 
> In order for the contributor to know person should sign papers, you need
> to ask for the necessary papers.  If you don't know per well, and you
> don't know that person is used to our ways of handling copyright papers,
> then it might be a good idea to raise the subject with a message like
> this:
> 
>      Would you be willing to assign the copyright to the Free Software
>      Foundation, so that we could install it in PROGRAM?
> 
> or
> 
>      Would you be willing to sign a copyright disclaimer to put this
>      change in the public domain, so that we can install it in PROGRAM?
> 
> If the contributor wants more information, you can send per
> `/gd/gnuorg/conditions.text', which explains per options (assign 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
> `/gd/gnuorg'.  This section explains which templates you should use in
> which circumstances.  *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
> sure to get the current version of the template you will use!  We change
> these templates occasionally--don't keep using an old version.
> 
> For large changes, ask the contributor for an assignment.  Send per a
> copy of the file `/gd/gnuorg/request-assign.changes'.
> 
> For medium to small changes, request a disclaimer by sending per the
> file `/gd/gnuorg/request-disclaim.changes'.
> 
> If the contributor is likely to keep making changes, person might want
> to sign an assignment for all per future changes to the program.  So it
> is useful to offer per that alternative.  If person wants to do it that
> way, send per the `/gd/gnuorg/request-assign.future'.
> 
> When you send a `request-' file, you don't need to fill in anything
> before sending it.  Just send the file verbatim to the contributor.  The
> file gives per instructions for how to ask the FSF to mail per the
> papers to sign.
> 
> 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 NAME OF PERSON and NAME OF
> PROGRAM, before sending; otherwise person might sign without noticing
> them, and the papers would be useless.  Note that in some templates
> there is more than one place to put the name of the program or the name
> of the person; be sure to change all of them.
> 
> You do not need to ask for separate papers for a manual that is
> distributed only in the software package it describes.  But if we
> sometimes distribute the manual separately (for instance, if we publish
> it as a book), then we need separate legal papers for changes in the
> manual.  For smaller changes, use `/gd/gnuorg/disclaim.changes.manual';
> for larger ones, use `/gd/gnuorg/assign.changes.manual'.  To cover both
> past and future changes to a manual, you can use
> `/gd/gnuorg/assign.future.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
> should offer this alternative if it helps you reach agreement.  We
> prefer an assignment for a larger change, so that we can enforce the GNU
> GPL for the new text, but a disclaimer is enough to let us use the text.
> 
> If you maintain a collection of programs, occasionally someone will
> contribute an entire separate program or manual that should be added to
> the collection.  Then you can use the files `request-assign.program',
> `disclaim.program', `assign.manual', and `disclaim.manual'.  We very
> much prefer an assignment for a new separate program or manual, unless
> it is quite small, but a disclaimer is acceptable if the contributor
> insists on handling the matter that way.
> 
> *Although there are other templates besides the ones listed here, they
> are for special circumstances; please do not use them without getting
> advice from <address@hidden>.*
> 
> If you are not sure what to do, then please ask <address@hidden> for
> advice; if the contributor asks you questions about the meaning and
> consequences of the legal papers, and you don't know the answers, you
> can forward them to <address@hidden> and we will answer.
> 
> *Please do not try changing the wording of a template yourself.  If you
> think a change is needed, please talk with <address@hidden>, and we will
> work with a lawyer to decide what to do.*
> 
> Copyright Notices
> =================
> 
> You should maintain a legally valid copyright notice in each nontrivial
> file of the program, including makefiles, scripts, and other data files
> used in building or running the program.  (Any file more than ten lines
> long is nontrivial for this purpose.)  Documentation files also should
> have copyright notices.
> 
> A copyright notice looks like this:
> 
>      Copyright YEAR1, YEAR2, YEAR3  COPYRIGHT-HOLDER
> 
> The COPYRIGHT-HOLDER may be the Free Software Foundation, Inc., or
> someone else; you should know who is the copyright holder for your
> package.
> 
> The list of year numbers should include each year in which you finished
> preparing a version which was actually released, and which was an
> ancestor of the current version.
> 
> Please reread the paragraph above, slowly and carefully.  It is
> important to understand that rule precisely, much as you would
> understand a complicated C statement in order to hand-simulate it.
> 
> This list is _not_ a list of years in which versions were _released_.
> It is a list of years in which versions, later released, were
> _completed_.  So if you finish a version on Dec 31, 1994 and release it
> on Jan 1, 1995, this version requires the inclusion of 1994, but
> doesn't require the inclusion of 1995.
> 
> Do not abbreviate the year list using a range; do not write
> `1996--1998' instead of `1996, 1997, 1998'.
> 
> The versions that matter, for purposes of this list, are versions that
> were ancestors of the current version.  So if you made a temporary
> branch in maintenance, and worked on branches A and B in parallel, then
> each branch would have its own list of years, which is based on the
> versions released in that branch.  A version in branch A need not be
> reflected in the list of years for branch B, and vice versa.
> 
> However, if you copy code from branch A into branch B, the years for
> branch A (or at least, for the parts that you copied into branch B) do
> need to appear in the list in branch B, because now they are ancestors
> of branch B.
> 
> This rule is complicated.  If we were in charge of copyright law, we
> 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.
> 
> But if contributors are not all assigning their copyrights to a single
> copyright holder, it can easily happen that one file has several
> copyright holders.  Each contributor of nontrivial amounts is a
> copyright holder.
> 
> In that case, you should always include a copyright notice in the name
> of main copyright holder of the file.  You can also include copyright
> notices for other copyright holders as well, and this is a good idea for
> those who have contributed a large amount and for those who specifically
> ask for notices in their names.  But you don't have to include a notice
> for everyone who contributed to the file, and that would be rather
> inconvenient.
> 
> License Notices
> ===============
> 
> In each file that has a copyright notice or notices, a license notice
> _must_ follow.  (Without a license notice giving permission to copy and
> change the file, copying and modification are legally prohibited, and
> that would make the file non-free.)
> 
> Typically the license notice should look like this:
> 
>      This file is part of GNU PROGRAM
> 
>      GNU PROGRAM 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 2, or (at your
>      option) any later version.
> 
>      GNU PROGRAM 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 a copy of the GNU General Public License
>      along with PROGRAM; see the file COPYING.  If not, write to the
>      Free Software Foundation, Inc., 59 Temple Place - Suite 330,
>      Boston, MA 02111-1307, USA.
> 
> But in a small program which is just a few files, you can use this
> instead:
> 
>      This program 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 2 of the
>      License, or (at your option) any later version.
> 
>      This program 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 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.
> 
> Documentation files should have license notices also.  Manuals should
> use the GNU Free Documentation License.  Here is an example of the
> license notice to use after the copyright notice.  Please adjust the
> list of invariant sections as appropriate for your manual.  (If there
> are none, then say "with no invariant sections".)
> 
>      Permission is granted to copy, distribute and/or modify this
> document
>      under the terms of the GNU Free Documentation License, Version 1.1
> or
>      any later version published by the Free Software Foundation; with
> the
>      Invariant Sections being "GNU General Public License", the
> Front-Cover
>      texts being (a) (see below), and with the Back-Cover Texts being (b)
>      (see below).  A copy of the license is included in the section
> entitled
>      "GNU Free Documentation License".
>      
>      (a) The FSF's Front-Cover Text is:
>      
>           A GNU Manual
>      
>      (b) The FSF's Back-Cover Text is:
>      
>           You have freedom to copy and modify this GNU Manual, like GNU
>           software.  Copies published by the Free Software Foundation
> raise
>           funds for GNU development.
> 
> If the FSF does not publish this manual on paper, then omit the last
> sentence that talks about copies published by the FSF.  If the FSF is
> not the copyright holder, then replace `FSF' with the appropriate name.
> 
> Short manuals (under 300 lines long) and rough documentation can use
> simple all-permissive licenses.  But note that when you distribute
> several manuals together in one software package, they can share a
> single copy of the GFDL (see section 6).
> 
> If you would like help with license issues or with using the GFDL,
> please contact <address@hidden>.
> 
> External Libraries
> ==================
> 
> When maintaining an FSF-copyrighted GNU package, sometimes you will want
> to use a general-purpose free software module which offers a useful
> functionality, as a "library" facility (though the module is not always
> packaged technically as a library).
> 
> In a case like this, it would be unreasonable to ask the author of that
> module to assign the copyright to the FSF.  After all, person did not
> write it specifically as a contribution to your package, so it would be
> impertinent to ask him, out of the blue, "Please give the FSF your
> copyright."
> 
> So the thing to do in this case is to make your program use the module,
> but not consider it a part of your program.  There are two reasonable
> methods of doing this:
> 
>   1. Assume the module is already installed on the system, and use it
>      when linking your program.  This is only reasonable if the module
>      really has the form of a library.
> 
>   2. Include the module in your package, putting the source in a
>      separate subdirectory whose `README' file says, "This is not part
>      of the GNU FOO program, but is used with GNU FOO."  Then set up
>      your makefiles to build this module and link it into the
>      executable.
> 
>      For this method, it is not necessary to treat the module as a
>      library and make a `.a' file from it.  You can link with the `.o'
>      files directly in the usual manner.
> 
> Please use these methods as infrequently as possible, because they
> create an irregularity and we have been told to minimize the amount of
> irregularity.  So consider them only for general-purpose modules that
> were written for other uses and released separately.  For anything that
> was written as a contribution to your package, please get papers signed.
> 
> Cleaning Up Changes
> *******************
> 
> Don't feel obligated to include every change that someone asks you to
> include.  You must judge which changes are improvements--partly based
> on what you think the users will like, and partly based on your own
> judgement of what is an improverment.  If you think a change is not
> good, you should reject it.
> 
> If someone sends you a change which is useful, but written in an ugly
> way or hard to understand and maintain in the future, don't hesitate to
> ask person to clean up per changes before you merge them.  Since the
> amount of work we can do is limited, the more we convince others to help
> us work efficiently, the faster GNU will advance.
> 
> If the contributor will not or can not make the changes clean enough,
> then it is legitimate to say "I can't install this in its present form;
> I can only do so if you clean it up."  Invite per to distribute per
> changes another way, or to find other people to make them clean enough
> for you to install and maintain.
> 
> The only reason to do these cleanups yourself is if (1) it is easy, less
> work than telling the author what to clean up, or (2) the change is an
> important one, important enough to be worth the work of cleaning it up.
> 
> The GNU Coding Standards are a good thing to send people when you ask
> them to clean up changes (*note Contents: (standards)Top.).  The Emacs
> Lisp manual contains an appendix that gives coding standards for Emacs
> Lisp programs; it is good to urge authors to read it (*note Tips and
> Standards: (elisp)Tips.).
> 
> Dealing With Mail
> *****************
> 
> 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
> address@hidden', 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 name
> of the bug-reporting list in a prominent place, and ask users to help
> us by reporting bugs there.
> 
> We also have a catch-all list, <address@hidden>, 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 <bug-gnu-utils>.
> 
> If you are the maintainer of a GNU package, you should have an account
> on the GNU servers; contact <address@hidden> 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
> `/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.
> 
> But if you don't want to learn how to do those things, you can
> alternatively ask <address@hidden> to add you to the bug-reporting
> list for your program.  To set up a new list, contact
> <address@hidden>.  You can subscribe to a list managed by
> Mailman by sending mail to the corresponding `-request' address.
> 
> 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.
> 
> You don't have an obligation to give more response than that, though.
> The main purpose of bug reports is to help you contribute to the
> community by improving the next version of the program.  Many of the
> people who report bugs don't realize this--they think that the point is
> for you to help them individually.  Some will ask you to focus on that
> _instead of_ on making the program better.  If you comply with their
> wishes, you will have been distracted from the job of maintaining the
> program.
> 
> For example, people sometimes report a bug in a vague (and therefore
> useless) way, and when you ask for more information, they say, "I just
> wanted to see if you already knew the solution" (in which case the bug
> report would do nothing to help improve the program).  When this
> happens, you should explain to them the real purpose of bug reports.  (A
> canned explanation will make this more efficient.)
> 
> When people ask you to put your time into helping them use the program,
> it may seem "helpful" to do what they ask.  But it is much _less_
> helpful than improving the program, which is the maintainer's real job.
> 
> By all means help individual users when you feel like it, if you feel
> you have the time available.  But be careful to limit the amount of time
> you spend doing this--don't let it eat away the time you need to
> maintain the program!  Know how to say no; when you are pressed for
> 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.
> 
> Recording Old Versions
> **********************
> 
> 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; *Note
> Concepts of Version Control: (emacs)Concepts of VC.
> 
> Distributions
> *************
> 
> It is important to follow the GNU conventions when making GNU software
> distributions.
> 
> Distribution tar Files
> ======================
> 
> The tar file for version M.N of program `foo' should be named
> `foo-M.N.tar'.  It should unpack into a subdirectory named `foo-M.N'.
> Tar files should not unpack into files in the current directory,
> because this is inconvenient if the user happens to unpack into a
> directory with other files in it.
> 
> Here is how the `Makefile' for Bison creates the tar file.  This method
> is good for other programs.
> 
>      dist: bison.info
>              echo bison-`sed -e '/version_string/!d' \
>                -e 's/[^0-9.]*\([0-9.]*\).*/\1/' -e q version.c` > .fname
>              -rm -rf `cat .fname`
>              mkdir `cat .fname`
>              dst=`cat .fname`; for f in $(DISTFILES); do \
>                 ln $(srcdir)/$$f $$dst/$$f || { echo copying $$f; \
>                   cp -p $(srcdir)/$$f $$dst/$$f ; } \
>              done
>              tar --gzip -chf `cat .fname`.tar.gz `cat .fname`
>              -rm -rf `cat .fname` .fname
> 
> Source files that are symbolic links to other file systems cannot be
> installed in the temporary directory using `ln', so use `cp' if `ln'
> fails.
> 
> Using Automake is a good way to take care of writing the `dist' target.
> 
> Distribution Patches
> ====================
> 
> If the program is large, it is useful to make a set of diffs for each
> release, against the previous important release.
> 
> At the front of the set of diffs, put a short explanation of which
> version this is for and which previous version it is relative to.  Also
> explain what else people need to do to update the sources properly (for
> example, delete or rename certain files before installing the diffs).
> 
> The purpose of having diffs is that they are small.  To keep them
> small, exclude files that the user can easily update.  For example,
> exclude info files, DVI files, tags tables, output files of Bison or
> Flex.  In Emacs diffs, we exclude compiled Lisp files, leaving it up to
> the installer to recompile the patched sources.
> 
> When you make the diffs, each version should be in a directory suitably
> named--for example, `gcc-2.3.2' and `gcc-2.3.3'.  This way, it will be
> very clear from the diffs themselves which version is which.
> 
> If you use GNU `diff' to make the patch, use the options `-rc2P'.  That
> will put any new files into the output as "entirely 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 `patch''s `-Z' option.  For example, you could use the
> following Bourne shell command to create the patch:
> 
>      LC_ALL=C TZ=UTC0 diff -rc2P gcc-2.3.2 gcc-2.3.3 | \
>      gzip -9 >gcc-2.3.2-2.3.3.patch.gz
> 
> If the distribution has subdirectories in it, then the diffs probably
> include some files in the subdirectories.  To help users install such
> patches reliably, give them precise directions for how to run patch.
> For example, say this:
> 
>      To apply these patches, cd to the main directory of the program
>      and then use `patch -p1'.   `-p1' avoids guesswork in choosing
>      which subdirectory to find each file in.
> 
> 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.
> 
> Distribution on `ftp.gnu.org'
> =============================
> 
> GNU packages are distributed through directory `/gnu' on `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.
> 
> Only the latest version of any program needs to be on `ftp.gnu.org'.
> Being an archive of old versions is not the function of `ftp.gnu.org'.
> 
> Diffs are another matter.  Since they are much smaller than
> distribution files, it is good to keep the diffs around for quite a
> while.
> 
> Please talk with <address@hidden> in regard to putting new versions
> on `ftp.gnu.org'.
> 
> Test Releases
> =============
> 
> 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 `alpha.gnu.org' for pretests and prerelease versions.
> 
> 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"
> release.
> 
> If you are about to release version 4.6 but you want to do a pretest
> first, call it 4.5.90.  If you need a second pretest, call it 4.5.91,
> and so on.  If you are really unlucky and ten pretests are not enough,
> after 4.5.99 you could advance to 4.5.990 and so on.
> 
> One thing that you should never do is to release a pretest with the same
> version number as the planned real release.  Many people will look only
> at the version number (in the tar file name, in the directory name that
> it unpacks into, or wherever they can find it) to determine whether a
> tar file is the latest version.  People might look at the test release
> in this way and mistake it for the real release.  Therefore, always
> change the number when you release changed code.
> 
> Announcing Releases
> *******************
> 
> When you have a new release, please make an announcement.  You can
> maintain your own mailing list for announcements if you like, or you can
> use the moderated general GNU announcements list, <address@hidden>.
> 
> If you use your own list, you can decide as you see fit what events are
> worth announcing.  If you use <address@hidden>, please do not
> announce pretest releases, only real releases.  But real releases do
> include releases made just to fix bugs.
> 
> Web Pages
> *********
> 
> Please write pages about your package for installation `www.gnu.org'.
> The pages should follow our usual standards for web pages (see
> <http://www.gnu.org/server>); we chose them in order to support a wide
> variety of browsers, to focus on information rather than flashy eye
> candy, and to keep the site simple and uniform.
> 
> Please talk with <address@hidden> about the arrangements for
> installing and updating pages.  There are various ways this can be done:
> you can mail them pages to install, they can make an account for you, or
> you can keep the pages in CVS on `subversions.gnu.org' and have them
> automatically checked out into the web server.
> 
> 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 `www.gnu.org'.  However, pages that access
> databases (such as mail logs or bug tracking) are an exception; set them
> up wherever is convenient for you, and the pages on `www.gnu.org' can
> link to them.
> 
> Terminology Issues
> ******************
> 
> This chapter explains a couple of issues of terminology which are
> important for correcting two widespread and important misunderstandings
> about GNU.
> 
> 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
> <http://www.gnu.org/philosophy/free-software-for-freedom.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 _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 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.
> 
> GNU and Linux
> =============
> 
> The GNU Project was formed to develop a free Unix-like operating system,
> GNU.  The existence of this system is our major accomplishment.
> However, the widely used version of the GNU system, in which Linux is
> used as the kernel, is often called simply "Linux".  As a result, most
> users don't know about the GNU Project's major accomplishment--or more
> 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."
> 
> To correct this confusion, we have made a years-long effort to
> distinguish between Linux, the kernel that Linus Torvalds wrote, and
> GNU/Linux, the operating system that is the combination of GNU and
> Linux.  The resulting increased awareness of what the GNU Project has
> already done helps every activity of the GNU Project recruit more
> support and contributors.
> 
> Please make this distinction consistently in GNU software releases, GNU
> documentation, and announcements and articles that you publish in your
> role as the maintainer of a GNU package.  If you want to explain the
> terminology and its reasons, you can refer to the URL
> <http://www.gnu.org/gnu/linux-and-gnu.html>.
> 
> Hosting
> *******
> 
> We would like to recommend using `subversions.gnu.org' as the CVS
> repository for your package, and using `ftp.gnu.org' as the standard
> FTP site.  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:
> 
>      The programs <list of them> Z hosted here are free software packages
>      of the GNU Project, not products of <company name>.  We call them
>      "free software" because you are free to copy and redistribute them,
>      following the rules stated in the license of each package.  For more
>      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.
>      
>      If you would like to contribute to the development of one of these
>      packages, contact the package maintainer or the bug-reporting
> address
>      of the package (which should be listed in the package itself), or
> look
>      on www.gnu.org for more information on how to contribute.
> 
> Free Software Directory
> ***********************
> 
> The Free Software Directory aims to be a complete list of free software
> packages, within certain criteria.  Every GNU package should be listed
> there, so please contact <address@hidden> to ask for information
> on how to write an entry for your package.
> 
> Using the Proofreaders List
> ***************************
> 
> If you want help finding errors in documentation, or help improving the
> quality of writing, or if you are not a native speaker of English and
> want help producing good English documentation, you can use the GNU
> proofreaders mailing list: <address@hidden>.
> 
> But be careful when you use the list, because there are over 200 people
> on it.  If you simply ask everyone on the list to read your work, there
> will probably be tremendous duplication of effort by the proofreaders,
> and you will probably get the same errors reported 100 times.  This
> must be avoided.
> 
> Also, the people on the list do not want to get a large amount of mail
> from it.  So do not ever ask people on the list to send mail to the
> list!
> 
> Here are a few methods that seem reasonable to use:
> 
>    * For something small, mail it to the list, and ask people to pick a
>      random number from 1 to 20, and read it if the number comes out as
>      10.  This way, assuming 50% response, some 5 people will read the
>      piece.
> 
>    * For a larger work, divide your work into around 20 equal-sized
>      parts, tell people where to get it, and ask each person to pick
>      randomly which part to read.
> 
>      Be sure to specify the random choice procedure; otherwise people
>      will probably use a mental procedure that is not really random,
>      such as "pick a part near the middle", and you will not get even
>      coverage.
> 
>      You can either divide up the work physically, into 20 separate
>      files, or describe a virtual division, such as by sections (if
>      your work has approximately 20 sections).  If you do the latter,
>      be sure to be precise about it--for example, do you want the
>      material before the first section heading to count as a section,
>      or not?
> 
>    * For a job needing special skills, send an explanation of it, and
>      ask people to send you mail if they volunteer for the job.  When
>      you get enough volunteers, send another message to the list saying
>      "I have enough volunteers, no more please."
> 
> Index
> *****
> 
> /gd/gnuorg directory:
>           See ``Copyright Papers''.
> alpha.gnu.org, ftp site for test releases:
>           See ``Test Releases''.
> AUTHORS file:
>           See ``Recording Contributors''.
> automake:
>           See ``Distribution tar Files''.
> beta releases:
>           See ``Test Releases''.
> bug reports:
>           See ``Dealing With Mail''.
> contributions, accepting:
>           See ``Cleaning Up Changes''.
> copyright notices in program files:
>           See ``Copyright Notices''.
> copyright papers:
>           See ``Copyright Papers''.
> CVS repository:
>           See ``Hosting''.
> data base of GNU copyright assignments:
>           See ``Copyright Papers''.
> diff:
>           See ``Distribution Patches''.
> distribution, tar files:
>           See ``Distribution tar Files''.
> email, for receiving bug reports:
>           See ``Dealing With Mail''.
> free software:
>           See ``Free Software and Open Source''.
> Free Software Directory:
>           See ``Free Software Directory''.
> FTP site:
>           See ``Hosting''.
> ftp.gnu.org, the GNU ftp site:
>           See ``Distribution on `ftp.gnu.org'''.
> GNU ftp site:
>           See ``Distribution on `ftp.gnu.org'''.
> GNU/Linux:
>           See ``GNU and Linux''.
> hosting:
>           See ``Hosting''.
> legal matters:
>           See ``Legal Matters''.
> legal papers for changes in manuals:
>           See ``Copyright Papers''.
> license notices in program files:
>           See ``License Notices''.
> Linux:
>           See ``GNU and Linux''.
> mailing list for bug reports:
>           See ``Dealing With Mail''.
> movements, Free Software and Open Source:
>           See ``Free Software and Open Source''.
> open source:
>           See ``Free Software and Open Source''.
> patch:
>           See ``Distribution Patches''.
> patches, against previous releases:
>           See ``Distribution Patches''.
> pretest releases:
>           See ``Test Releases''.
> proofreading:
>           See ``Using the Proofreaders List''.
> quality of changes suggested by others:
>           See ``Cleaning Up Changes''.
> recording contributors:
>           See ``Recording Contributors''.
> repository:
>           See ``Hosting''.
> responding to bug reports:
>           See ``Dealing With Mail''.
> terminology:
>           See ``Terminology Issues''.
> test releases:
>           See ``Test Releases''.
> time stamp in diffs:
>           See ``Distribution Patches''.
> version control:
>           See ``Recording Old Versions''.
> web pages:
>           See ``Web Pages''.
> Table of Contents
> *****************
> 
> 
> Version
> 
> About This Document
> 
> Stepping Down
> 
> Recruiting Helpers
> 
> Legal Matters
>   Recording Contributors
>   Copyright Papers
>   Copyright Notices
>   License Notices
>   External Libraries
> 
> Cleaning Up Changes
> 
> Dealing With Mail
> 
> Recording Old Versions
> 
> Distributions
>   Distribution tar Files
>   Distribution Patches
>   Distribution on `ftp.gnu.org'
>   Test Releases
> 
> Announcing Releases
> 
> Web Pages
> 
> Terminology Issues
>   Free Software and Open Source
>   GNU and Linux
> 
> Hosting
> 
> Free Software Directory
> 
> Using the Proofreaders List
> 
> Index
> 
> 
>