Finished section 3 on interacting with developers.. just one more

[fspm_howto] / FreeSoftwareProjectManagementHOWTO.sgml

diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml
index a04bac678fa2f7c8c5daebe4b1c54252774a183b..ad8e78fca92668f97ad78843d822a183b00189c9 100644 (file)
--- a/FreeSoftwareProjectManagementHOWTO.sgml
+++ b/FreeSoftwareProjectManagementHOWTO.sgml
@@ -10,7 +10,7 @@
   <author>
      <firstname>Benjamin</firstname>
      <othername>Mako</othername>
   <author>
      <firstname>Benjamin</firstname>
      <othername>Mako</othername>

-     <surnamen>Hill</surname>
+     <surname>Hill</surname>

      <affiliation>
         <address>
            <email>mako@debian.org</email>
      <affiliation>
         <address>
            <email>mako@debian.org</email>


@@ -22,7 +22,7 @@
    <revhistory>
       <revision>
          <revnumber>v0.01</revnumber>
    <revhistory>
       <revision>
          <revnumber>v0.01</revnumber>

-         <date>1 January 2001</date>
+         <date>25 March 2001</date>

          <authorinitials>bch</authorinitials>
           <revremark>
          Initial Release
          <authorinitials>bch</authorinitials>
           <revremark>
          Initial Release


@@ -118,11 +118,9 @@
    <title>Copyright Information</title>
 
    <para>
    <title>Copyright Information</title>
 
    <para>

-    This document is copyrighted (c) 2000 Stein Gjoen and is
+    This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is

     distributed under the terms of the Linux Documentation Project
     distributed under the terms of the Linux Documentation Project

-    (LDP) license, stated below.  <emphasis>Replace with your name,
-    or supply a new license, when you use this skeleton for a new
-    HOWTO.</emphasis>
+    (LDP) license, stated below.

    </para>
 
    <para>
    </para>
 
    <para>


@@ -208,9 +206,9 @@
    </para>
 
    <para>
    </para>
 
    <para>

-    The latest version number of this document should always be listed 
-    at my webpage at<ulink url="http://people.debian.org/~mako/">
-    http://people.debian.org/~mako/</unlink> Debian.
+    The latest version number of this document should always be listed
+    on <ulink url="http://people.debian.org/~mako/">my webpage at
+    Debian</ulink>.

    </para>
 
    <para>
    </para>
 
    <para>


@@ -253,6 +251,7 @@
     </listitem>
    </itemizedlist>
    </para>
     </listitem>
    </itemizedlist>
    </para>

+  </sect2>

 
 <!-- Section2: credits -->
 
 
 <!-- Section2: credits -->
 


@@ -320,7 +319,7 @@
     development process that it heralds and I think its ultimate
     success will be rooted in this fact. Please send your additions,
     comments and criticisms to the following email address :
     development process that it heralds and I think its ultimate
     success will be rooted in this fact. Please send your additions,
     comments and criticisms to the following email address :

-    <email>mako (at) debian (dot) org</email>.
+    <email>mako@debian. org</email>.

    </para>
    </sect2>
 
    </para>
    </sect2>
 


@@ -340,8 +339,7 @@
     available. If you would like to help with or do a translation, you
     will gain my utmost respect and admiration and you'll get to be
     part of a cool process. If you are at all interested, please don't
     available. If you would like to help with or do a translation, you
     will gain my utmost respect and admiration and you'll get to be
     part of a cool process. If you are at all interested, please don't

-    hesitate to contact me at: <email>mako (at) debian (dot)
-    org</email>.
+    hesitate to contact me at: <email>mako@debian.org</email>.

    </para>
    </sect2>
  </sect1>
    </para>
    </sect2>
  </sect1>


@@ -356,1096 +354,1477 @@
    <indexterm>
     <primary>fswd!starting</primary>
    </indexterm>
    <indexterm>
     <primary>fswd!starting</primary>
    </indexterm>

+  <para>
+   With very little argument, starting a project is most difficult
+   part of successful free software development. Laying a firm
+   foundation for your project will determine whether your project
+   flourishes or withers away and dies. It is also the subject that is
+   of most immediate interest to anyone reading this document as a
+   tutorial.
+  </para>
+
+  <para>
+   Starting a project also involves a dilemna that you as a developer
+   must try and deal with. No potential user for your program will be
+   interested by a program that doesn't work. Simultaneously, the
+   development process that you want to employ holds involvement of
+   users as essential to the process of the development that will
+   realize this working software.
+  </para>
+
+  <para>
+   It is in these dangerous initial moments that anyone working to
+   start a free software project must strike a balance. One of the
+   most important ways that omeone trying to start a project can work
+   towards this balance is by establishing a framework for the
+   development process through some of the ways mentioned in this
+   section.
+  </para>

 
 
 <!-- Section2: chooseproject-->
 
   <sect2 id="chooseproject">
    <title>Choosing a Project</title>
 
 
 <!-- Section2: chooseproject-->
 
   <sect2 id="chooseproject">
    <title>Choosing a Project</title>

-  </sect2>

 
 

-<!-- Section2: chooselicense-->
+   <para>
+    If you are reading this document, there's a good chance you
+    already have an idea for a project in mind. Chances are pretty
+    good, it fills a gap by doing something that no other free
+    software process does or or does it in a way that is unique
+    enought to necessitate a seperate project.
+   </para>

 
 

-  <sect2 id="chooselicense">
-   <title>Deciding on a License</title>
-  </sect2>
+   <sect3 id=identifyidea>
+    <title>Indentify and articulate your idea</title>
+    <para>
+     Eric S. Raymond writes about how free software projects start in
+     his paper, "The Cathedral and the Bazaar" which comes as required
+     reading for any free softare development. You can find it <ulink
+     url="http://www.tuxedo.org/!esr/writings/cathedral-bazaar/">online
+     </ulink>.
+    </para>

 
 

-<!-- Section2: chooseversioning-->
+    <para>
+     In "The Cathedral and Bazaar," Raymond tells us that:
+     <emphasis>Every good work of software starts by scratching a
+     developers itch.</emphasis> Raymond now widely accepted
+     hypothesis is that new free software programs are written, first
+     and foremost, to solve a specific problem facing the developer.
+    </para>

 
 

-  <sect2 id="chooseversioning">
-   <title>Choosing a Method of Version Numbering</title>
-  </sect2>
+    <para>
+     If you have an idea for a program in mind, chances are good that
+     it it is targetting a specific problem or itch you want to see
+     scratched. <emphasis>This idea is the project. Articulate it
+     clearly. Write it out. Describe the problem you will attack in
+     detail. The success of your project in tackling a particular
+     problem will be tied to your ability to identify that problem
+     early on. Find out exactly what it is that you want your project
+     to do.</emphasis>
+    </para>
+   </sect3>

 
 

-<!-- Section2: documentation-->
+   <sect3 id=evalulateidea>
+    <title>Evaluate your idea</title>

 
 

-  <sect2 id="documentation">
-   <title>Documentation</title>
-  </sect2>
+    <para>
+     In evaluating your idea, you need to ask yourself questions.
+     Before you move any further into this HOWTO, you need to
+     determine if the free software development model really is the
+     right one for your project. Obviously, since the program
+     scratches your itch, you are definately interested in seeing it
+     implemented in code. But, because one hacker coding alone fails
+     to qualify as a free software development effort, you need to ask
+     yourself the question: <emphasis>Is anybody else
+     interested?</emphasis>
+    </para>

 
 

-<!-- Section2: presentation -->
+    <para>
+     Sometimes the answer is <emphasis>no</emphasis>. If you want to
+     write a set of scripts to sort <emphasis>your</emphasis> MP3
+     collection on your machine, maybe the free software development
+     model is not the best one to choose. However, if you want to
+     write a set of scripts to sort <emphasis>anyone's</emphasis>
+     MP3s, a free software project might fill a useful gap.
+    </para>

 
 

-  <sect2 id="presentation">
-   <title>Other Presentation Issues</title>
-  </sect2>
+    <para>
+     Luckily, The Internet is a place so big and diverse that, chances
+     are, there is someone, somewhere, who shares your interests and
+     how feels the same itch. It is the fact that there are so many
+     people with so many similar needs and desires that introduces the
+     second major question: <emphasis>Has somebody already had your
+     idea or a reasonably similar one?</emphasis>
+    </para>
+
+     <sect4 id=evalwhere>
+      <title>Finding Similar Projects</title>
+
+     <para>
+      There are places you can go on the web to try and answer this
+      question. If you have experience with the free software
+      community, you are probably already familiar with all of these
+      sites. All of the resources listed bellow offer searching of
+      their databases:
+     </para>
+
+     <para>
+     <variablelist>
+       <varlistentry>
+        <term>freshmeat.net:</term>
+        <listitem>
+        <para><ulink url="http://freshmeat.net">freshmeat</ulink>
+        describes itself as, <quote>the Web's largest index of Linux
+        and Open Source software</quote> and its reputation along
+        these lines remains unquestioned. If you can't find it on
+        freshmeat, its doubtful that you'll find it indexed anywhere
+        else.</para>
+        </listitem>
+       </varlistentry>
+
+       <varlistentry>
+        <term>Slashdot:</term>
+        <listitem>
+        <para><ulink url="http://slashdot.org">Slashdot</ulink>
+        provides <quote>News for Nerds: Stuff that Matters,</quote>
+        which usually includes discussion of free software, open
+        source, technology, and geek culture new and events. It is
+        not unusual for an particularly sexy develpment effort to be
+        announced here so it definately worth checking.</para>
+        </listitem>
+       </varlistentry>
+
+       <varlistentry>
+        <term>SourceForge:</term>
+        <listitem>
+        <para><ulink url="http://sourceforge.net">SourceForge</ulink>
+        houses and facilitates a growning number of open source and
+        free software projects, SourceForge is quickly becoming a
+        nexus and an necessary stop for free software
+        developers. SourceForge's <ulink
+        url="http://sourceforge.net/softwaremap/trove_list.php">software
+        map</ulink> and <ulink url="http://sourceforge.net/new/"> new
+        releases</ulink> pages. should be necessary stops before
+        embarking on a new free software project. SourceForge also
+        provides a at <ulink
+        url="http://sourceforge.net/snippet/">Code Snippet
+        Library</ulink> which contains useful reusuable chunks of
+        code in an array of langauges which can come in useful in any
+        project.</para>
+        </listitem>
+       </varlistentry>
+
+       <varlistentry>
+        <term>Google and Google's Linux Search:</term>
+        <listitem>
+        <para><ulink url="http://www.google.com">Google</ulink> and
+        <ulink url="http://www.google.com/linux"> Google's Linux
+        Search</ulink>, provide powwerful web searches that may
+        reveal people working on similar projects. It is not a
+        catalog of software or news like freshmeat or Slashdot, but
+        it is worth checking before you begin pouring your effort
+        into a redundant project.</para>
+        </listitem>
+       </varlistentry>
+
+      </variablelist>
+     </para>
+    </sect4>
+
+    <sect4 id=evalhow>
+     <title>Deciding to Proceed</title>
+     <para>
+      Once you have successfull charted the terrain and have an idea
+      bout what kinds of similar free software projects exist, every
+      developer needs to decide whether to proceed with their own
+      project. It is rare that a new project seeks to accomplish a
+      goal that is not similar to related to the goal of another
+      project. Anyone starting a new project needs to ask themselves:
+      <emphasis>Will the new project be duplicating work done by
+      another project? Will the new project be competing for
+      developers with an existing project? Can the goals of the new
+      project be accomplished by adding functionality to an existing
+      project?</emphasis>
+     </para>

 
 

-<!-- Section2: futuredev -->
+     <para>
+      If the answer to any of these questions is yes, try to contact
+      the developer of the existing project in question and see if he
+      or she might be willing to collaborate with you.
+     </para>
+
+     <para>
+      This may be the single most difficult aspect of free software
+      development for many developers but it is essential. It is easy
+      to become fired up by and idea and be caught up in the momentum
+      and excitement of a new project. It is often extremely difficult
+      but it is important that any free software developer rememeber
+      that the best interests of the of the free software community
+      and the quickest way to accomplish ones own project's goals and
+      the goals of similar project can often be accomplished by
+      <emphasis>not</emphasis> starting a new project.
+     </para>

 
 

-  <sect2 id="futuredev">
-   <title>Nuturing Future Development</title>
+    </sect4>
+   </sect3>

   </sect2>
 
   </sect2>
 

- </sect1>
+<!-- Section2: licensing-->

 
 

-<!-- Section1: starting: END -->
+  <sect2 id="licensing">
+   <title>Licensing your Software</title>
+   
+   <para>
+    On one level, the difference between a piece of free software and
+    a piece of propriety software is the license. A license helps both
+    you as the developer by protecting your legal rights to your
+    software and helps demonstrate to those who wish to help you or
+    your project that they are encouraged to join.
+   </para>
+   
+   <sect3 id="chooselicense">
+    <title>Choosing a license</title>

 
 

-<!-- Section1: developers -->
+    <para>
+     Any discussion of licenses is also sure to generate at least a
+     small flamewar as there are strong feelings that some free
+     software licenses are better than other free software
+     licenses. This discussion also brings up the question of
+     <quote>Open Source Software</quote> and the debate around
+     <quote>Open Source Software</quote> and <quote>Free
+     Software</quote>. However, because I've written the Free Software
+     Development HOWTO and not the Open Source Development HOWTO, my
+     own allegiences in this argument are out in the open.
+    </para>

 
 

- <sect1 id="developers">
-  <title>Maintaining a Project: Interacting with Developers</title>
+    <para>
+     In attempting to reach a middle ground, I recommend picking any
+     license that conforms to the <ulink
+     url="http://www.debian.org/social_contract">Debian Free Software
+     Guidlines</ulink>. Examples of these licenses are the
+     <acronym>GPL</acronym>, the <acronym>BSD</acronym>, and the
+     Artistic License. Conforming to the definition of Free Software
+     offered by Richard Stallman in <ulink
+     url="http://www.gnu.org/philosophy/free-sw.html">The Free
+     Software Definition</ulink>, any of these licenses will
+     uphold,<quote> users' freedom to run, copy, distribute, study,
+     change and improve the software.</quote> There are other licenses
+     as well but sticking with a more common license will offer the
+     advantage of immediate recognition and undestanding.
+    </para>

 
 

-   <indexterm>
-    <primary>fswd!developers</primary>
-   </indexterm>
+    <para>
+     In attempting a more in-depth analysis, I agree with Karl Fogel's
+     description of licenses as falling into two groups: those that
+     are the <acronym>GPL</acronym> and those that are not the
+     <acronym>GPL</acronym>.
+    </para>

 
 

-<!-- Section2: delegation  -->
+    <para>
+     Personally, I license all my software under the
+     <acronym>GPL</acronym>. Created and protected by the Free
+     Software Foundation and the GNU Project, the
+     <acronym>GPL</acronym> is the license for the Linux kernel,
+     GNOME, Emacs, and the majority of Linux software. Its an easy
+     choice but I believe it is a good one. <emphasis>However, there
+     is a viral aspect to the <acronym>GPL</acronym>that prevents the
+     mixture of <acronym>GPL</acronym>'ed code with
+     non-<acronym>GPL</acronym>'ed code. To many people (myself
+     included), this is a benefit, but to some, it is a major
+     drawback.</emphasis>
+    </para>

 
 

-  <sect2 id="delegation">
-   <title>Delegating Work</title>
-  </sect2>
+    <para>
+     The three major license can be found at the following locations:
+    </para>

 
 

-<!-- Section2: branches  -->
+    <para>
+     <itemizedlist>
+      <listitem>
+       <para><ulink url="http://www.gnu.org/copyleft/gpl.html">The GNU
+       General Public License</ulink></para>
+      </listitem>
+      <listitem>
+       <para><ulink url="http://www.debian.org/misc/bsd.license">The
+       BSD License</ulink></para>
+      </listitem>
+      <listitem>
+       <para><ulink
+       url="http://language.perl.com/misc/Artistic.html">The Artistic
+       License</ulink></para>
+      </listitem>
+     </itemizedlist>
+    </para>

 
 

-  <sect2 id="branches">
-   <title>Stable and Development Branches</title>
-  </sect2>
+    <para>
+     <emphasis>In all cases, please read through any license before
+     your release your software. As the developer, you can't afford
+     any license surprises.</emphasis>
+    </para>
+   </sect3>

 
 

-<!-- Section2: freezing -->
+   <sect3 id="licensechoose">
+    <title>The mechanics of licensing</title>

 
 

-  <sect2 id="freezing">
-   <title>Freezing</title>
-  </sect2>
+    <para>
+     The text of the <acronym>GPL</acronym> offers <ulink
+     url="http://www.gnu.org/copyleft/gpl.html#SEC4">a good
+     description</ulink> of mechanics of applying a license to a piece
+     of software. A checklist for applying a license would include:
+    </para>

 
 

-<!-- Section2: codecram -->
+    <para>
+    <orderedlist>
+      <listitem>

 
 

-  <sect2 id="codecram">
-   <title>Avoiding the Code Cram Effect</title>
-  </sect2>
+       <para>If at all possible, attach and distribute a full copy of
+       the license with the source and binary in a seperate
+       file.</para>

 
 

-<!-- Section2: patching -->
+      </listitem>
+      <listitem>

 
 

-  <sect2 id="patching">
-   <title>Accepting and Rejecting Patches</title>
-  </sect2>
- </sect1>
+       <para>At the top of each source file in your program, attach a
+       notice of copyright and information on where the full license
+       can be found. The <acronym>GPL</acronym> recommends that each
+       file begin with:</para>

 
 

-<!-- Section1: users -->
+       <screen>
+<emphasis>one line to give the program's name and an idea of what it does.</emphasis>
+Copyright (C) yyyy  name of author

 
 

- <sect1 id="users">
-  <title>Maintaining a Project: Interacting with Users</title>
+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.

 
 

-   <indexterm>
-    <primary>fswd!users</primary>
-   </indexterm>
+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.
+       </screen>

 
 

-<!-- Section2: announcing  -->
+       <para>
+        The <acronym>GPL</acronym> goes on to recommend attaching
+        information on contacting you (the author) via email or
+        physical mail.
+      </para>

 
 

-  <sect2 id="announcing">
-   <title>Announcing Your Project</title>
-  </sect2>
+      </listitem>
+      <listitem>

 
 

-<!-- Section2: testing -->
+       <para>
+        The <acronym>GPL</acronym> continues and suggests that if your
+        program runs in an interactive mode, you should have the
+        program output a notice each time it enters interactive mode
+        that includes a message like this one that points to more
+        information about the programs licensing:
+       </para>

 
 

-  <sect2 id="testing">
-   <title>Testing and Testers</title>
-  </sect2>
-</sect1>
+       <screen>
+Gnomovision version 69, Copyright (C) year name of author
+Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
+type `show w'.  This is free software, and you are welcome
+to redistribute it under certain conditions; type `show c' 
+for details.
+       </screen>
+
+      </listitem>
+      <listitem>
+       <para>Finally, it might be helpful to include a
+       <quote>copyright disclaimer</quote> with the program from an
+       employer or a school if you work as a programmer or if it seems
+       like your employer or school might be able to make an argument
+       for ownership of your code.</para>
+      </listitem>

 
 

-<!-- Section1: samples  -->
+     </orderedlist>
+     </para>    
+   </sect3>

 
 

- <sect1 id="samples">
-  <title>Samples</title>
+   <sect3 id="licensewarning">
+    <title>Final license warning</title>

 
 

-  <para>
-   <emphasis>This section gives some simple SGML examples you could
-   use. Read the SGML source to see how it was done.</emphasis>
-  </para>
+    <para>
+     Please, please, please, place your software under some
+     license. It may not seem important, and to you, it may not be,
+     but licenses are important. For a piece of software to be
+     included in the Debian GNU/Linux distrobution, it must have a
+     license that fits the <ulink
+     url="http://www.debian.org/social_contract">Debian Free Software
+     Guidelines</ulink>. If you have no license, your program can be
+     distributed in part of Debian until you rerelease it under a free
+     license. Please save yourself and others trouble by releasing the
+     first version of your software with a clear license.
+    </para>

 
 

-  <para>
-   Further information and examples can be obtained from the publication
-   <ulink url="http://docbook.org/tdg/html/">DocBook: The Definitive 
-   Guide</ulink>. Written by <emphasis>Norman Walsh</emphasis>
-   and <emphasis>Leonard Muellner</emphasis>; 1st Edition, October 1999.
-  </para>
-  
-<!-- Section2: lists -->
+   </sect3>

 
 

-  <sect2 id="lists">
-   <title>Lists</title>
+ </sect2>

 
 

+<!-- Section2: chooseversioning-->
+
+  <sect2 id="chooseversioning">
+   <title>Choosing a Method of Version Numbering</title>

    <para>
    <para>

-    <emphasis>Lists are used frequently, and are available in a number
-    of formats shown below.</emphasis>
+    <emphasis>The most important thing about a system of numbering is
+    that there is one.</emphasis> It may seem pedantic to emphasize
+    this point but you'd be surprised at the number of scripts and
+    small programs that pop up without any version number. 

    </para>
 
    <para>
    </para>
 
    <para>

-    A list in which each entry is marked with a bullet or other dingbat:
+    <emphasis>The second most important thing about a system of
+    numbering is that the numbers always go up.</emphasis> Automatic
+    versioning systems and people's sense of order in the universe
+    will fall apart if version numbers don't rise. It doesn't
+    <emphasis>really</emphasis> matter if 2.1 is a big jump and
+    2.0.005 is a small jump but it does matter that 2.1 is more recent
+    than 2.0.005.

    </para>
 
    <para>
    </para>
 
    <para>

-    <itemizedlist>
+    Follow these two rules and you will not go wrong. Still there are
+    several versioning system that are well known, useful, and that
+    might be worth looking into before you release your first version.
+   </para>

 
 

+   <variablelist>
+    <varlistentry>
+     <term>Linux kernel version numbering:</term>

      <listitem>
      <listitem>

-      <para>Apples</para>
-     </listitem>
+      <para>The Linux kernel uses a versioning system where the any
+      minor odd minor version number refers to an development or
+      testing release and any even minor version number refers to a
+      stable version. Under this system, 2.1 and 2.3 kernels were and
+      always will be development and testing kernels and 2.0, 2.2. and
+      2.4 kernels are all production code with a higher degree of
+      stability.
+     </para>

 
 

-     <listitem>
-      <para>Oranges</para>
-     </listitem>
+      <para>
+       Whether you plan on having a split development model (as
+       described in <xref linkend="branches">) or only one version
+       released at a time, my experience with several free software
+       projects and with the Debian project has taught me taht use of
+       Linux's version numbering system is worth taking into
+       consideration. In Debian, all minor versions are stable
+       distributions (2.0, 2.1, etc). However, many people assume that
+       2.1 is an unstable or development version and continue to use
+       an older version until they get so frusterated with the lack of
+       development and progress that they complain. If you never
+       release an odd minor version but only release even ones, nobody
+       is hurt, and less people are confused.
+      </para>

 
 

-     <listitem>
-      <para>Bananas</para>

      </listitem>
      </listitem>

+    </varlistentry>
+    <varlistentry>
+     <term>Wine version numbering:</term>
+     <listitem>
+      <para>Because of the unusual nature of wine's development where
+      it constantly improving but not working towards any immediately
+      achievable goal, wine is released every three weeks. Wine does
+      this by versioning their releases in Year Month Day format where
+      each release might be labeled <quote>wine-XXXXXXXX</quote> where
+      the version from Janurary 04, 2000 would be
+      <quote>wine-20000104</quote>. For certain projects, Year Month
+      Day format can make a lot of sense.
+      </para>

 
 

-    </itemizedlist>
-   </para>
+     </listitem>
+    </varlistentry>
+    <varlistentry>
+     <term>Mozilla milestones:</term>
+     <listitem>
+      <para>When one considers Netscape 6 and verdor versions, the
+      mozilla's project development structure is one of the most
+      complex free software model available. Their version numbering
+      has reflected the unique situation in which it is
+      developed.
+      </para>

 
 

-   <para>
-    A list in which each entry is composed of a set of one or more
-    terms and an associated description:
-   </para>
+      <para>
+       Mozilla's development structure has historically been made up
+       of milestones. From teh beginning of the mozilla project, the
+       goals of the project in the order and degree to which they were
+       to be achieved were charted out on a series of <ulink
+       url="http://www.mozilla.org/roadmap.html">road
+       maps</ulink>. Major points and achievements along this roadmaps
+       were marked as milestones. Therefore, mozilla was built and
+       distributed nightly as "nightly builds" but on a day when the
+       goals of a milestone on the roadmap had been reached, that
+       particular build was marked as a milstone release.
+      </para>

 
 

-   <para>
-    <variablelist>
+      <para>
+       While I haven't seen this method employed in any other projects
+       to date, I like the idea and think that it might have value in
+       any testing or development branch of a large free application
+       under heavy development.
+      </para>

 
 

-     <varlistentry>
-      <term>Fruits</term>
-      <listitem>
-       <para>such as apples, oranges, and more.</para>
-      </listitem>
-     </varlistentry>
+     </listitem>
+    </varlistentry>
+   </variablelist>
+  </sect2>

 
 

-     <varlistentry>
-      <term>Nuts</term>
-      <listitem>
-       <para>Don't eat too many; you are what you eat.</para>
-      </listitem>
-     </varlistentry>
+<!-- Section2: documentation-->

 
 

-     <varlistentry>
-      <term>Vegetables</term>
-      <listitem>
-       <para>Potatos are spelled with care.</para>
-      </listitem>
-     </varlistentry>
+  <sect2 id="documentation">
+   <title>Documentation</title>

 
 

-    </variablelist>
+   <para>
+    A huge number of otherwise fantastic free software applications
+    have withered because their author was the only person who knew
+    how to use them well. Even if your program is written primarily
+    for a techno-savvy group of users, documentation is helpful and
+    necessary for the survival of your project. You will learn later
+    in <xref linkend="releasing"> that you must always release
+    something that is usable. <emphasis>A piece of software without
+    documentation is not usuable.</emphasis>

    </para>
 
    <para>
    </para>
 
    <para>

-    A list in which each entry is marked with a sequentially 
-    incremented label:
+    There are lots of ways to document your project and lots of
+    different people to document for. The idea of documentation the
+    code itself to help facilitate development by a large community is
+    vital but is outside the scope of this HOWTO. This being the case,
+    this section deals mostly useful tactics for user-directed
+    documentation.

    </para>
 
    <para>
    </para>
 
    <para>

-     <orderedlist>
+    A combination of tradition and necessity has resulted in a
+    semi-regular system method of documentation in most free software
+    projects that is worth following. Both users and developers expect
+    to be able to get documentation in several ways and its essential
+    that you provide the information they are seeking in a form they
+    can read if your project is ever going to get off the
+    ground. People have come to expect:
+   </para>

 
 

-      <listitem>
-       <para>Step one</para>
-      </listitem>
+   <sect3>
+    <title>Man pages</title> 

 
 

-      <listitem>
-       <para>Step two</para>
-      </listitem>
+    <para>Your users will want to be able to type <quote>man
+    foo</quote> end up with a nicely formatted man page highlighting
+    the basic use of their application. Make sure that before you
+    release your program, you've planned for this.
+    </para>

 
 

-     </orderedlist>
-   </para>
-  </sect2>
+    <para>
+     Man pages are not difficult to write. There is excellent
+     documentation on the man page process available through the
+     <quote>The Linux Man-Page-HOWTO</quote> available through the
+     Linux Documentation project <acronym>(LDP)</acronym> written by
+     Jens Schweikhardt. It is available <ulink
+     url="http://www.schweikhardt.net/man_page_howto.html">from
+     Schweikhardt's site</ulink> or <ulink
+     url="http://www.linuxdoc.org/HOWTO/mini/Man-Page.html">from the
+     <acronym>LDP</acronym></ulink>.
+    </para>

 
 

-<!-- Section2: links -->
+    <para>
+     It is also possible to write man pages using DocBook SGML and
+     convert them into man pages. Because manpages are so simple, I
+     have not been able to follow this up but would love help from
+     anyone who can give me more information on how exactly this is
+     done.
+    </para>
+   </sect3>

 
 

-  <sect2 id="links">
-   <title>Links</title>
+   <sect3>
+    <title>Command line accessable documentation</title>

 
 

-   <para>
-    <emphasis>Links can be used within your documents to refer to
-    different sections and chapters or to refer to documents external
-    to yours.</emphasis>
-   </para>
+    <para>
+     Most users will expect the most basic amount of documentation to
+     be easily availabe from the command line. For few programs should
+     then documentation extend for more than one screen (24 or 25
+     lines) but it should cover the basic usage, a brief (one or two
+     sentance) description of the program, a list of commands, all the
+     major options, and a pointer to more in-depth documentation for
+     those who need it. The command line documentation for Debian's
+     apt-get serves as an excellent example and a useful model:
+    </para>

 
 

-   <sect3 id="int-links">
-    <title>Internal links</title>
+    <screen>
+apt 0.3.19 for i386 compiled on May 12 2000  21:17:27
+Usage: apt-get [options] command
+       apt-get [options] install pkg1 [pkg2 ...]
+
+apt-get is a simple command line interface for downloading and
+installing packages. The most frequently used commands are update
+and install.
+
+Commands:
+   update - Retrieve new lists of packages
+   upgrade - Perform an upgrade
+   install - Install new packages (pkg is libc6 not libc6.deb)
+   remove - Remove packages
+   source - Download source archives
+   dist-upgrade - Distribution upgrade, see apt-get(8)
+   dselect-upgrade - Follow dselect selections
+   clean - Erase downloaded archive files
+   autoclean - Erase old downloaded archive files
+   check - Verify that there are no broken dependencies
+
+Options:
+  -h  This help text.
+  -q  Loggable output - no progress indicator
+  -qq No output except for errors
+  -d  Download only - do NOT install or unpack archives
+  -s  No-act. Perform ordering simulation
+  -y  Assume Yes to all queries and do not prompt
+  -f  Attempt to continue if the integrity check fails
+  -m  Attempt to continue if archives are unlocatable
+  -u  Show a list of upgraded packages as well
+  -b  Build the source package after fetching it
+  -c=? Read this configuration file
+  -o=? Set an arbitary configuration option, eg -o dir::cache=/tmp
+See the apt-get(8), sources.list(5) and apt.conf(5) manual
+pages for more information and options.
+    </screen>

 
     <para>
 
     <para>

-     Click on the <xref LinkEnd="samples"> link to jump to the top of
-     this chapter. Note the anchor at the section tag.
+     It has become a GNU convention to make this information
+     accessable with the <quote>-h</quote> and the
+     <quote>--help</quote> options. Most GNU/Linux users will expect
+     to be able to retrieve basic documentation these ways so if you
+     choose to use different method, be prepared for the flames and
+     for the fallout that may result.
+    </para>
+   </sect3>
+   <sect3>
+    <title>Files users will expect</title>
+    <para>
+     In addition to man pages and online help, there are certain files
+     where people will look to documentation, especially in any
+     package containing source code. In a source distribution, most of
+     these files can be stored in a the root directery of the source
+     distribution or in a subdirectory of the root called
+     <quote>doc</quote> or <quote>Documentation</quote>. These files include:
+    </para>
+    <para>
+     <variablelist>
+      <varlistentry>
+       <term>README or Readme</term>
+
+       <listitem>
+       <para>
+         A document containing all the basic installation,
+         compiliation, and even basic use instructions that make up
+         the bare minimum information needed to get the program up and
+         running. A README is not your chance to be verbose but needs
+         to be concise and effective. An ideal README is at least 30
+         lines long and more no more than 250.
+        </para>
+       </listitem>
+
+      </varlistentry>
+      <varlistentry>
+       <term>INSTALL or Install</term>
+
+       <listitem>
+       <para>
+         The INSTALL file should be much shorter than the INSTALL file
+         and should quicly and concisely describe how to build and
+         install the program. Usually an install simply instructs the
+         user to run ./configure; make; make install and touches on
+         any unusual options that may be necessary. More advanced
+         users can usually avoid them but it's good practice to at
+         least glance at the file to understand what can be
+         expected. For most relatively standard install procedures and
+         for most programs, INSTALL files are as short as possible are
+         rarely over 100 lines.
+        </para>
+       </listitem>
+
+      </varlistentry>
+      <varlistentry>
+       <term>Changelog, ChangeLog, CHANGELOG, or changelog</term>
+
+       <listitem>
+       <para>
+         A changelog is a simple file that every well-managed free
+         software project should include. A changelog is simple the
+         file that, as its name would imply, logs or documents the
+         changes to a program. The most simple way to do a changelog
+         is to simply keep a file with teh source code for your
+         program and add a section to the top of the changelog with
+         each release describing what has been, changed, fixed, or
+         added to the program. It's a good idea to post the changelog
+         onto the website as well because it can help people decide
+         whether they want or need to upgrade to a newer version or
+         wait for a more signifigant upgrade.
+        </para>
+       </listitem>
+
+      </varlistentry>
+      <varlistentry>
+       <term><acronym>FAQ</acronym></term>
+
+       <listitem>
+       <para>
+         For those of you that don't already
+         know. <acronym>FAQ</acronym> stands for Frequently Asked
+         Questions and the file is a collection of exactly that. FAQs
+         are not difficult to make. Simply make a policy that if you
+         are asked a question or see a question on a mailing list two
+         or more times, add it the question (and its answer) to your
+         FAQs. FAQs are more optional than the files listed above but
+         they can save your time, increase useability, and decrease
+         headaches on all sides.
+        </para>
+       </listitem>
+
+      </varlistentry>
+     </variablelist>

     </para>
    </sect3>
 
     </para>
    </sect3>
 

-   <sect3 id="ext-links">
-    <title>External links</title>
-
+   <sect3>
+    <title>Website</title>

     <para>
     <para>

-     Click on <ulink url="http://www.linuxdoc.org/">this</ulink> link
-     to jump to the LDP site. Note you can use http, ftp, news and
-     other protocols in the locator if required.
+     It's only a sort of an issue of documentation but a good website
+     is quickly becoming an essential part of any free software
+     project. Your website should provide access to documentation (in
+     <acronym>HTML</acronym> if possible). It should also include a
+     section for news and events around your program and a section
+     that details the process of getting involved with development or
+     testing and creates an open invitation. It should also supply
+     links to any mailing lists, similar websites, and directly to all
+     the available ways of downloading your software.

     </para>
    </sect3>
 
     </para>
    </sect3>
 

-  </sect2>
+   <sect3>
+    <title>Other documentation hints</title>

 
 

-<!-- Section2: images -->
+    <para>
+     It doesn't hurt to distribute any documentation for your program
+     from your website or anywhere else (FAQs etc) with the
+     program. Make a FAQ by cutting and posting common questions and
+     answers from a mailing list or your own email. Then, don't
+     hesitate through this in the programs tarball. If people don't
+     need it, they will delete it. I can repeat it over and over:
+     <emphasis>Too much documentation is not a sin.</emphasis>
+    </para>

 
 

-  <sect2 id="images">
-   <title>Images</title>
+    <para>
+     All your documentation should be in plaintext, or, in cases where
+     it is on your website primarily, in HTML. Everyone can cat a
+     file, everyone has a pager, (almost) everyone can render
+     HTML. <emphasis>You are welcome to distribute information in PDF,
+     PostScript, RTF, or any number of other widely used formats but
+     this information must also be available in plaintext or HTML or
+     people will be very angry at you.</emphasis>
+    </para>
+   </sect3>
+  </sect2>

 
 

-   <para>
-    <emphasis>Avoid diagrams if possible as this cannot be rendered
-    in the ASCII outputs which are still needed by many around the
-    world.</emphasis>
-   </para>
+<!-- Section2: presentation -->

 
 

+  <sect2 id="presentation">
+   <title>Other Presentation Issues</title>

    <para>
    <para>

-     <figure>
-      <title>Graphics Test Image</title>
-      <graphic FileRef="red.gif"></graphic>
-     </figure>
+    Many of the remaining issues surrounding the creation of a new
+    free software program fall under what most people describe as
+    common sense actions. Still, they are worth noting briefly in
+    hopes that they may remind a developer of something they may have
+    forgotten.

    </para>
 
    </para>
 

-   <para>
-    Here is another variation which allows for ALT text:
-   </para>
+   <sect3>
+    <title>Package formats</title>
+    <para>
+     Package formats may differ depending on the system you are
+     developing for. For windows based software, Zip archives (.zip)
+     usually serve as the package format of choice. If you are
+     developing for GNU/Linux, *BSD, or any UN*X, make sure that your
+     source code is always available in tar'ed and gzip'ed format
+     (.tar.gz). UNIX compress (.Z) has gone out of style and
+     usefulness and faster computers have brought bzip2 (.bz2) into
+     the spotlit as a more effective compression medium. I now make
+     all my releases available in both gzip'ed and bzip2'ed formats.
+    </para>

 
 

-   <para>
-     <mediaobject>
+    <para>
+     Binary packages are largely distribution specific. You can build
+     binary packages against a current version of a major
+     distribution, you will only make your users happy. Try to foster
+     relationships with users or developers of large distribution to
+     develop a system for consistent binary packages. It's often a
+     good idea to provide RedHat <acronym>RPM</acronym>'s (.rpm),
+     Debian deb's (.deb) and source <acronym>RPM</acronym>'s
+     <acronym>SRPM</acronym>'s. Binary packages can also be compiled
+     against a specified system with specificed libraries and
+     distributed in tar.gz format as well. <emphasis>Remember: While
+     these binaries packages are nice, geting the source packaged and
+     released should always be your priority. Other can and will do
+     the the binary packages for you.</emphasis>
+    </para>
+   </sect3>

 
 

-      <imageobject>
-       <imagedata fileref="green.gif" format="gif">
-      </imageobject>
+   <sect3>
+    <title>Useful tidbits and presentation hints</title>

 
 

-      <textobject>
-       <phrase>
-        ALT text to be used: Green Ball
-       </phrase>
-      </textobject>
+    <para>
+     <itemizedlist>

 
 

-      <caption>
+      <listitem>

        <para>
        <para>

-        Caption for the graphic goes here: This is a Green Ball.
+        <emphasis>Make sure that your program can always be found in a
+        single location.</emphasis> Often this means that you have a
+        single directory accessable via <acronym>FTP</acronym> or
+        <acronym>HTTP</acronym> where the newest version will be
+        quickly recognized. One effective technique is a provide a
+        symlink called <quote>projectname-latest</quote> that is
+        always pointing to the most recent released or development
+        version of your free software project.

        </para>
        </para>

-      </caption>
-     </mediaobject>
-   </para>
-  </sect2>
+      </listitem>

 
 

- </sect1>
+      <listitem>
+       <para>
+        <emphasis>Make sure that there is a consistent email address
+        for bug reports.</emphasis> It's usually a good idea to make
+        this something that is NOT your primary email address like
+        projectname@host or projectname-bugs@host. This way if you
+        ever decide to hand over maintainership or if your email
+        address changes, you simply need to change where this email
+        address forwards to. It also will allow for more than one
+        person to deal with the influx of mail that is created if your
+        project becomes as huge as you hope it will.
+       </para>
+      </listitem>

 
 

-<!-- Section1: samples: END -->
+     </itemizedlist>
+    </para>

 
 

+   </sect3>
+  </sect2>
+ </sect1>

 
 

-<!-- Section1: structure -->
+<!-- Section1: starting: END -->

 
 

- <sect1 id="structure">
-  <title>Structure</title>
+<!-- Section1: developers -->

 
 

-  <para>
-   <emphasis>A quick overview on how all parts fit together in the overall
-   structure. An example from the Multi Disk HOWTO is used.</emphasis>
- </para>
+ <sect1 id="developers">
+  <title>Maintaining a Project: Interacting with Developers</title>
+  <indexterm>
+   <primary>fswd!developers</primary>
+  </indexterm>

 
   <para>
 
   <para>

-   As this type of document is supposed to be as much for learning as
-   a technical reference document I have rearranged the structure to
-   this end. For the designer of a system it is more useful to have
-   the information presented in terms of the goals of this exercise
-   than from the point of view of the logical layer structure of the
-   devices themselves. Nevertheless this document would not be
-   complete without such a layer structure the computer field is so
-   full of, so I will include it here as an introduction to how it
-   works.
+   Once you have gotten the project started, you have gotten over the
+   most difficult hurdles in the development process of your
+   program. Laying a firm foundation is essential, but the development
+   process itself is equally important and provides an equal number of
+   opportunities for failure. In the next two sections, I will and
+   cover running a project by discussing how to maintain a project
+   rhough interactions with developers and with users.

   </para>
 
   </para>
 

-<!-- Section2: logical-struct -->
-
-  <sect2 id="logical-struct">
-   <title>Logical structure</title>
-
-    <indexterm>
-     <primary>disk!structure, I/O subsystem</primary>
-    </indexterm>
-
-   <para>
-    This is based on how each layer access each other, traditionally
-    with the application on top and the physical layer on the bottom.
-    It is quite useful to show the interrelationship between each of
-    the layers used in controlling drives.
-
-    <screen>
-        ___________________________________________________________
-        |__     File structure          ( /usr /tmp etc)        __|
-        |__     File system             (ext2fs, vfat etc)      __|
-        |__     Volume management       (AFS)                   __|
-        |__     RAID, concatenation     (md)                    __|
-        |__     Device driver           (SCSI, IDE etc)         __|
-        |__     Controller              (chip, card)            __|
-        |__     Connection              (cable, network)        __|
-        |__     Drive                   (magnetic, optical etc) __|
-        -----------------------------------------------------------
-    </screen>
-   </para>
+  <para>
+   In releasing your program, your program becomes free software. This
+   transition is more than just a larger user base. By releasing your
+   program as free software, <emphasis>your</emphasis> software
+   becomes the <emphasis>free software community's</emphasis>
+   software. The direction of your software's development will be
+   reshaped, redirected, and fully determined by your users and, to a
+   larger extent, by other developers in the community.
+  </para>

 
 

-   <para>
-    In the above diagram both volume management and RAID and
-    concatenation are optional layers. The 3 lower layers are in
-    hardware. All parts are discussed at length later on in this
-    document.
-   </para>
-  </sect2>
+  <para>
+   The major difference between free software development and propriety
+   software development is the developer base. As the leader of a free
+   software project, you need to attract and keep developers in a way
+   that leaders of proprietary software projects sipmly don't have to
+   worry about. <emphasis>As the person leading development of a free
+   software project, you must harness the work of fellow developers by
+   making responsible decisions and by and by choosing not to make
+   decisions responsibly. You have to direct developers without being
+   overbearing or bossy. You need to strive to earn respect and never
+   forget to give it.</emphasis>
+  </para>

 
 

-<!-- Section2: doc-struct -->
+<!-- Section2: delegation  -->

 
 

-  <sect2 id="doc-struct">
-   <title>Document structure</title>
+  <sect2 id="delegation">
+   <title>Delegating Work</title>

 
    <para>
 
    <para>

-    Most users start out with a given set of hardware and some plans
-    on what they wish to achieve and how big the system should be.
-    This is the point of view I will adopt in this document in
-    presenting the material, starting out with hardware, continuing
-    with design constraints before detailing the design strategy that
-    I have found to work well. I have used this both for my own
-    personal computer at home, a multi purpose server at work and
-    found it worked quite well. In addition my Japanese co-worker in
-    this project have applied the same strategy on a server in an
-    academic setting with similar success.
+    By now, you've hypothetically followed me through the early
+    writing of a piece of software, the creation of a website and
+    system of documentation and and we've gone ahead and (as will be
+    discussed in <xref linkend="releasing">) released it to the rest
+    of the world. Times passes, and if things go well, people become
+    interested and want to help. The patches begin flowing in.

    </para>
 
    <para>
    </para>
 
    <para>

-    Finally at the end I have detailed some configuration tables for
-    use in your own design. If you have any comments regarding this
-    or notes from your own design work I would like to hear from you
-    so this document can be upgraded.
+    <emphasis>Like the parent of any child who grows up, it's now time
+    to wince and smile and do most difficult thing in any parents
+    life: It's time to let go.</emphasis>

    </para>
    </para>

-  </sect2>
-
-<!-- Section2: reading-plan -->
-
-  <sect2 id="reading-plan">
-   <title>Reading plan</title>

 
    <para>
 
    <para>

-    <emphasis>As you go beyond 50 pages or so there will be a lot of
-    text that experts and even the experienced do not need to read.
-    Keeping in mind that we wish to care for all kinds of people in
-    the Linux world we might have to make a reading plan. Again,
-    an example follows from the Multi Disk HOWTO.</emphasis>
+    Delegation is the politcal way of describing this process of
+    <quote>letting go.</quote> It is the process of handing some of
+    the responsibility and power over your project to other reponsible
+    and involved developers. It is difficult for anyone who has
+    invested a large deal of time and energy into a project but it
+    essential for the growth of any free software project. One person
+    can only do so much. <emphasis>A free software project is nothing
+    without the involvement of a group of developers. A group of
+    developers can only be maintained through respectful and
+    responsible leadership and delegation.</emphasis>

    </para>
 
    <para>
    </para>
 
    <para>

-    Although not the biggest HOWTO it is nevertheless rather big
-    already and I have been requested to make a reading plan to make
-    it possible to cut down on the volume.
+    As your project progresses, you will notice people who are putting
+    signfigant amounts of time and effort into your project. These
+    will be the people submitting the most patches, posting most on
+    the mailing lists, engaging in long email discussions. It is your
+    responsiblity to contact these people and to try and shift some of
+    the power and responsiblity of your position as the project's
+    maintainer onto them (if they want it). There are several easy
+    weays you can do this:

    </para>
 
    </para>
 

-   <para>
-    <variablelist>
-
-     <varlistentry>
-      <term>Expert</term>
-      <listitem>
-       <para>
-        (aka the elite). If you are familiar with Linux as well as
-        disk drive technologies you will find most of what you need in
-        the appendices. Additionally you are recommended to read the
-        FAQ and the <XRef LinkEnd="bits-n-pieces">chapter.
-       </para>
-      </listitem>
-     </varlistentry>
-
-     <varlistentry>
-      <term>Experienced</term>
-      <listitem>
-       <para>
-       (aka Competent). If you are familiar with computers in
-       general you can go straight to the chapters on 
-       <XRef LinkEnd="technologies"> and continue from there on.
-       </para>
-      </listitem>
-     </varlistentry>
-
-     <varlistentry>
-      <term>Newbie</term>
-      <listitem>
-       <para>
-       (mostly harmless). You just have to read the whole thing.
-       Sorry. In addition you are also recommended to read all the
-       other disk related HOWTOs.
-       </para>
-      </listitem>
-     </varlistentry>
-
-    </variablelist>
-   </para>
-  </sect2>
-
- </sect1>
-
-<!-- Section1: structure: END -->
-
-
-<!-- Section1: technologies -->
-
- <sect1 id="technologies">
-  <title>Technologies</title>
-
-   <indexterm>
-    <primary>(your index root)!technologies</primary>
-   </indexterm>
-
-  <para>
-   <emphasis>Introduction of technology for the newbie with a few
-   references to detailed works. Remember that not everyone has
-   Internet access so you have to explain in sufficient details so
-   even the newbie can get by.</emphasis>
-  </para>
-
- </sect1>
-
-<!-- Section1: technologies: END -->
-
-
-<!-- Section1: implement -->
-
- <sect1 id="implement">
-  <title>Implementation</title>
-
-   <indexterm>
-    <primary>(your index root)!implementation</primary>
-   </indexterm>
-
-  <para>
-   <emphasis>Now your readers should have a sufficient knowledge of
-   what this is about and now we come to the hands on of implementing
-   your clever scheme.</emphasis>
-  </para>
-
- </sect1>
-
-<!-- Section1: implement: END -->
-
-
-<!-- Section1: maint -->
-
- <sect1 id="maint">
-  <title>Maintenance</title>
-
-   <indexterm>
-    <primary>(your index root)!maintenance</primary>
-   </indexterm>
-
-  <para>
-   <emphasis>Few systems and designs are maintenance free, here you
-   explain how to keep the system running.</emphasis>
-  </para>
-
- </sect1>
-
-<!-- Section1: maint: END -->
-
-
-<!-- Section1: adv-issues -->
-
- <sect1 id="adv-issues">
-  <title>Advanced Issues</title>
+   <sect3>
+    <title>How to delegate</title>
+ 
+    <para>
+     Like anything, its easier to see how others delegate than to do
+     it yourself. You may find that other developers seem even more
+     experienced or knowledgeable than you. Your job as a maintainer
+     does not mean you have to have to be the best or the
+     brightest. It means you need are responsible for showing good
+     judgement and for recognizing solutions that are maintainable and
+     are not. In a sentance: <emphasis>Keep an eye out for other
+     qualified developers who show an interest and sustained
+     involvement with your project and try and shift responsibility
+     towards them.</emphasis> The following ideas might be good places
+     to start or good sources of inspiriation:
+    </para>
+ 
+    <sect4>
+     <title>Allow a larger group of people write access to your CVS
+     reponsitory and make real efforts towards rule by a
+     committee</title>

 
 

-   <indexterm>
-    <primary>(your index root)!advanced topics</primary>
-   </indexterm>
+     <para>
+      <ulink url="http://httpd.apache.org/">Apache</ulink> is an
+      example of a project that is run by small group of developers
+      who vote on major technical issues and the admission of new
+      members and all have write access to the main source
+      repository. Their process is detailed <ulink
+      url="http://httpd.apache.org/ABOUT_APACHE.html">online.</ulink>
+     </para>

 
 

-  <para>
-   <emphasis>You can get most things up and running in a quick and
-   dirty fashion, useful for testing and getting used to how things
-   work. For more serious use you would need to be a little more
-   advanced. This is the place to explain it all, if applicable.</emphasis>
-  </para>
+     <para>
+      The <ulink url="http://www.debian.org/"> Debian Project</ulink>
+      is an extreme example of rule by committee. At current count,
+      more than 700 developers have full responsibility for certain
+      aspects of the projects. All these developers can upload into
+      the main ftp servers, and vote on major issues. Direction for
+      the project is determined by the project <ulink
+      url="http://www.debian.org/social_contract">social
+      contract</ulink> and a <ulink
+      url="http://www.debian.org/devel/constitution">constitution</ulink>. To
+      facilitate this system, there are special teams (i.e. the
+      install team, the Japanese language team) and a technical
+      committee and a project lead. There is a project lead as well
+      but the lead's main responsiblity is to, <quote>Appoint
+      Delegates or delegate decisions to the Technical
+      Committee.</quote>
+     </para>

 
 

- </sect1>
+     <para>
+      While both of these projects operate on a scale that your
+      project will not (at least initially), their example is
+      helpful. Debian's idea of a project who lead who can do
+      <emphasis>nothing</emphasis> but delegate can serve as a
+      charicature of how a project can involve and empower a huge
+      number of developers and grow to a huge size.
+     </para>

 
 

-<!-- Section1: adv-issues: END -->
+    </sect4>

 
 

+    <sect4 id="releasemanager">
+     <title>Publicly appoint someone as the release manager for a
+       specific release.</title>

 
 

-<!-- Section1: moreinfo -->
+     <para>
+      A relase manager is usually responsible for coordinating
+      testing, encforcing a code freeze, being responsible for
+      stability and quality control, packaging up the software, and
+      placing it in the approrpriate places to be downloaded.
+     </para>

 
 

- <sect1 id="moreinfo">
-  <title>Further Information</title>
+     <para>
+      This use of the release manager is a good way to give yourself a
+      break and to shift the responsibility for accepting and
+      rejecting patches to somenoe else. It is a good way of very
+      clearly defining a chunk of work on the project as belonging to
+      a certain person and its a great way of giving yourself a break.
+     </para>
+    </sect4>

 
 

-   <indexterm>
-    <primary>(your index root)!information resources</primary>
-   </indexterm>
+    <sect4 id="delegatebranch">
+     <title>Delegate control of an entire branch.</title>
+     <para>
+      If your project chooses to have branches (as described in <xref
+      linkend="branches">), it might be a good idea to appoint someone
+      else to be the the head of a branch. If you like focusing your
+      energy on development releases and the implementation of new
+      features, had total control over the stable releases to a
+      well-suiteded developer.
+     </para>

 
 

-  <para>
-   <emphasis>A HOWTO cannot describe everything, some times the user
-   has to venture out on th enet to get more information or just
-   updates. Here is the place to tell where and how. Again examples
-   from the Multi Disk HOWTO, replace as needed.</emphasis> There is wealth
-   of information one should go through when setting up a major system,
-   for instance for a news or general Internet service provider.  The
-   FAQs in the following groups are useful:
-  </para>
+     <para>
+      The author of linux, Linus Torvalds, came out and crowned Alan
+      Cox as <quote>the man for stable kernels.</quote> All patches
+      for stable kernels go to Alan and, if Linus were to be taken
+      away from work on linux for any reason, Alan Cox would be more
+      than suited to fill his role as the acknowledged heir to the
+      linux maintainership.
+     </para>
+    </sect4>
+   </sect3> 
+  </sect2>

 
 

-<!-- Section2: newsgroups -->
+<!-- Section2: patching -->

 
 

-  <sect2 id="newsgroups">
-   <title>News groups</title>
+  <sect2 id="patching">
+   <title>Accepting and Rejecting Patches</title>
+   <para>
+    This HOWTO has already touched on the fact that as the maintainer
+    of a free software project, one of primary and most important
+    responsibilities will be accepting and rejecting patches submitted
+    to you by other developers.
+   </para>

 
 

-    <indexterm>
-     <primary>disk!information resources!news groups</primary>
-    </indexterm>
+   <sect3>
+    <title>Technical judgement</title>

 
 

-   <para>Some of the most interesting news groups are:
+    <para>
+     In <emphasis>Open Source Development with CVS</emphasis>, Karl
+     Fogel makes a convincing argument that the most important things
+     to keep in mind are a firm knowledge of the scope of your program
+     (that's the <quote>idea</quote> I talked about in <xref
+     linkend="chooseproject">) and the ability to recognize,
+     facilitate, and direct <quote>evolution</quote> of a free
+     software program so that the program can grow and change and
+     incorporate functionatlity that was orignally unforseen but avoid
+     digressions that might expand the scope of the program too much
+     and result and push the project towards an early death under its
+     own weight and unweildiness. These are the criteria that you as a
+     project mainatiner should take into account each time you recieve
+     a patch.
+    </para>

 
 

-    <itemizedlist>
+    <para>
+     Fogel elaborates on this again and states the <quote>the
+     questions to ask yourself when considering whether to implement
+     (or approve) a change are:</quote>
+    </para>

 
 

-     <listitem>
-      <para>
-       <ulink url="news:comp.arch.storage">Storage</ulink>.
-      </para>
-     </listitem>
+    <para>
+     <itemizedlist>

 
 

-     <listitem>
-      <para>
-       <ulink url="news:comp.sys.ibm.pc.hardware.storage">PC storage</ulink>.
-      </para>
-     </listitem>
+      <listitem>
+       <para>Will it benefit a significant percentage of the program's
+       user community?</para>
+      </listitem>

 
 

-     <listitem>
-      <para>
-       <ulink url="news:alt.filesystems.afs">AFS</ulink>.
-      </para>
-     </listitem>
+      <listitem>
+       <para>Does it fit within the program's domain or within a
+       natural, intuitive extension of that domain?</para>
+      </listitem>

 
 

-     <listitem>
-      <para>
-       <ulink url="news:comp.periphs.scsi">SCSI</ulink>.
-      </para>
-     </listitem>
+     </itemizedlist>
+    </para>

 
 

-     <listitem>
-      <para>
-       <ulink url="news:comp.os.linux.setup">Linux setup</ulink>.
-      </para>
-     </listitem>
+    <para>
+     The answers to these questions are never straighforward and its
+     very possible (and even likely) that the person who submitted the
+     patch may feel differently about the answer to those questions
+     than you do. However, if you feel that that the answer to either
+     of those questions is <quote>no,</quote> it is your responsiblity
+     to reject the change. If you fail to do this, the project will
+     become unweildy and unmaintainable and will ultimately fail.
+    </para>
+   </sect3>

 
 

-    </itemizedlist>
-   </para>
+   <sect3>
+    <title>Rejecting patches</title>

 
 

-   <para>
-    Most newsgroups have their own FAQ that are designed to answer most
-    of your questions, as the name Frequently Asked Questions indicate.
-    Fresh versions should be posted regularly to the relevant newsgroups.
-    If you cannot find it in your news spool you could go directly to the
-    <ulink url="ftp://rtfm.mit.edu/">FAQ main archive FTP site</ulink>.
-    The WWW versions can be browsed at the 
-    <ulink url="http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html">FAQ
-    main archive WWW site</ulink>.
-   </para>
+    <para>
+     Rejecting patches is probably the most difficult and the most
+     sesnative job that the maintainer of any free software project
+     has to face. But sometimes it has to be done. I mentioned earlier
+     (in <xref linkend="developers"> and in <xref
+     linkend="delegation">) that any developer needs to try and
+     balance your responsibility and power to make what you think are
+     the best technical decisions with the fact that you will lose
+     support from other developers if you seem like you are on a
+     powertrip or being overly bossy or possesive of a community-based
+     project. I recommend that you keep three major facts in mind when
+     rejecting patches (or other changes):
+    </para>

 
 

-   <para>
-    Some FAQs have their own home site, of particular interest:
+    <sect4>
+     <title>Bring it to the community</title>
+     <para>
+      One of the best ways of justifying  a decision to reject a patch
+      and working  to  not seem like  you  keep an  iron grip  on your
+      project is by  not making the  decision  alone at all. It  might
+      make  sense  to  turn over  larger  proposed  changes  or more
+      difficult decisions to a development mailing list where they can
+      be discussed. There will be some patches (bug fixes, etc.) which
+      will  definately be accepted  and some that you  feel are so off
+      base that they do not even merit further discussion. It is those
+      that fall into the grey area between these two groups that might
+      merit a quick forward to a mailing list.
+     </para>

 
 

-    <itemizedlist>
+     <para>
+      I recommend this process wholeheartedly. As the project
+      maintainer you are worried about making the best decision for
+      the project, for the project's users and developers, and for
+      yourself as a responsible project leader. Turning things over to
+      an email list will demonstrate your own responsible and
+      responsive leadership as it tests and serves the interests of
+      your software's community.
+     </para>
+    </sect4>

 
 

-     <listitem>
-      <para>
-       <ulink url="http://www.paranoia.com/~filipg/HTML/LINK/F_SCSI.html">SCSI FAQ</ulink> 
-       and
-      </para>
-     </listitem>
+    <sect4>
+     <title>Technical issues is not always good justification</title>
+     <para>
+      Especially towards the beginning, you will find that many
+      changes are difficult to implement, introduce new bugs, or have
+      other techincal problems. Try to see past these. Especially with
+      added functionality, good ideas do not always come from good
+      coders. Technical merit is a valid reason to postpone the
+      application of a patch but it is not always a good reason to
+      reject a change outright. Even small changes are worth the
+      effort of working with the submittor to iron out bugs and
+      incorporate the change if you thing you think it seems like a
+      good addition to your project. The effort on your part will work
+      to make your project a community project and it will pull a new
+      or less experienced developer onto your project and even teach
+      them something that might help them in their next patch.
+     </para>
+    </sect4>

 
 

-     <listitem>
-      <para>
-       <ulink url="http://alumni.caltech.edu/~rdv/comp_arch_storage/FAQ-1.html">comp.arch.storage FAQ</ulink>.
-      </para>
-     </listitem>
+    <sect4>
+     <title>Common courtesy</title>
+     <para>
+      It should go without saying but, <emphasis>above all and in all
+      cases, just be nice.</emphasis> If someone has an idea and cares
+      about it enough to write some code and submit a patch, they
+      care, they are motivated, and they are already involved. Your
+      goal as the maintainer is make sure they submit again. They may
+      have thrown you a dud this time but next time may be the idea or
+      feature that revolutionizes your project. 
+     </para>

 
 

-    </itemizedlist>
-   </para>
+     <para>
+      It is your responsibility to first justify your action to not
+      incorporate their change clearly and concisely. Then thank
+      them. Let them know that you a appreciate their help and feel
+      horrible that you can't incorproate their change. Let them know
+      that you look forward to their staying involved and you hope
+      that the next patch or idea meshes better with your project
+      because you appreciate their work and want to see it in the
+      project. If you have ever had a patch rejected that put a large
+      deal of time, thought, and energy into, you remember how it
+      feels and it feels bad. Keep this in mind when you have to let
+      someone down. It's never easy but you need to do everything you
+      have to make it as not-unpleasant as possible.
+     </para>
+    </sect4>
+   </sect3>

   </sect2>
 
   </sect2>
 

-<!-- Section2: maillists -->
-
-  <sect2 id="maillists">
-   <title>Mailing Lists</title>
-
-    <indexterm>
-     <primary>disk!information resources!mailing lists</primary>
-    </indexterm>
+<!-- Section2: branches  -->

 
 

-   <para>
-    These are low-noise channels mainly for developers. Think twice
-    before asking questions there as noise delays the development.
-    Some relevant lists are <email>linux-raid</email>,
-    <email>linux-scsi</email> and <email>linux-ext2fs</email>.  Many
-    of the most useful mailing lists run on the <Literal
-    remap="tt">vger.rutgers.edu</Literal> server but this is
-    notoriously overloaded, so try to find a mirror. There are some
-    lists mirrored at <ulink url="http://www.redhat.com">The Redhat
-    Home Page</ulink>. Many lists are also accessible at <ulink
-    url="http://www.linuxhq.com/lnxlists">linuxhq</ulink>, and the
-    rest of the web site contains useful information as well.
-   </para>
+  <sect2 id="branches">
+   <title>Stable and Development Branches</title>

 
    <para>
 
    <para>

-    If you want to find out more about the lists available you can send
-    a message with the line <command>lists</command> to the list server
-    at <email>majordomo@vger.rutgers.edu</email>.
-    If you need help on how to use the mail server just send the line
-    <command>help</command> to the same address.  Due to the
-    popularity of this server it is likely it takes a bit to time before
-    you get a reply or even get messages after you send a
-    <command>subscribe</command> command.
+    The idea of stable and development branches has already been
+    described briefly in <xref linkend="chooseversioning"> and in
+    <xref linkend="delegatebranch">. These alluses attest to the fact
+    to some of the ways that multiple branches can affect your
+    software. Branches can let you avoid (to some extent) some of the
+    problems around rejecting patches (as described in <xref
+    linkend="patching">) by allowing you to temporarily compromise the
+    stability of your project without affected those users who need
+    that stability.

    </para>
 
    <para>
    </para>
 
    <para>

-    There is also a number of other majordomo list servers that can
-    be of interest such as the EATA driver list
-    (<email>linux-eata@mail.uni-mainz.de</email>)
-    and the Intelligent IO list <email>linux-i2o@dpt.com</email>.
+    The most common way of branching your project is to have one
+    branch that is stable and one that is development. This is the
+    model followed by the Linux kernel that is described in <xref
+    linkend="chooseversioning">. In this model, there is always one
+    branch that is stable and always one that is in
+    development. Before any new release, the development branch goes
+    into a <quote>feature freeze</quote> where major changes and added
+    features are rejected or put on hold under the development kernel
+    is released as the new stable branch and major development begins
+    again on the development branch. Bug fixes and small changes that
+    are unlikely to have any large negative reprocussion are
+    incorporated into the stable branch also to the development
+    branch.

    </para>
 
    <para>
    </para>
 
    <para>

-    Mailing lists are in a state of flux but you can find links to a
-    number of interesting lists from the 
-    <ulink url="http://www.linuxdoc.org/">Linux Documentation
-    Homepage</ulink>.
+    Linux's model is an extreme one. On many projects, there is no
+    need to have two versions always available. It may make sense ot
+    have two versions only near a release. The Debian project has
+    historically made both a stable and an unstable distribution
+    available but has expanded to this to include: stable, unstable,
+    testing, experimental, and (around release time) a frozen
+    distribution that only incorporates bug fixes during the
+    transition from unstable to stable. There are few projects whose
+    size would necessitate a system like Debian but their use of
+    branches helps demonstrate how they can be used to balance
+    consitent and effective development with the need to make regular
+    and useable releases.

    </para>
    </para>

-  </sect2>
-
-<!-- Section2: howto -->
-
-  <sect2 id="howto">
-   <title>HOWTO</title>
-
-    <indexterm>
-     <primary>disk!information resources!HOWTOs</primary>
-    </indexterm>

 
    <para>
 
    <para>

-    These are intended as the primary starting points to get the
-    background information as well as show you how to solve a
-    specific problem. Some relevant HOWTOs are
-    <Literal remap="tt">Bootdisk</Literal>, 
-    <Literal remap="tt">Installation</Literal>,
-    <Literal remap="tt">SCSI</Literal> and 
-    <Literal remap="tt">UMSDOS</Literal>.  The main site for these is the
-    <ulink url="http://www.linuxdoc.org/">LDP archive</ulink>at
-    Metalab (formerly known as Sunsite).
+    In trying to set up a development tree for yourself, there are
+    several things that might be useful to keep in mind:

    </para>
 
    <para>
    </para>
 
    <para>

-    There is a a new HOWTO out that deals with setting up a DPT RAID
-    system, check out the
-    <ulink url="http://www.ram.org/computing/linux/dpt_raid.html">DPT RAID
-    HOWTO homepage</ulink>.
-   </para>
-  </sect2>
-
-<!-- Section2: local-res -->
+    <variablelist>

 
 

-  <sect2 id="local-res">
-   <title>Local Resources</title>
+     <varlistentry>
+      <term>Minimize the number of branches</term>
+      <listitem>
+       <para>
+        Debian may be able to make good use of four or five branches
+        but it contains gigabytes of software in over 5000 packages
+        compiled for a 5-6 different architectures. Two is a good
+        number. Too many branches will confuse your users (I can't
+        count how many times I had to describe debian's system when it
+        only had 2 and sometimes 3 branches!), potential developers
+        and even yourself. Branches can help but they come at a cost
+        so use them very sparingly.
+       </para>
+      </listitem>
+     </varlistentry>

 
 

-    <indexterm>
-     <primary>disk!information resources!local</primary>
-    </indexterm>
+     <varlistentry>
+      <term>Make sure that all your different branches are explained</term>
+      <listitem>
+       <para>
+        As I mentioned in the preceeding paragraph, different branches
+        <emphasis>will</emphasis> confuse your users. Do everything
+        you can to avoid this by clearly explaining the different
+        branches in a promenant page on your website and in a Readme
+        file in the <acronym>FTP</acronym> or <acronym>HTTP</acronym>
+        directory.
+       </para>

 
 

-   <para>
-    In most distributions of Linux there is a document directory
-    installed, have a look in the <filename>/usr/doc</filename>
-    directory. where most packages store their main documentation and
-    README files etc.  Also you will here find the HOWTO archive 
-    (<filename>/usr/doc/HOWTO</filename>) of ready formatted HOWTOs
-    and also the mini-HOWTO archive 
-    (<filename>/usr/doc/HOWTO/mini</filename>) of plain text
-    documents.
-   </para>
+       <para>
+        I might also recommend against a mistake that I think Debian
+        has made. The terms <quote>unstable,</quote>
+        <quote>testing,</quote> and <quote>experimental</quote> are
+        vague and difficult to rank in order of stability (or
+        instability as the case may be). Try explaining to someone
+        that <quote>stable</quote> actually means <quote>ultra
+        stable</quote> and that <quote>unstable</quote> doesn't
+        actually include any unstable software but is really stable
+        software that is untested as a distribution.
+       </para>

 
 

-   <para>
-    Many of the configuration files mentioned earlier can be found in
-    the <filename>/etc</filename> directory. In particular you will
-    want to work with the <filename>/etc/fstab</filename> file that
-    sets up the mounting of partitions and possibly also
-    <filename>/etc/raidtab</filename> file that is used for the
-    <Literal remap="tt">md</Literal> system to set up RAID.
-   </para>
+       <para>
+        If you are going to do branches, especially early on, keep in
+        mind that people are conditioned to understand the terms
+        <quote>stable</quote> and <quote>development</quote> and you
+        probaly can't go wrong with this simple and common division of
+        branches.
+       </para>
+      </listitem>
+     </varlistentry>

 
 

-   <para>
-    The kernel source in <filename>/usr/src/linux</filename> is, of
-    course, the ultimate documentation. In other words, <quote>use
-    the source, Luke</quote>. It should also be pointed out that the
-    kernel comes not only with source code which is even commented
-    (well, partially at least) but also an informative
-    <filename>/usr/src/linux/Documentation</filename>. If you are
-    about to ask any questions about the kernel you should read this
-    first, it will save you and many others a lot of time and
-    possibly embarrassment.
-   </para>
+     <varlistentry>
+      <term>Make sure all your branches are always available</term>
+      <listitem>
+       <para>
+        Like a lot of document, this should probably should go without
+        saying but experience has taught me that it's not always
+        obvious to people. It's a good idea to physicall split up
+        different branches in different directories or directory trees
+        on your <acronym>FTP</acronym> or <acronym>HTTP</acronym>
+        site. Linux accomplishes this by having all the v2.2 and a
+        v2.3 subdirectory where it is immediately obvious (after you
+        know their version numbering scheme) which directory is the
+        most recent stable and the current development
+        releases. Debian accomplishes this by naming all their
+        distribution by name and then changing symlinks named
+        <quote>stable,</quote> <quote>unstable</quote> and
+        <quote>frozen</quote> to point to which ever distribution (by
+        name) is in whatever stage. Both methods work and their are
+        others. In any case, it is important that different branches
+        are always available, are accessable from consistent
+        locations, and that different branches are clearly
+        distinguished from each other so your users know exactly what
+        they want to be downloading and where to get it.
+       </para>
+      </listitem>
+     </varlistentry>

 
 

-   <para>
-    Also have a look in your system log file
-    (<filename>/var/log/messages</filename>) to see what is going on
-    and in particular how the booting went if too much scrolled off
-    your screen. Using <command>tail -f /var/log/messages</command>
-    in a separate window or screen will give you a continuous update
-    of what is going on in your system.
+    </variablelist>

    </para>
 
    </para>
 

-   <para>
-    You can also take advantage of the  <filename>/proc</filename>
-    file system that is a window into the inner workings of your
-    system. Use <command>cat</command> rather than
-    <command>more</command> to view the files as they are reported as
-    being zero length. Reports are that <command>less</command> works
-    well here.
-   </para>

   </sect2>
 
   </sect2>
 

-<!-- Section2: web -->
-
-  <sect2 id="web">
-   <title>Web Sites</title>
-
-    <indexterm>
-     <primary>disk!information resources!WWW</primary>
-    </indexterm>
-    <indexterm>
-     <primary>disk!information resources!web pages</primary>
-    </indexterm>
-
-   <para>
-    There are a huge number of informative web sites available. By
-    their very nature they change quickly so do not be surprised
-    if these links become quickly outdated.
-   </para>
-
-   <para>
-    A good starting point is of course the 
-    <ulink url="http://www.linuxdoc.org/">Linux Documentation
-    Project</ulink> home page, an information central for
-    documentation, project pages and much more.
-   </para>
+<!-- Section2: otherdev -->

 
 

+  <sect2 id="otherdev">
+   <title>Other Development issues</title>

    <para>
    <para>

-    Please let me know if you have any other leads that can be 
-    of interest.
+    There are more issues around surrounding interaction with
+    developers in a free software project that I can touch on in great
+    detail in a HOWTO of this size. Please don't hesitate to contact
+    me if you see any major omissions. Other smaller issues that are
+    worth mentioning are:

    </para>
    </para>

-  </sect2>
-
- </sect1>
-
-<!-- Section1: moreinfo: END -->
-
-
-<!-- Section1: help -->
-
- <sect1 id="help">
-  <title>Getting Help</title>
-
-   <indexterm>
-    <primary>(your index root)!assistance, obtaining</primary>
-   </indexterm>
-
-  <para>
-   In the end you might find yourself unable to solve your problems
-   and need help from someone else. The most efficient way is either
-   to ask someone local or in your nearest Linux user group, search
-   the web for the nearest one.
-  </para>
-
-  <para>
-   Another possibility is to ask on Usenet News in one of the many,
-   many newsgroups available. The problem is that these have such a
-   high volume and noise (called low signal-to-noise ratio) that your
-   question can easily fall through unanswered.
-  </para>
-
-  <para>
-   No matter where you ask it is important to ask well or you will
-   not be taken seriously. Saying just <emphasis remap="it">my disk
-   does not work</emphasis> is not going to help you and instead the
-   noise level is increased even further and if you are lucky someone
-   will ask you to clarify.
-  </para>
-
-  <para>
-   Instead describe your problems in some detail that will enable
-   people to help you. The problem could lie somewhere you did not
-   expect. Therefore you are advised to list the following information
-   about your system:
-  </para>
-
-  <para>
-   <variablelist>
-
-    <varlistentry>
-     <term>Hardware</Term>
-     <listitem>
-      <para>
-       <itemizedlist>
-       <listitem>
-        <para>Processor</para>
-       </listitem>
-
-       <listitem>
-        <para>DMA</para>
-       </listitem>
-
-       <listitem>
-        <para>IRQ</para>
-       </listitem>
-
-       <listitem>
-        <para>Chip set (LX, BX etc)</para>
-       </listitem>
-
-       <listitem>
-        <para>Bus (ISA, VESA, PCI etc)</para>
-       </listitem>
-
-       <listitem>
-        <para>
-          Expansion cards used (Disk controllers, video, IO 
-          etc.)
-         </para>
-       </listitem>
-
-       </itemizedlist>
-      </para>
-     </listitem>
-    </varlistentry>
-
-    <varlistentry>
-     <term>Software</term>
-     <listitem>
-      <para>
-       <itemizedlist>
-
-       <listitem>
-        <para>BIOS (On motherboard and possibly SCSI host adapters)</para>
-       </listitem>
-
-       <listitem>
-        <para>LILO, if used</para>
-       </listitem>
-
-       <listitem>
-        <para>
-          Linux kernel version as well as possible modifications 
-          and patches
-         </para>
-       </listitem>
-
-       <listitem>
-        <para>Kernel parameters, if any</para>
-       </listitem>
-
-       <listitem>
-        <para>
-          Software that shows the error (with version number 
-          or date)
-         </para>
-       </listitem>
-
-       </itemizedlist>
-      </para>
-
-     </listitem>
-    </varlistentry>
-
-    <varlistentry>
-     <term>Peripherals</term>
-     <listitem>
-      <para>
-       <itemizedlist>
-
-       <listitem>
-        <para>
-          Type of disk drives with manufacturer name, version and type
-         </para>
-       </listitem>
-
-       <listitem>
-        <para>Other relevant peripherals</para>
-       </listitem>
-
-       </itemizedlist>
-      </para>
-     </listitem>
-    </varlistentry>

 
 

-   </variablelist>
-  </para>
-
-  <para>
-   Remember that booting text is logged to
-   <filename>/var/log/messages</filename> which can answer most of
-   the questions above. Obviously if the drives fail you might not be
-   able to get  the log saved to disk but you can at least scroll
-   back up the screen using the <keycap>SHIFT</keycap> and
-   <keycap>PAGE UP</keycap> keys. It may also be useful to include
-   part of this in your request for help but do not go overboard,
-   keep it <emphasis>brief</emphasis> as a complete log file dumped
-   to Usenet News is more than a little annoying.
-  </para>
-
- </sect1>
-
-<!-- Section1: help: END -->
+   <sect3>
+    <title>Freezing</title>
+    <para>
+     For those projects that choose to adopt a split development model
+     (<xref linkend="branches">), freezing is a concept that is worth
+     becoming familiar with. 
+    </para>

 
 

+    <para>
+     Freeze come in two major forms. A <quote>feature freeze</quote>
+     is a period when no signifigant functionality is added to a
+     program. It is a period where established functionality (even
+     skeletons of barely working functionality) can be improved and
+     perfected. It is a period where bugs are fixed. This type of
+     freeze is usually applied some period (a month or two) before a
+     release. It is easy to push a release back as you wait for
+     <quote>one more feature</quote> and a freeze helps to avoid this
+     situation by drawing the much neede line in the sand. It gives
+     developers room they need to get a program ready for release.
+    </para>

 
 

-<!-- Section1: remarks -->
+    <para>
+     The second type of freeze is a <quote>code freeze</quote> which
+     is much more like a released piece of software. Once a piece of
+     software has entered a code freeze, all changes to the code are
+     frowned upon and only changes that fix known bugs are
+     permitted. This type of freeze usually follows a <quote>feature
+     freeze</quote> and directly preceeds a release. Most released
+     software is in what could be interpreted as a sort of high
+     level<quote>code freeze.</quote>
+    </para>

 
 

- <sect1 id="remarks">
-  <title>Concluding Remarks</title>
+    <para>
+     Even you do not choose to appoint a release manager (<xref
+     linkend="releasemanager">), you will have an easier time
+     justifying the rejection or postponement of patches (<xref
+     linkend="patching"> before a release with a publicly stated
+     freeze in effect.
+    </para>
+   </sect3>

 
 

-   <indexterm>
-    <primary>(your index root)!conclusion</primary>
-   </indexterm>
+   <sect3>
+    <title>Forking</title>
+    <para>
+     Forks are the most extreme interpretation of a branch. A fork is
+     when a group of developers takes code from a free software
+     project and actually starts a brand new free software
+     project. The most famous example of a fork is Emacs and
+     XEmacs. Both emacsen are based on an almost identical codebase
+     but for technical, political, and philisophical reasons,
+     development was split into two projects which now compete with
+     each other.
+    </para>

 
 

-  <para>
-   <emphasis>Just summing up... Also a place for general
-   recommendations.</emphasis>
-  </para>
+    <para>
+     The short version of the fork section is, <emphasis>don't do
+     them.</emphasis> Forks force developers to choose one project to
+     work with, cause nasty political divisions, redundancy of work.
+     Luckily, usually the threat of the fork is enough to scare the
+     maintainer or maintainers of a project into changing the way they
+     run their project to avoid it.
+    </para>

 
 

+    <para>
+     In his chapter on <quote>The Open Source Process,</quote> Karl
+     Fogel describes how to do a fork if you absolutely must. If you
+     have determined that is absolutely necessary and that the
+     differences between you and the people threatening to fork are
+     absolutely unresolvable, I recommend Fogel's book as a good place
+     to start.
+    </para>
+   </sect3>
+  </sect2>

  </sect1>
 
  </sect1>
 

-<!-- Section1: remarks: END -->
-
-
-<!-- Section1: faq -->
-
- <sect1 id="faq">
-  <title>Questions and Answers</title>
-
-   <indexterm>
-    <primary>(your index root)!FAQ</primary>
-   </indexterm>
-   <indexterm>
-    <primary>(your index root)!frequently asked questions</primary>
-   </indexterm>
-
-  <para>
-   <emphasis>Check the newsgroups and try to determine some frequent
-   problems and cover them here. Again an example from the Multi Disk
-   HOWTO.</emphasis>
-  </para>
+<!-- Section1: users -->

 
 

-  <para>
-   This is just a collection of what I believe are the most common
-   questions people might have. Give me more feedback and I will turn
-   this section into a proper FAQ.
-  </para>
+ <sect1 id="users">
+  <title>Maintaining a Project: Interacting with Users</title>
+  <indexterm>
+   <primary>fswd!users</primary>
+  </indexterm>

 
   <para>
 
   <para>

-   <itemizedlist>
-    <listitem>
-     <para>
-      Q:How many physical disk drives (spindles) does a Linux system need?
-     </para>
-
-     <para>
-      A: Linux can run just fine on one drive (spindle).  Having
-      enough  RAM (around 32 MB, and up to 64 MB) to support swapping
-      is a  better price/performance choice than getting a second
-      disk. (E)IDE disk is usually cheaper (but a little slower) than
-      SCSI.
-     </para>
-    </listitem>
-
-    <listitem>
-     <para>
-      Q: Are there any disadvantages in this scheme?
-     </para>
-
-     <para>
-      A: There is only a minor snag: if even a single partition
-      overflows the system might stop working properly. The severity
-      depends of course on what partition is affected. Still this is
-      not hard to monitor, the command <command>df</command> gives
-      you a good overview of the situation. Also check the swap
-      partition(s) using <command>free</command> to make sure you are
-      not about to run out of virtual memory.
-     </para>
-    </listitem>
-
-    <listitem>
-     <para>
-      Q: OK, so should I split the system into as many partitions as 
-      possible for a single drive?
-     </para>
-
-     <para>
-      A: No, there are several disadvantages to that. First of all
-      maintenance becomes needlessly complex and you gain very little
-      in this. In fact if your partitions are too big you will seek
-      across larger areas than needed. This is a balance and
-      dependent on the number of physical drives you have.
-     </para>
-    </listitem>
-
-   </itemizedlist>
-
-   <comment>
-    Greg Leblanc:  Depending on how big this FAQ gets, perhaps it
-    would be worthwhile to have, say, the 5 most FAQ, and put the
-    rest into an external FAQ.  Dunno.  Comments?
-   </comment>
-
-   <emphasis>(rest deleted.)</emphasis>
+   If you've worked your way up to here, congratuatlions, you are
+   nearing the end of this document. This final section touches upon 

   </para>
 
   </para>
 

- </sect1>
-
-<!-- Section1: faq: END -->

 
 

+<!-- Section2: testing -->

 
 

-<!-- Section1: bits-n-pieces -->
-
- <sect1 id="bits-n-pieces">
-  <title>Bits and Pieces </title>
-
-   <indexterm>
-    <primary>disk!miscellaneous</primary>
-   </indexterm>
-
-  <para>
-   This is basically a section where I stuff all the bits I have not
-   yet decided where should go, yet that I feel is worth knowing
-   about. It is a kind of transient area.
-  </para>
-
- </sect1>
+  <sect2 id="testing">
+   <title>Testing and Testers</title>
+   <para></para>
+  </sect2>

 
 

-<!-- Section1: bits-n-pieces: END -->
+<!-- Section2: support  -->

 
 

+  <sect2 id="support">
+   <title>Setting up a Support Infrastructure</title>
+   <para></para>
+  </sect2>

 
 

-<!-- Section1: examples -->
+<!-- Section2: releasing  -->

 
 

- <sect1 id="examples">
-  <title>Examples</title>
+  <sect2 id="releasing">
+   <title>Releasing Your Program</title>
+   <para></para>
+  </sect2>

 
 

-   <indexterm>
-    <primary>(your index root)!examples</primary>
-   </indexterm>
+<!-- Section2: announcing  -->

 
 

-  <para>
-   <emphasis>Example designs and sample configuration files and other
-   relevant details is always handy</emphasis>
-  </para>
+  <sect2 id="announcing">
+   <title>Announcing Your Project</title>
+   <para></para>
+  </sect2>

 
 

- </sect1>

 
 

-<!-- Section1: examples: END -->
+</sect1>

 
 </article>
 
 
 </article>
 


@@ -1465,4 +1844,4 @@ sgml-exposed-tags:nil
 sgml-local-catalogs:nil
 sgml-local-ecat-files:nil
 End:
 sgml-local-catalogs:nil
 sgml-local-ecat-files:nil
 End:

--->
+-->
\ No newline at end of file