-<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">\r
-\r
-<article>\r
-\r
-<!-- Header -->\r
-\r
- <artheader>\r
- <title>Free Software Development HOWTO</title>\r
-\r
- <author>\r
- <firstname>Benjamin</firstname>\r
- <othername>Mako</othername>\r
- <surnamen>Hill</surname>\r
- <affiliation>\r
- <address>\r
- <email>mako@debian.org</email>\r
- </address>\r
- </affiliation>\r
- </author>\r
-\r
- <revhistory>\r
- <revision>\r
- <revnumber>v0.01</revnumber>\r
- <date>1 January 2001</date>\r
- <authorinitials>bch</authorinitials>\r
- <revremark>\r
- Initial Release\r
- </revremark>\r
- </revision>\r
- </revhistory>\r
-\r
- <abstract>\r
- <indexterm>\r
- <primary>fswd</primary>\r
- </indexterm>\r
-\r
- <para>\r
- This HOWTO is designed for people with experience in programming\r
- and some skills in managing a software project but who are new to\r
- the world of Free Software. This document is meant to act as a\r
- guide to the non-technical aspects of programming and is meant as\r
- a crash course in the people skills that can make or break a free\r
- software project.\r
- </para>\r
- </abstract>\r
-\r
- </artheader>\r
-\r
-<!-- Section1: intro -->\r
-\r
- <sect1 id="intro">\r
- <title>Introduction</title>\r
-\r
- <indexterm>\r
- <primary>fswd!introduction</primary>\r
- </indexterm>\r
-\r
- <para>\r
- For various reasons this brand new release is codenamed the\r
- <emphasis>release</emphasis> release.\r
- </para>\r
-\r
- <para>\r
- New code names will appear as per industry standard\r
- guidelines to emphasize the state-of-the-art-ness of this\r
- document.\r
- </para>\r
-\r
- <para>\r
- This document was written when I read a feedback asking for a\r
- template to fill in to make new HOWTOs. This template was\r
- initially made by extracting the skeletal structure of the Multi\r
- Disk HOWTO which is a rather large HOWTO. It then went through\r
- extensive editing.\r
- </para>\r
-\r
- <para>\r
- Stating the background is a simple way to getting started\r
- writing the intro.\r
- </para>\r
-\r
- <para>\r
- First of all we need a bit of legalese. Recent development\r
- shows it is quite important.\r
- </para>\r
-\r
-<!-- Section2: copyright -->\r
-\r
- <sect2 id="copyright">\r
- <title>Copyright Information</title>\r
-\r
- <para>\r
- This document is copyrighted (c) 2000 Stein Gjoen and is\r
- distributed under the terms of the Linux Documentation Project\r
- (LDP) license, stated below. <emphasis>Replace with your name,\r
- or supply a new license, when you use this skeleton for a new\r
- HOWTO.</emphasis>\r
- </para>\r
-\r
- <para>\r
- Unless otherwise stated, Linux HOWTO documents are\r
- copyrighted by their respective authors. Linux HOWTO documents may\r
- be reproduced and distributed in whole or in part, in any medium\r
- physical or electronic, as long as this copyright notice is\r
- retained on all copies. Commercial redistribution is allowed and\r
- encouraged; however, the author would like to be notified of any\r
- such distributions.\r
- </para>\r
-\r
- <para>\r
- All translations, derivative works, or aggregate works\r
- incorporating any Linux HOWTO documents must be covered under this\r
- copyright notice. That is, you may not produce a derivative work\r
- from a HOWTO and impose additional restrictions on its\r
- distribution. Exceptions to these rules may be granted under\r
- certain conditions; please contact the Linux HOWTO coordinator at\r
- the address given below.\r
- </para>\r
-\r
- <para>\r
- In short, we wish to promote dissemination of this\r
- information through as many channels as possible. However, we do\r
- wish to retain copyright on the HOWTO documents, and would like to\r
- be notified of any plans to redistribute the HOWTOs.\r
- </para>\r
-\r
- <para>\r
- If you have any questions, please contact \r
- <email>linux-howto@metalab.unc.edu</email>\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: disclaimer -->\r
-\r
- <sect2 id="disclaimer">\r
- <title>Disclaimer</title>\r
-\r
- <para>\r
- No liability for the contents of this documents can be accepted.\r
- Use the concepts, examples and other content at your own risk.\r
- As this is a new edition of this document, there may be errors\r
- and inaccuracies, that may of course be damaging to your system.\r
- Proceed with caution, and although this is highly unlikely,\r
- the author(s) do not take any responsibility for that.\r
- </para>\r
-\r
- <para>\r
- All copyrights are held by their by their respective owners, unless\r
- specifically noted otherwise. Use of a term in this document\r
- should not be regarded as affecting the validity of any trademark\r
- or service mark.\r
- </para>\r
-\r
- <para>\r
- Naming of particular products or brands should not be seen \r
- as endorsements.\r
- </para>\r
-\r
- <para>\r
- You are strongly recommended to take a backup of your system \r
- before major installation and backups at regular intervals.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: newversions-->\r
-\r
- <sect2 id="newversions">\r
- <title>New Versions</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!news on</primary>\r
- </indexterm>\r
-\r
- <para>\r
- This is where you make a summary of what is new. When a\r
- HOWTO exceeds 20 pages it takes more than a casual read to find\r
- the updates. This is where you help your readers with that,\r
- alerting them to specific and important updates to the document.\r
- </para>\r
-\r
- <para>\r
- This is the initial release.\r
- </para>\r
-\r
- <para>\r
- Tell people where the document home page is so the very\r
- newest release could be found in case of problems with the main\r
- <ulink url="http://www.linuxdoc.org/">Linux Documentation\r
- Project</ulink> homepage.\r
- </para>\r
-\r
- <para>\r
- The following is a sample from the Multi Disk HOWTO:\r
- </para>\r
-\r
- <para>\r
- The latest version number of this document can be \r
- gleaned from my plan entry if you \r
- <ulink url="http://www.cs.indiana.edu/finger/nox.nyx.net/sgjoen">\r
- finger</ulink> my Nyx account.\r
- </para>\r
-\r
- <para>\r
- <emphasis>If you have the capability, it would be nice to \r
- make the HOWTO available in a number of formats.</emphasis>\r
- </para>\r
-\r
- <para>\r
- The newest version of this HOWTO will always be made available on\r
- my website, in a variety of formats:\r
- </para>\r
-\r
- <para>\r
- <itemizedlist>\r
- <listitem>\r
- <para>\r
- <ulink url="http://www.nyx.net/~sgjoen/disk.html">HTML</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink URL="http://www.nyx.net/~sgjoen/disk.txt">plain text</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://www.nyx.net/~sgjoen/disk-US.ps.gz">compressed \r
- postscript (US letter format)</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://www.nyx.net/~sgjoen/disk.sgml">SGML source</ulink>.\r
- </para>\r
- </listitem>\r
- </itemizedlist>\r
- </para>\r
-\r
- <para>\r
- Note that paper sizes vary in the world, A4 and US letter differ \r
- significantly. You might also wish to consider using the \r
- <emphasis>universal format</emphasis> (8.27x11in; 210x279mm). \r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: credits -->\r
-\r
- <sect2 id="credits">\r
- <title>Credits</title>\r
-\r
- <para>\r
- <emphasis>It is always nice to acknowledge people who help you\r
- with input; it is also regarded by many as important in the\r
- Linux world new economy.</emphasis>\r
- </para>\r
-\r
- <para>\r
- In this version I have the pleasure of acknowledging:\r
- </para>\r
-\r
- <para>\r
- <email>name (at) site.org</email>\r
- </para>\r
-\r
- <para>\r
- <emphasis>Please scramble the addresses so email harvesters\r
- cannot get addresses from your HOWTO and then spam people. That\r
- has happened in the past.</emphasis>\r
- </para>\r
-\r
- <para>\r
- <emphasis>Somecompany</emphasis> is acknowledged for sending me\r
- documentation on their gizmos as well as permission to quote from\r
- the material. These quotes have been approved before appearing\r
- here and will be clearly labeled.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: feedback -->\r
-\r
- <sect2 id="feedback">\r
- <title>Feedback</title>\r
-\r
- <para>\r
- Feedback is most certainly welcome for this document. Without\r
- your submissions and input, this document wouldn't exist. Please\r
- send your additions, comments and criticisms to the following\r
- email address : <email>sgjoen@nyx.net</email>.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: translations -->\r
-\r
- <sect2 id="translations">\r
- <title>Translations</title>\r
-\r
- <para>\r
- Not everyone speaks English, pointers to translations are nice.\r
- Also your translators tend to give very important inputs.\r
- </para>\r
-\r
- <para>\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://linuxdoc.org/">German Translation</ulink>\r
- by <email>someone (at) somewhere.de</email>\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://linuxdoc.org/">French Translation</ulink>\r
- by <email>someone (at) somewhere.fr</email>\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://linuxdoc.org/">Italian Translation</ulink>\r
- by <email>someone (at) somewhere.it</email>\r
- </para>\r
- </listitem>\r
- </itemizedlist>\r
- </para>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: intro: END -->\r
-\r
-<!-- Section1: starting -->\r
-\r
- <sect1 id="starting">\r
- <title>Starting a Project</title>\r
-\r
-<!-- Section2: chooseproject-->\r
-\r
- <sect2 id="chooseproject">\r
- <title>Choosing a Project</title>\r
- </sect2>\r
-\r
-<!-- Section2: chooselicense-->\r
-\r
- <sect2 id="chooselicense">\r
- <title>Deciding on a License</title>\r
- </sect2>\r
-\r
-<!-- Section2: chooseversioning-->\r
-\r
- <sect2 id="chooseversioning">\r
- <title>Choosing a Method of Version Numbering</title>\r
- </sect2>\r
-\r
-<!-- Section2: documentation-->\r
-\r
- <sect2 id="documentation">\r
- <title>Documentation</title>\r
- </sect2>\r
-\r
-<!-- Section2: presentation -->\r
-\r
- <sect2 id="presentation">\r
- <title>Other Presentation Issues</title>\r
- </sect2>\r
-\r
-<!-- Section2: futuredev -->\r
-\r
- <sect2 id="futuredev">\r
- <title>Nuturing Future Development</title>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: starting: END -->\r
-\r
-<!-- Section1: developers -->\r
-\r
- <sect1 id="developers">\r
- <title>Maintaining a Project: Interacting with Developers</title>\r
-\r
-<!-- Section2: delegation -->\r
-\r
- <sect2 id="delegation">\r
- <title>Delegating Work</title>\r
- </sect2>\r
-\r
-<!-- Section2: branches -->\r
-\r
- <sect2 id="branches">\r
- <title>Stable and Development Branches</title>\r
- </sect2>\r
-\r
-<!-- Section2: freezing -->\r
-\r
- <sect2 id="freezing">\r
- <title>Freezing</title>\r
- </sect2>\r
-\r
-<!-- Section2: codecram -->\r
-\r
- <sect2 id="codecram">\r
- <title>Avoiding the Code Cram Effect</title>\r
- </sect2>\r
-\r
-<!-- Section2: patching -->\r
-\r
- <sect2 id="patching">\r
- <title>Accepting and Rejecting Patches</title>\r
- </sect2>\r
- </sect1>\r
-\r
-<!-- Section1: users -->\r
-\r
- <sect1 id="users">\r
- <title>Maintaining a Project: Interacting with Users</title>\r
-\r
-<!-- Section2: announcing -->\r
-\r
- <sect2 id="announcing">\r
- <title>Announcing Your Project</title>\r
- </sect2>\r
-\r
-<!-- Section2: testing -->\r
-\r
- <sect2 id="testing">\r
- <title>Testing and Testers</title>\r
- </sect2>\r
-</sect1>\r
-\r
-<!-- Section1: samples -->\r
-\r
- <sect1 id="samples">\r
- <title>Samples</title>\r
-\r
- <para>\r
- <emphasis>This section gives some simple SGML examples you could\r
- use. Read the SGML source to see how it was done.</emphasis>\r
- </para>\r
-\r
- <para>\r
- Further information and examples can be obtained from the publication\r
- <ulink url="http://docbook.org/tdg/html/">DocBook: The Definitive \r
- Guide</ulink>. Written by <emphasis>Norman Walsh</emphasis>\r
- and <emphasis>Leonard Muellner</emphasis>; 1st Edition, October 1999.\r
- </para>\r
- \r
-<!-- Section2: lists -->\r
-\r
- <sect2 id="lists">\r
- <title>Lists</title>\r
-\r
- <para>\r
- <emphasis>Lists are used frequently, and are available in a number\r
- of formats shown below.</emphasis>\r
- </para>\r
-\r
- <para>\r
- A list in which each entry is marked with a bullet or other dingbat:\r
- </para>\r
-\r
- <para>\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>Apples</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Oranges</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Bananas</para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
-\r
- <para>\r
- A list in which each entry is composed of a set of one or more\r
- terms and an associated description:\r
- </para>\r
-\r
- <para>\r
- <variablelist>\r
-\r
- <varlistentry>\r
- <term>Fruits</term>\r
- <listitem>\r
- <para>such as apples, oranges, and more.</para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Nuts</term>\r
- <listitem>\r
- <para>Don't eat too many; you are what you eat.</para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Vegetables</term>\r
- <listitem>\r
- <para>Potatos are spelled with care.</para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- </variablelist>\r
- </para>\r
-\r
- <para>\r
- A list in which each entry is marked with a sequentially \r
- incremented label:\r
- </para>\r
-\r
- <para>\r
- <orderedlist>\r
-\r
- <listitem>\r
- <para>Step one</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Step two</para>\r
- </listitem>\r
-\r
- </orderedlist>\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: links -->\r
-\r
- <sect2 id="links">\r
- <title>Links</title>\r
-\r
- <para>\r
- <emphasis>Links can be used within your documents to refer to\r
- different sections and chapters or to refer to documents external\r
- to yours.</emphasis>\r
- </para>\r
-\r
- <sect3 id="int-links">\r
- <title>Internal links</title>\r
-\r
- <para>\r
- Click on the <xref LinkEnd="samples"> link to jump to the top of\r
- this chapter. Note the anchor at the section tag.\r
- </para>\r
- </sect3>\r
-\r
- <sect3 id="ext-links">\r
- <title>External links</title>\r
-\r
- <para>\r
- Click on <ulink url="http://www.linuxdoc.org/">this</ulink> link\r
- to jump to the LDP site. Note you can use http, ftp, news and\r
- other protocols in the locator if required.\r
- </para>\r
- </sect3>\r
-\r
- </sect2>\r
-\r
-<!-- Section2: images -->\r
-\r
- <sect2 id="images">\r
- <title>Images</title>\r
-\r
- <para>\r
- <emphasis>Avoid diagrams if possible as this cannot be rendered\r
- in the ASCII outputs which are still needed by many around the\r
- world.</emphasis>\r
- </para>\r
-\r
- <para>\r
- <figure>\r
- <title>Graphics Test Image</title>\r
- <graphic FileRef="red.gif"></graphic>\r
- </figure>\r
- </para>\r
-\r
- <para>\r
- Here is another variation which allows for ALT text:\r
- </para>\r
-\r
- <para>\r
- <mediaobject>\r
-\r
- <imageobject>\r
- <imagedata fileref="green.gif" format="gif">\r
- </imageobject>\r
-\r
- <textobject>\r
- <phrase>\r
- ALT text to be used: Green Ball\r
- </phrase>\r
- </textobject>\r
-\r
- <caption>\r
- <para>\r
- Caption for the graphic goes here: This is a Green Ball.\r
- </para>\r
- </caption>\r
- </mediaobject>\r
- </para>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: samples: END -->\r
-\r
-\r
-<!-- Section1: structure -->\r
-\r
- <sect1 id="structure">\r
- <title>Structure</title>\r
-\r
- <para>\r
- <emphasis>A quick overview on how all parts fit together in the overall\r
- structure. An example from the Multi Disk HOWTO is used.</emphasis>\r
- </para>\r
-\r
- <para>\r
- As this type of document is supposed to be as much for learning as\r
- a technical reference document I have rearranged the structure to\r
- this end. For the designer of a system it is more useful to have\r
- the information presented in terms of the goals of this exercise\r
- than from the point of view of the logical layer structure of the\r
- devices themselves. Nevertheless this document would not be\r
- complete without such a layer structure the computer field is so\r
- full of, so I will include it here as an introduction to how it\r
- works.\r
- </para>\r
-\r
-<!-- Section2: logical-struct -->\r
-\r
- <sect2 id="logical-struct">\r
- <title>Logical structure</title>\r
-\r
- <indexterm>\r
- <primary>disk!structure, I/O subsystem</primary>\r
- </indexterm>\r
-\r
- <para>\r
- This is based on how each layer access each other, traditionally\r
- with the application on top and the physical layer on the bottom.\r
- It is quite useful to show the interrelationship between each of\r
- the layers used in controlling drives.\r
-\r
- <screen>\r
- ___________________________________________________________\r
- |__ File structure ( /usr /tmp etc) __|\r
- |__ File system (ext2fs, vfat etc) __|\r
- |__ Volume management (AFS) __|\r
- |__ RAID, concatenation (md) __|\r
- |__ Device driver (SCSI, IDE etc) __|\r
- |__ Controller (chip, card) __|\r
- |__ Connection (cable, network) __|\r
- |__ Drive (magnetic, optical etc) __|\r
- -----------------------------------------------------------\r
- </screen>\r
- </para>\r
-\r
- <para>\r
- In the above diagram both volume management and RAID and\r
- concatenation are optional layers. The 3 lower layers are in\r
- hardware. All parts are discussed at length later on in this\r
- document.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: doc-struct -->\r
-\r
- <sect2 id="doc-struct">\r
- <title>Document structure</title>\r
-\r
- <para>\r
- Most users start out with a given set of hardware and some plans\r
- on what they wish to achieve and how big the system should be.\r
- This is the point of view I will adopt in this document in\r
- presenting the material, starting out with hardware, continuing\r
- with design constraints before detailing the design strategy that\r
- I have found to work well. I have used this both for my own\r
- personal computer at home, a multi purpose server at work and\r
- found it worked quite well. In addition my Japanese co-worker in\r
- this project have applied the same strategy on a server in an\r
- academic setting with similar success.\r
- </para>\r
-\r
- <para>\r
- Finally at the end I have detailed some configuration tables for\r
- use in your own design. If you have any comments regarding this\r
- or notes from your own design work I would like to hear from you\r
- so this document can be upgraded.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: reading-plan -->\r
-\r
- <sect2 id="reading-plan">\r
- <title>Reading plan</title>\r
-\r
- <para>\r
- <emphasis>As you go beyond 50 pages or so there will be a lot of\r
- text that experts and even the experienced do not need to read.\r
- Keeping in mind that we wish to care for all kinds of people in\r
- the Linux world we might have to make a reading plan. Again,\r
- an example follows from the Multi Disk HOWTO.</emphasis>\r
- </para>\r
-\r
- <para>\r
- Although not the biggest HOWTO it is nevertheless rather big\r
- already and I have been requested to make a reading plan to make\r
- it possible to cut down on the volume.\r
- </para>\r
-\r
- <para>\r
- <variablelist>\r
-\r
- <varlistentry>\r
- <term>Expert</term>\r
- <listitem>\r
- <para>\r
- (aka the elite). If you are familiar with Linux as well as\r
- disk drive technologies you will find most of what you need in\r
- the appendices. Additionally you are recommended to read the\r
- FAQ and the <XRef LinkEnd="bits-n-pieces">chapter.\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Experienced</term>\r
- <listitem>\r
- <para>\r
- (aka Competent). If you are familiar with computers in\r
- general you can go straight to the chapters on \r
- <XRef LinkEnd="technologies"> and continue from there on.\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Newbie</term>\r
- <listitem>\r
- <para>\r
- (mostly harmless). You just have to read the whole thing.\r
- Sorry. In addition you are also recommended to read all the\r
- other disk related HOWTOs.\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- </variablelist>\r
- </para>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: structure: END -->\r
-\r
-\r
-<!-- Section1: technologies -->\r
-\r
- <sect1 id="technologies">\r
- <title>Technologies</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!technologies</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Introduction of technology for the newbie with a few\r
- references to detailed works. Remember that not everyone has\r
- Internet access so you have to explain in sufficient details so\r
- even the newbie can get by.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: technologies: END -->\r
-\r
-\r
-<!-- Section1: implement -->\r
-\r
- <sect1 id="implement">\r
- <title>Implementation</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!implementation</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Now your readers should have a sufficient knowledge of\r
- what this is about and now we come to the hands on of implementing\r
- your clever scheme.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: implement: END -->\r
-\r
-\r
-<!-- Section1: maint -->\r
-\r
- <sect1 id="maint">\r
- <title>Maintenance</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!maintenance</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Few systems and designs are maintenance free, here you\r
- explain how to keep the system running.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: maint: END -->\r
-\r
-\r
-<!-- Section1: adv-issues -->\r
-\r
- <sect1 id="adv-issues">\r
- <title>Advanced Issues</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!advanced topics</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>You can get most things up and running in a quick and\r
- dirty fashion, useful for testing and getting used to how things\r
- work. For more serious use you would need to be a little more\r
- advanced. This is the place to explain it all, if applicable.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: adv-issues: END -->\r
-\r
-\r
-<!-- Section1: moreinfo -->\r
-\r
- <sect1 id="moreinfo">\r
- <title>Further Information</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!information resources</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>A HOWTO cannot describe everything, some times the user\r
- has to venture out on th enet to get more information or just\r
- updates. Here is the place to tell where and how. Again examples\r
- from the Multi Disk HOWTO, replace as needed.</emphasis> There is wealth\r
- of information one should go through when setting up a major system,\r
- for instance for a news or general Internet service provider. The\r
- FAQs in the following groups are useful:\r
- </para>\r
-\r
-<!-- Section2: newsgroups -->\r
-\r
- <sect2 id="newsgroups">\r
- <title>News groups</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!news groups</primary>\r
- </indexterm>\r
-\r
- <para>Some of the most interesting news groups are:\r
-\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:comp.arch.storage">Storage</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:comp.sys.ibm.pc.hardware.storage">PC storage</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:alt.filesystems.afs">AFS</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:comp.periphs.scsi">SCSI</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="news:comp.os.linux.setup">Linux setup</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
-\r
- <para>\r
- Most newsgroups have their own FAQ that are designed to answer most\r
- of your questions, as the name Frequently Asked Questions indicate.\r
- Fresh versions should be posted regularly to the relevant newsgroups.\r
- If you cannot find it in your news spool you could go directly to the\r
- <ulink url="ftp://rtfm.mit.edu/">FAQ main archive FTP site</ulink>.\r
- The WWW versions can be browsed at the \r
- <ulink url="http://www.cis.ohio-state.edu/hypertext/faq/usenet/FAQ-List.html">FAQ\r
- main archive WWW site</ulink>.\r
- </para>\r
-\r
- <para>\r
- Some FAQs have their own home site, of particular interest:\r
-\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://www.paranoia.com/~filipg/HTML/LINK/F_SCSI.html">SCSI FAQ</ulink> \r
- and\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- <ulink url="http://alumni.caltech.edu/~rdv/comp_arch_storage/FAQ-1.html">comp.arch.storage FAQ</ulink>.\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: maillists -->\r
-\r
- <sect2 id="maillists">\r
- <title>Mailing Lists</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!mailing lists</primary>\r
- </indexterm>\r
-\r
- <para>\r
- These are low-noise channels mainly for developers. Think twice\r
- before asking questions there as noise delays the development.\r
- Some relevant lists are <email>linux-raid</email>,\r
- <email>linux-scsi</email> and <email>linux-ext2fs</email>. Many\r
- of the most useful mailing lists run on the <Literal\r
- remap="tt">vger.rutgers.edu</Literal> server but this is\r
- notoriously overloaded, so try to find a mirror. There are some\r
- lists mirrored at <ulink url="http://www.redhat.com">The Redhat\r
- Home Page</ulink>. Many lists are also accessible at <ulink\r
- url="http://www.linuxhq.com/lnxlists">linuxhq</ulink>, and the\r
- rest of the web site contains useful information as well.\r
- </para>\r
-\r
- <para>\r
- If you want to find out more about the lists available you can send\r
- a message with the line <command>lists</command> to the list server\r
- at <email>majordomo@vger.rutgers.edu</email>.\r
- If you need help on how to use the mail server just send the line\r
- <command>help</command> to the same address. Due to the\r
- popularity of this server it is likely it takes a bit to time before\r
- you get a reply or even get messages after you send a\r
- <command>subscribe</command> command.\r
- </para>\r
-\r
- <para>\r
- There is also a number of other majordomo list servers that can\r
- be of interest such as the EATA driver list\r
- (<email>linux-eata@mail.uni-mainz.de</email>)\r
- and the Intelligent IO list <email>linux-i2o@dpt.com</email>.\r
- </para>\r
-\r
- <para>\r
- Mailing lists are in a state of flux but you can find links to a\r
- number of interesting lists from the \r
- <ulink url="http://www.linuxdoc.org/">Linux Documentation\r
- Homepage</ulink>.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: howto -->\r
-\r
- <sect2 id="howto">\r
- <title>HOWTO</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!HOWTOs</primary>\r
- </indexterm>\r
-\r
- <para>\r
- These are intended as the primary starting points to get the\r
- background information as well as show you how to solve a\r
- specific problem. Some relevant HOWTOs are\r
- <Literal remap="tt">Bootdisk</Literal>, \r
- <Literal remap="tt">Installation</Literal>,\r
- <Literal remap="tt">SCSI</Literal> and \r
- <Literal remap="tt">UMSDOS</Literal>. The main site for these is the\r
- <ulink url="http://www.linuxdoc.org/">LDP archive</ulink>at\r
- Metalab (formerly known as Sunsite).\r
- </para>\r
-\r
- <para>\r
- There is a a new HOWTO out that deals with setting up a DPT RAID\r
- system, check out the\r
- <ulink url="http://www.ram.org/computing/linux/dpt_raid.html">DPT RAID\r
- HOWTO homepage</ulink>.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: local-res -->\r
-\r
- <sect2 id="local-res">\r
- <title>Local Resources</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!local</primary>\r
- </indexterm>\r
-\r
- <para>\r
- In most distributions of Linux there is a document directory\r
- installed, have a look in the <filename>/usr/doc</filename>\r
- directory. where most packages store their main documentation and\r
- README files etc. Also you will here find the HOWTO archive \r
- (<filename>/usr/doc/HOWTO</filename>) of ready formatted HOWTOs\r
- and also the mini-HOWTO archive \r
- (<filename>/usr/doc/HOWTO/mini</filename>) of plain text\r
- documents.\r
- </para>\r
-\r
- <para>\r
- Many of the configuration files mentioned earlier can be found in\r
- the <filename>/etc</filename> directory. In particular you will\r
- want to work with the <filename>/etc/fstab</filename> file that\r
- sets up the mounting of partitions and possibly also\r
- <filename>/etc/raidtab</filename> file that is used for the\r
- <Literal remap="tt">md</Literal> system to set up RAID.\r
- </para>\r
-\r
- <para>\r
- The kernel source in <filename>/usr/src/linux</filename> is, of\r
- course, the ultimate documentation. In other words, <quote>use\r
- the source, Luke</quote>. It should also be pointed out that the\r
- kernel comes not only with source code which is even commented\r
- (well, partially at least) but also an informative\r
- <filename>/usr/src/linux/Documentation</filename>. If you are\r
- about to ask any questions about the kernel you should read this\r
- first, it will save you and many others a lot of time and\r
- possibly embarrassment.\r
- </para>\r
-\r
- <para>\r
- Also have a look in your system log file\r
- (<filename>/var/log/messages</filename>) to see what is going on\r
- and in particular how the booting went if too much scrolled off\r
- your screen. Using <command>tail -f /var/log/messages</command>\r
- in a separate window or screen will give you a continuous update\r
- of what is going on in your system.\r
- </para>\r
-\r
- <para>\r
- You can also take advantage of the <filename>/proc</filename>\r
- file system that is a window into the inner workings of your\r
- system. Use <command>cat</command> rather than\r
- <command>more</command> to view the files as they are reported as\r
- being zero length. Reports are that <command>less</command> works\r
- well here.\r
- </para>\r
- </sect2>\r
-\r
-<!-- Section2: web -->\r
-\r
- <sect2 id="web">\r
- <title>Web Sites</title>\r
-\r
- <indexterm>\r
- <primary>disk!information resources!WWW</primary>\r
- </indexterm>\r
- <indexterm>\r
- <primary>disk!information resources!web pages</primary>\r
- </indexterm>\r
-\r
- <para>\r
- There are a huge number of informative web sites available. By\r
- their very nature they change quickly so do not be surprised\r
- if these links become quickly outdated.\r
- </para>\r
-\r
- <para>\r
- A good starting point is of course the \r
- <ulink url="http://www.linuxdoc.org/">Linux Documentation\r
- Project</ulink> home page, an information central for\r
- documentation, project pages and much more.\r
- </para>\r
-\r
- <para>\r
- Please let me know if you have any other leads that can be \r
- of interest.\r
- </para>\r
- </sect2>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: moreinfo: END -->\r
-\r
-\r
-<!-- Section1: help -->\r
-\r
- <sect1 id="help">\r
- <title>Getting Help</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!assistance, obtaining</primary>\r
- </indexterm>\r
-\r
- <para>\r
- In the end you might find yourself unable to solve your problems\r
- and need help from someone else. The most efficient way is either\r
- to ask someone local or in your nearest Linux user group, search\r
- the web for the nearest one.\r
- </para>\r
-\r
- <para>\r
- Another possibility is to ask on Usenet News in one of the many,\r
- many newsgroups available. The problem is that these have such a\r
- high volume and noise (called low signal-to-noise ratio) that your\r
- question can easily fall through unanswered.\r
- </para>\r
-\r
- <para>\r
- No matter where you ask it is important to ask well or you will\r
- not be taken seriously. Saying just <emphasis remap="it">my disk\r
- does not work</emphasis> is not going to help you and instead the\r
- noise level is increased even further and if you are lucky someone\r
- will ask you to clarify.\r
- </para>\r
-\r
- <para>\r
- Instead describe your problems in some detail that will enable\r
- people to help you. The problem could lie somewhere you did not\r
- expect. Therefore you are advised to list the following information\r
- about your system:\r
- </para>\r
-\r
- <para>\r
- <variablelist>\r
-\r
- <varlistentry>\r
- <term>Hardware</Term>\r
- <listitem>\r
- <para>\r
- <itemizedlist>\r
- <listitem>\r
- <para>Processor</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>DMA</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>IRQ</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Chip set (LX, BX etc)</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Bus (ISA, VESA, PCI etc)</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Expansion cards used (Disk controllers, video, IO \r
- etc.)\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Software</term>\r
- <listitem>\r
- <para>\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>BIOS (On motherboard and possibly SCSI host adapters)</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>LILO, if used</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Linux kernel version as well as possible modifications \r
- and patches\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Kernel parameters, if any</para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Software that shows the error (with version number \r
- or date)\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
-\r
- </listitem>\r
- </varlistentry>\r
-\r
- <varlistentry>\r
- <term>Peripherals</term>\r
- <listitem>\r
- <para>\r
- <itemizedlist>\r
-\r
- <listitem>\r
- <para>\r
- Type of disk drives with manufacturer name, version and type\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>Other relevant peripherals</para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
- </para>\r
- </listitem>\r
- </varlistentry>\r
-\r
- </variablelist>\r
- </para>\r
-\r
- <para>\r
- Remember that booting text is logged to\r
- <filename>/var/log/messages</filename> which can answer most of\r
- the questions above. Obviously if the drives fail you might not be\r
- able to get the log saved to disk but you can at least scroll\r
- back up the screen using the <keycap>SHIFT</keycap> and\r
- <keycap>PAGE UP</keycap> keys. It may also be useful to include\r
- part of this in your request for help but do not go overboard,\r
- keep it <emphasis>brief</emphasis> as a complete log file dumped\r
- to Usenet News is more than a little annoying.\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: help: END -->\r
-\r
-\r
-<!-- Section1: remarks -->\r
-\r
- <sect1 id="remarks">\r
- <title>Concluding Remarks</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!conclusion</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Just summing up... Also a place for general\r
- recommendations.</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: remarks: END -->\r
-\r
-\r
-<!-- Section1: faq -->\r
-\r
- <sect1 id="faq">\r
- <title>Questions and Answers</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!FAQ</primary>\r
- </indexterm>\r
- <indexterm>\r
- <primary>(your index root)!frequently asked questions</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Check the newsgroups and try to determine some frequent\r
- problems and cover them here. Again an example from the Multi Disk\r
- HOWTO.</emphasis>\r
- </para>\r
-\r
- <para>\r
- This is just a collection of what I believe are the most common\r
- questions people might have. Give me more feedback and I will turn\r
- this section into a proper FAQ.\r
- </para>\r
-\r
- <para>\r
- <itemizedlist>\r
- <listitem>\r
- <para>\r
- Q:How many physical disk drives (spindles) does a Linux system need?\r
- </para>\r
-\r
- <para>\r
- A: Linux can run just fine on one drive (spindle). Having\r
- enough RAM (around 32 MB, and up to 64 MB) to support swapping\r
- is a better price/performance choice than getting a second\r
- disk. (E)IDE disk is usually cheaper (but a little slower) than\r
- SCSI.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Q: Are there any disadvantages in this scheme?\r
- </para>\r
-\r
- <para>\r
- A: There is only a minor snag: if even a single partition\r
- overflows the system might stop working properly. The severity\r
- depends of course on what partition is affected. Still this is\r
- not hard to monitor, the command <command>df</command> gives\r
- you a good overview of the situation. Also check the swap\r
- partition(s) using <command>free</command> to make sure you are\r
- not about to run out of virtual memory.\r
- </para>\r
- </listitem>\r
-\r
- <listitem>\r
- <para>\r
- Q: OK, so should I split the system into as many partitions as \r
- possible for a single drive?\r
- </para>\r
-\r
- <para>\r
- A: No, there are several disadvantages to that. First of all\r
- maintenance becomes needlessly complex and you gain very little\r
- in this. In fact if your partitions are too big you will seek\r
- across larger areas than needed. This is a balance and\r
- dependent on the number of physical drives you have.\r
- </para>\r
- </listitem>\r
-\r
- </itemizedlist>\r
-\r
- <comment>\r
- Greg Leblanc: Depending on how big this FAQ gets, perhaps it\r
- would be worthwhile to have, say, the 5 most FAQ, and put the\r
- rest into an external FAQ. Dunno. Comments?\r
- </comment>\r
-\r
- <emphasis>(rest deleted.)</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: faq: END -->\r
-\r
-\r
-<!-- Section1: bits-n-pieces -->\r
-\r
- <sect1 id="bits-n-pieces">\r
- <title>Bits and Pieces </title>\r
-\r
- <indexterm>\r
- <primary>disk!miscellaneous</primary>\r
- </indexterm>\r
-\r
- <para>\r
- This is basically a section where I stuff all the bits I have not\r
- yet decided where should go, yet that I feel is worth knowing\r
- about. It is a kind of transient area.\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: bits-n-pieces: END -->\r
-\r
-\r
-<!-- Section1: examples -->\r
-\r
- <sect1 id="examples">\r
- <title>Examples</title>\r
-\r
- <indexterm>\r
- <primary>(your index root)!examples</primary>\r
- </indexterm>\r
-\r
- <para>\r
- <emphasis>Example designs and sample configuration files and other\r
- relevant details is always handy</emphasis>\r
- </para>\r
-\r
- </sect1>\r
-\r
-<!-- Section1: examples: END -->\r
-\r
-</article>\r
-\r
-<!-- Keep this comment at the end of the file\r
-Local variables:\r
-mode: sgml\r
-sgml-omittag:t\r
-sgml-shorttag:t\r
-sgml-namecase-general:t\r
-sgml-general-insert-case:lower\r
-sgml-minimize-attributes:nil\r
-sgml-always-quote-attributes:t\r
-sgml-indent-step:1\r
-sgml-indent-data:nil\r
-sgml-parent-document:nil\r
-sgml-exposed-tags:nil\r
-sgml-local-catalogs:nil\r
-sgml-local-ecat-files:nil\r
-End:\r
--->\r
+<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
+
+<article>
+
+<!-- Header -->
+
+ <artheader>
+ <title>Free Software Development HOWTO</title>
+
+ <author>
+ <firstname>Benjamin</firstname>
+ <othername>Mako</othername>
+ <surname>Hill</surname>
+ <affiliation>
+ <address>
+ <email>mako@debian.org</email>
+
+ </address>
+ </affiliation>
+ </author>
+
+ <revhistory>
+ <revision>
+ <revnumber>v0.01</revnumber>
+ <date>25 March 2001</date>
+ <authorinitials>bch</authorinitials>
+ <revremark>
+ Initial Release
+ </revremark>
+ </revision>
+ </revhistory>
+
+ <abstract>
+ <indexterm>
+ <primary>fswd</primary>
+ </indexterm>
+
+ <para>
+ This HOWTO is designed for people with experience in programming
+ and some skills in managing a software project but who are new to
+ the world of Free Software. This document is meant to act as a
+ guide to the non-technical aspects of programming and was written
+ to act as a crash course in the people skills that aren't taught
+ to commercial coders but that can make or break a free software
+ project.
+ </para>
+ </abstract>
+
+ </artheader>
+
+<!-- Section1: intro -->
+
+ <sect1 id="intro">
+ <title>Introduction</title>
+
+ <indexterm>
+ <primary>fswd!introduction</primary>
+ </indexterm>
+
+ <para>
+ For various reasons, this release has been code-named the
+ <emphasis>homemade yogurt</emphasis> release.
+ </para>
+
+ <para>
+ New code names will appear as per industry standard
+ guidelines to emphasize the state-of-the-art-ness of this
+ document.
+ </para>
+
+ <para>
+ Skimming through freshmeat.net provides mountains of reasons for this
+ HOWTO's existence--the Internet is littered with excellently
+ written and useful programs that have faded away into the Universe
+ of Free Software Forgottenness. This dismal scene made me ask
+ myself, "Why?"
+ </para>
+
+ <para>
+ This HOWTO tries to do a lot of thing (probably too many), but it
+ can't answer that question and won't attempt it. What this HOWTO
+ will attempt to do is give your Free Software project a fighting
+ chance-an edge. If you write a piece of crap that no one is
+ interested in, you can read this HOWTO until you recite it in your
+ sleep and your project will probably fail. Then again, you can
+ write a beautiful, relevant piece of software and follow every
+ instruction in this HOWTO and your software may still not make
+ it. Sometimes life is like that. However, I'll go out a limb and
+ say that if you write a great, relevant pieces of software and
+ ignore the advise in this HOWTO, you'll probably fail <emphasis>
+ more often</emphasis>.
+ </para>
+
+ <para>
+ A lot of the information in this HOWTO is best called common
+ sense. Of course, as any debate on interfaces will prove, what is
+ common sense to some programmers proves totally unintuitive to
+ others. After explaining bites and pieces of this HOWTO to Free
+ Software developers on several occasions, I realized that that
+ writing this HOWTO might provide a useful resource and a forum for
+ programmers to share ideas about what has and has not worked for
+ them.
+ </para>
+
+ <para>
+
+ </para>
+
+ <para>
+ As anyone involved in any of what seems like an unending parade of
+ ridiculous intellectual property clashes will attest to, a little
+ bit of legalese proves important.
+ </para>
+
+<!-- Section2: copyright -->
+
+ <sect2 id="copyright">
+ <title>Copyright Information</title>
+
+ <para>
+ This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is
+ distributed under the terms of the Linux Documentation Project
+ (LDP) license, stated below.
+ </para>
+
+ <para>
+ Unless otherwise stated, Linux HOWTO documents are
+ copyrighted by their respective authors. Linux HOWTO documents may
+ be reproduced and distributed in whole or in part, in any medium
+ physical or electronic, as long as this copyright notice is
+ retained on all copies. Commercial redistribution is allowed and
+ encouraged; however, the author would like to be notified of any
+ such distributions.
+ </para>
+
+ <para>
+ All translations, derivative works, or aggregate works
+ incorporating any Linux HOWTO documents must be covered under this
+ copyright notice. That is, you may not produce a derivative work
+ from a HOWTO and impose additional restrictions on its
+ distribution. Exceptions to these rules may be granted under
+ certain conditions; please contact the Linux HOWTO coordinator at
+ the address given below.
+ </para>
+
+ <para>
+ In short, we wish to promote dissemination of this
+ information through as many channels as possible. However, we do
+ wish to retain copyright on the HOWTO documents, and would like to
+ be notified of any plans to redistribute the HOWTOs.
+ </para>
+
+ <para>
+ If you have any questions, please contact
+ <email>linux-howto@metalab.unc.edu</email>
+ </para>
+ </sect2>
+
+<!-- Section2: disclaimer -->
+
+ <sect2 id="disclaimer">
+ <title>Disclaimer</title>
+
+ <para>
+ No liability for the contents of this documents can be accepted.
+ Use the concepts, examples and other content at your own risk.
+ As this is a new edition of this document, there may be errors
+ and inaccuracies, that may of course be damaging to your system.
+ Proceed with caution, and although this is highly unlikely,
+ the author(s) do not take any responsibility for that.
+ </para>
+
+ <para>
+ All copyrights are held by their by their respective owners, unless
+ specifically noted otherwise. Use of a term in this document
+ should not be regarded as affecting the validity of any trademark
+ or service mark.
+ </para>
+
+ <para>
+ Naming of particular products or brands should not be seen
+ as endorsements.
+ </para>
+
+ <para>
+ You are strongly recommended to take a backup of your system
+ before major installation and backups at regular intervals.
+ </para>
+ </sect2>
+
+<!-- Section2: newversions-->
+
+ <sect2 id="newversions">
+ <title>New Versions</title>
+
+ <indexterm>
+ <primary>(your index root)!news on</primary>
+ </indexterm>
+
+ <para>
+ This is the initial release. It is written to be released to
+ developers for critique and brainstorming and submitted to
+ Hampshire College for academic credit. Please keep in mind that
+ this version of the HOWTO is still in an infant stage and will be
+ revised extensively before it hits the LDP.
+ </para>
+
+ <para>
+ 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>
+ The newest version of this HOWTO will always be made available at
+ the same website, in a variety of formats:
+ </para>
+
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://people.debian.org/~mako/howto/fswd-howto.html">HTML</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink URL="http://people.debian.org/~mako/howto/fswd-howto.txt">plain text</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink url="http://people.debian.org/~mako/howto/fswd-howto.US.ps.gz">compressed
+ postscript (US letter format)</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink url="http://people.debian.org/~mako/howto/fswd-howto.UF.ps.gz">compressed
+ postscript (Universal format / 8.27x11in; 210x279mm)</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink url="http://people.debian.org/~mako/howto/fswd-howto.sgml">SGML source</ulink>.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect2>
+
+<!-- Section2: credits -->
+
+ <sect2 id="credits">
+ <title>Credits</title>
+
+ <para>
+ In this version I have the pleasure of acknowledging:
+ </para>
+
+ <para>
+ <emphasis>Karl Fogel</emphasis>, the author of <emphasis>Open
+ Source Development with CVS</emphasis> published by the Coriolis
+ Open Press. Large parts of the book are available <ulink
+ url="http://cvsbook.red-bean.com">on the web</ulink>. 225 pages of
+ the book are available under the GPL and constitute the best
+ tutorial on CVS I have ever seen. The rest of the book covers,
+ "the challenges and philosophical issues inherent in running an
+ Open Source project using CVS." The book does a good job of
+ covering some of the subjects brought up in this HOWTO and much
+ more. <ulink url="http://cvsbook.red-bean.com">The book's
+ website</ulink> has information on ordering the book and provides
+ several translations of the chapters on CVS. I you are seriously
+ interested in running a Free Software project, you want this book.
+ </para>
+
+ <para>
+ Karl Fogel can be reached at <email>kfogel (at) red-bean (dot)
+ com</email>
+ </para>
+ <para>
+ Also providing support and material, and inspiration for this
+ HOWTO is Eric S. Raymond for his prolific, consistent, and
+ carefully crafted arguments, to Lawrence Lessig for reminding me
+ of the importance of Free Software and to every user and developer
+ involved with the <ulink url="http://www.debian.org">Debian
+ Project</ulink>. The project has provided me with a home, a place
+ to practice Free Software advocacy and to make a difference, a
+ place to learn from those how have been involved with the movement
+ much longer than I, and an proof of a Free Software project that
+ <emphasis>definitely, definitely works</emphasis>.
+ </para>
+
+ <para>
+ Above all, I want to thank <emphasis>Richard Stallman</emphasis>
+ for his work at the Free Software Foundation and for never giving
+ up. Stallman provided the philosophical basis that attracts me to
+ Free Software and that drives me towards writing a document to
+ make sure it succeeds. RMS can always be emailed at <email>rms
+ (at) gnu (dot) org</email>.
+ </para>
+
+ </sect2>
+
+<!-- Section2: feedback -->
+
+ <sect2 id="feedback">
+ <title>Feedback</title>
+
+ <para>
+ Feedback is most certainly welcome for this document. Without your
+ submissions and input, this document wouldn't exist. Something
+ missing? Don't hesitate to contact me and to write a chapter. I
+ want this document to be as much a product of the Free Software
+ 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@debian. org</email>.
+ </para>
+ </sect2>
+
+<!-- Section2: translations -->
+
+ <sect2 id="translations">
+ <title>Translations</title>
+
+ <para>
+ I know that not everyone speaks English. Translations are nice and
+ I'd love for this HOWTO to gain the kind of international reach
+ afforded by a translated version.
+ </para>
+ <para>
+ However, this HOWTO is still young and I have to yet to be
+ contacted about a translation so English is all that is
+ 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@debian.org</email>.
+ </para>
+ </sect2>
+ </sect1>
+
+<!-- Section1: intro: END -->
+
+<!-- Section1: starting -->
+
+ <sect1 id="starting">
+ <title>Starting a Project</title>
+
+ <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 dilemma 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 someone 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>
+
+ <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
+ enough to necessitate a separate project.
+ </para>
+
+ <sect3 id=identifyidea>
+ <title>Identify 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 software development. You can find it <ulink
+ url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/">online
+ </ulink>.
+ </para>
+
+ <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>
+
+ <para>
+ If you have an idea for a program in mind, chances are good that
+ it it is targeting 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>
+
+ <sect3 id=evalulateidea>
+ <title>Evaluate your idea</title>
+
+ <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 definitely 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>
+
+ <para>
+ Sometimes the answer is <emphasis>no</emphasis>. If you want to
+ write a set of scripts to sort <emphasis>your</emphasis>
+ <acronym>MP3</acronym> 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> <acronym>MP3</acronym>s, a free
+ software project might fill a useful gap.
+ </para>
+
+ <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 development effort to be
+ announced here so it definitely worth checking.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>SourceForge:</term>
+ <listitem>
+ <para><ulink url="http://sourceforge.net">SourceForge</ulink>
+ houses and facilitates a growing 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 reusable chunks of
+ code in an array of languages 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 powerful 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 successful 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>
+
+ <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 remember
+ 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>
+
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: licensing-->
+
+ <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>
+
+ <para>
+ Any discussion of licenses is also sure to generate at least a
+ small flame war 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 allegiances in this argument are out in the open.
+ </para>
+
+ <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
+ Guidelines</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 understanding.
+ </para>
+
+ <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>
+
+ <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>
+
+ <para>
+ The three major license can be found at the following locations:
+ </para>
+
+ <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>
+
+ <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>
+
+ <sect3 id="licensechoose">
+ <title>The mechanics of licensing</title>
+
+ <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>
+
+ <para>
+ <orderedlist>
+ <listitem>
+
+ <para>If at all possible, attach and distribute a full copy of
+ the license with the source and binary in a separate
+ file.</para>
+
+ </listitem>
+ <listitem>
+
+ <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>
+
+ <screen>
+<emphasis>one line to give the program's name and an idea of what it does.</emphasis>
+Copyright (C) yyyy name of author
+
+This program is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public License
+as published by the Free Software Foundation; either version 2
+of the License, or (at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ </screen>
+
+ <para>
+ The <acronym>GPL</acronym> goes on to recommend attaching
+ information on contacting you (the author) via email or
+ physical mail.
+ </para>
+
+ </listitem>
+ <listitem>
+
+ <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>
+
+ <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>
+
+ </orderedlist>
+ </para>
+ </sect3>
+
+ <sect3 id="licensewarning">
+ <title>Final license warning</title>
+
+ <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 distribution, 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 re-release it under a free
+ license. Please save yourself and others trouble by releasing the
+ first version of your software with a clear license.
+ </para>
+
+ </sect3>
+
+ </sect2>
+
+<!-- Section2: chooseversioning-->
+
+ <sect2 id="chooseversioning">
+ <title>Choosing a Method of Version Numbering</title>
+ <para>
+ <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>
+ <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>
+ 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>
+ <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>
+
+ <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 that 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 frustrated 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>
+ </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 January 04, 2000 would be
+ <quote>wine-20000104</quote>. For certain projects, Year Month
+ Day format can make a lot of sense.
+ </para>
+
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Mozilla milestones:</term>
+ <listitem>
+ <para>When one considers Netscape 6 and vendor 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>
+ Mozilla's development structure has historically been made up
+ of milestones. From the 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 road-maps
+ 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 road-map had been reached, that
+ particular build was marked as a milestone release.
+ </para>
+
+ <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>
+
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </sect2>
+
+<!-- Section2: documentation-->
+
+ <sect2 id="documentation">
+ <title>Documentation</title>
+
+ <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 usable.</emphasis>
+ </para>
+
+ <para>
+ 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>
+ 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>
+
+ <sect3>
+ <title>Man pages</title>
+
+ <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>
+
+ <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>
+
+ <para>
+ It is also possible to write man pages using DocBook SGML and
+ convert them into man pages. Because man pages 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>
+
+ <sect3>
+ <title>Command line accessible documentation</title>
+
+ <para>
+ Most users will expect the most basic amount of documentation to
+ be easily available 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
+ sentence) 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>
+
+ <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>
+ It has become a GNU convention to make this information
+ accessible 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 directory 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,
+ compilation, 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 quickly 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 the 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 significant 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 usability, and decrease
+ headaches on all sides.
+ </para>
+ </listitem>
+
+ </varlistentry>
+ </variablelist>
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Website</title>
+ <para>
+ 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>
+
+ <sect3>
+ <title>Other documentation hints</title>
+
+ <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>
+
+ <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>
+
+<!-- Section2: presentation -->
+
+ <sect2 id="presentation">
+ <title>Other Presentation Issues</title>
+ <para>
+ 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>
+
+ <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 spot-lit as a more effective compression medium. I now make
+ all my releases available in both gzip'ed and bzip2'ed formats.
+ </para>
+
+ <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 specified libraries and
+ distributed in tar.gz format as well. <emphasis>Remember: While
+ these binaries packages are nice, getting the source packaged and
+ released should always be your priority. Other can and will do
+ the the binary packages for you.</emphasis>
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Useful tidbits and presentation hints</title>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ <emphasis>Make sure that your program can always be found in a
+ single location.</emphasis> Often this means that you have a
+ single directory accessible 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>
+ </listitem>
+
+ <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>
+
+ </itemizedlist>
+ </para>
+
+ </sect3>
+ </sect2>
+ </sect1>
+
+<!-- Section1: starting: END -->
+
+<!-- Section1: developers -->
+
+ <sect1 id="developers">
+ <title>Maintaining a Project: Interacting with Developers</title>
+ <indexterm>
+ <primary>fswd!developers</primary>
+ </indexterm>
+
+ <para>
+ 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
+ rough interactions with developers and with users.
+ </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>
+ 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 simply 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: delegation -->
+
+ <sect2 id="delegation">
+ <title>Delegating Work</title>
+
+ <para>
+ 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>
+ <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>
+ Delegation is the political 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 responsible
+ 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>
+ As your project progresses, you will notice people who are putting
+ significant 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
+ responsibility to contact these people and to try and shift some of
+ the power and responsibility of your position as the project's
+ maintainer onto them (if they want it). There are several easy
+ ways you can do this:
+ </para>
+
+ <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
+ judgment and for recognizing solutions that are maintainable and
+ are not. In a sentence: <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 inspiration:
+ </para>
+
+ <sect4>
+ <title>Allow a larger group of people write access to your CVS
+ repository and make real efforts towards rule by a
+ committee</title>
+
+ <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>
+ 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 leader as well
+ but the leader's main responsibility is to, <quote>Appoint
+ Delegates or delegate decisions to the Technical
+ Committee.</quote>
+ </para>
+
+ <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
+ caricature of how a project can involve and empower a huge
+ number of developers and grow to a huge size.
+ </para>
+
+ </sect4>
+
+ <sect4 id="releasemanager">
+ <title>Publicly appoint someone as the release manager for a
+ specific release.</title>
+
+ <para>
+ A release manager is usually responsible for coordinating
+ testing, enforcing a code freeze, being responsible for
+ stability and quality control, packaging up the software, and
+ placing it in the appropriate places to be downloaded.
+ </para>
+
+ <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 someone 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>
+
+ <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-suited developer.
+ </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: patching -->
+
+ <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>
+
+ <sect3>
+ <title>Technical judgment</title>
+
+ <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 functionality that was originally unforeseen 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 unwieldiness. These are the criteria that you as a
+ project maintainer should take into account each time you receive
+ a patch.
+ </para>
+
+ <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>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>Will it benefit a significant percentage of the program's
+ user community?</para>
+ </listitem>
+
+ <listitem>
+ <para>Does it fit within the program's domain or within a
+ natural, intuitive extension of that domain?</para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ <para>
+ The answers to these questions are never straightforward 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 responsibility
+ to reject the change. If you fail to do this, the project will
+ become unwieldy and unmaintainable and will ultimately fail.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Rejecting patches</title>
+
+ <para>
+ Rejecting patches is probably the most difficult and the most
+ sensitive 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
+ power trip or being overly bossy or possessive of a community-based
+ project. I recommend that you keep three major facts in mind when
+ rejecting patches (or other changes):
+ </para>
+
+ <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 definitely 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>
+
+ <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>
+
+ <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 technical 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 developer submitting the patch 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>
+
+ <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>
+
+ <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 incorporate 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>
+
+<!-- Section2: branches -->
+
+ <sect2 id="branches">
+ <title>Stable and Development Branches</title>
+
+ <para>
+ The idea of stable and development branches has already been
+ described briefly in <xref linkend="chooseversioning"> and in
+ <xref linkend="delegatebranch">. These alludes 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>
+ 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 repercussions are
+ incorporated into the stable branch also to the development
+ branch.
+ </para>
+
+ <para>
+ Linux's model is an extreme one. On many projects, there is no
+ need to have two versions always available. It may make sense to
+ 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
+ consistent and effective development with the need to make regular
+ and usable releases.
+ </para>
+
+ <para>
+ In trying to set up a development tree for yourself, there are
+ several things that might be useful to keep in mind:
+ </para>
+
+ <para>
+ <variablelist>
+
+ <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>
+
+ <varlistentry>
+ <term>Make sure that all your different branches are explained</term>
+ <listitem>
+ <para>
+ As I mentioned in the preceding paragraph, different branches
+ <emphasis>will</emphasis> confuse your users. Do everything
+ you can to avoid this by clearly explaining the different
+ branches in a prominent page on your website and in a Readme
+ file in the <acronym>FTP</acronym> or <acronym>HTTP</acronym>
+ directory.
+ </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>
+ 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
+ probably can't go wrong with this simple and common division of
+ branches.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <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 physically 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 accessible 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>
+
+ </variablelist>
+ </para>
+
+ </sect2>
+
+<!-- Section2: otherdev -->
+
+ <sect2 id="otherdev">
+ <title>Other Development issues</title>
+ <para>
+ 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>
+
+ <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 significant 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 needed line in the sand. It gives
+ developers room they need to get a program ready for release.
+ </para>
+
+ <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 precedes a release. Most released
+ software is in what could be interpreted as a sort of high
+ level<quote>code freeze.</quote>
+ </para>
+
+ <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>
+
+ <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 code-base
+ but for technical, political, and philosophical reasons,
+ development was split into two projects which now compete with
+ each other.
+ </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>
+
+<!-- Section1: users -->
+
+ <sect1 id="users">
+ <title>Maintaining a Project: Interacting with Users</title>
+ <indexterm>
+ <primary>fswd!users</primary>
+ </indexterm>
+
+ <para>
+ If you've worked your way up to here, congratulations, you are
+ nearing the end of this document. This final section describes some
+ of the situations in which you, in your capacity as project
+ maintainer, will be interacting with users and gives some
+ suggestions on how these situations might be handled effectively.
+ </para>
+
+ <para>
+ Interacting with users is difficult. In our discussion of
+ interaction with developers, the underlying assumption is that in a
+ free software project, a project maintainer must constantly strive to
+ attract and keep developers who can easily leave at any time.
+ </para>
+
+ <para>
+ Users in the free software community are different than users in
+ the world of proprietary software and they should be treated
+ differently. Some ways in which the groups differ significantly
+ follow:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para>The lines between users and developers are blurred in ways
+ that is totally foreign to any proprietary development
+ model. Your users are often your developers and vice
+ versa.</para>
+ </listitem>
+
+ <listitem>
+ <para>In the free software world, you are often your users only
+ choice. Because there is such an emphasis on not replicating the
+ work of others in the free software community and because the
+ element of competition present in the propriety software model is
+ absent (or at least in an extremely different form) in the free
+ software development model your users will probably be the only
+ project that does what you do (or at least the only one that does
+ what you do in the way that you do it). This means your
+ responsiveness to your users is even more important in that in
+ the proprietary world.</para>
+ </listitem>
+
+ <listitem>
+ <para>In an almost paradoxical situation, free software projects
+ have less immediate or dire consequences for ignoring their
+ users--it is often easier to do. Because you don't usually need
+ to compete with another product in the free software model,
+ chances are good that you will not be scrambling to gain the
+ features of the competitor's newest program. This means that your
+ development process will have to be directed either internally,
+ by your users or both.</para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ Trying to tackle this unique situation can only be done
+ indirectly. Developers and maintainers need to listen to users and
+ to try and be as responsive as possible. A solid knowledge of the
+ situation recounted above is any free software developers best tool
+ for shifting his development or leadership style to fit the unique
+ process of free software development. This chapters will try and
+ introduce some of the more difficult or important points in any
+ projects interactions with users and give some hints on how to
+ tackle these.
+ </para>
+
+<!-- Section2: testing -->
+
+ <sect2 id="testing">
+ <title>Testing and Testers</title>
+
+ <para>
+ In addition to your users being your developers, they are also
+ (and perhaps more commonly) your testers. Before I get flamed, I
+ should rephrase my sentence: <emphasis>some</emphasis> users are
+ your testers.
+ </para>
+
+ <para>
+ It is important that this distinction be made early on because not
+ all of your users wants to be testers. Many users want to use
+ stable software and don't care if they don't have the newest
+ greatest software with the latest and greatest features. These
+ users except a stable, tested piece of software with major or
+ obvious bugs worked out or openly declared and will be angry if
+ they find themselves in a testing position. This is yet another
+ way in which a split development model (as mentioned in <xref
+ linkend="branches">) might come in handy.
+ </para>
+
+ <sect3>
+ <title>Automated testing</title>
+ <para>
+ For many programs, many common and mistakes can be caught by
+ automated means. Automated tests tend to be pretty good at
+ catching errors that you've run into several times before or
+ something you just forget and not very good at finding errors,
+ even major ones, that were totally unforeseen.
+ </para>
+
+ <para>
+ CVS comes with a bourne shell script called sanity.sh that is
+ worth looking at. Debian uses a program called lintian that
+ checks Debian packages for all of the most common errors. While
+ using these scripts may not be possible, there is a host of other
+ sanity checking software on the net that may be applicable (feel
+ free to email any recommendations). None of these will create a
+ bug-free release but they will avoid at least some major
+ oversights. Finally, if your programs become a long term
+ endeavor, you will find that there are certain errors that you
+ tend to make over and over. Start a collection of scripts that
+ check for these errors to help prevent them in the future.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Testing by testers</title>
+ <para>
+ For any program that depends on user interactivity, many bugs
+ will only be uncovered through testing by users actually clicking
+ the keys and pressing the mouse buttons. For this you need
+ testers and as many testers as possible.
+ </para>
+
+ <para>
+ The most difficult part of testing is finding testers. It's
+ usually a good tactic to post a message to a relevant mailing
+ list or news group announcing a specific proposed release date
+ and outline the functionality of the program. If you put some
+ time into the announcement, you are sure to get a few bites.
+ </para>
+
+ <para>
+ The second most difficult part of testing is keeping your testers
+ and keeping them actively involved in the testing
+ process. Fortunately, there are some tried and true tactics that
+ can applied towards this end:
+ </para>
+
+ <para>
+ <itemizedlist>
+
+ <listitem>
+ <para><emphasis>Make things simple for your testers.</emphasis>
+ Your testers are doing you a favor so make it as easy as
+ possible. This means that you should be careful to package your
+ software in a way that is easy to find, unpack, install, and
+ uninstall. This also means you should explain what you are
+ looking for to each tester and make the means for reporting
+ bugs simple and well established. The key is to provide as much
+ structure as possible to make your tester's job easy and
+ maintain as much flexibility as possible for those that want to
+ do things a little differently.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Be responsive to your testers.</emphasis> When
+ your testers submit bugs, respond to them and respond
+ quickly. Even if you are only responding to tell them that the
+ bug has already been fixed, quick and consistent response make
+ them feel like their work is heard, important, and
+ appreciated.</para>
+ </listitem>
+
+ <listitem>
+ <para><emphasis>Thank your testers.</emphasis> Thank them
+ personally each time they send you patch. Thank them publicly
+ in the documentation and the about section of your program. You
+ appreciate your testers and your program would not be possible
+ without their help. Make sure they know and pat them on the
+ back by making sure the rest of the world knows it too. It will
+ be appreciated more than you expected.</para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </sect3>
+ </sect2>
+
+<!-- Section2: support -->
+
+ <sect2 id="support">
+ <title>Setting up a Support Infrastructure</title>
+
+ <para>
+ While testing is important, the large part of your interactions
+ and responsibility to your users falls under the category of
+ support. The best way to make sure your users are adequately
+ supported in using your program is to set up a good infrastructure
+ for this purpose so that your developers and users help each other
+ and less of the burden falls on you while people get quicker and
+ better responses to their questions. This infrastructure comes in
+ several forms:
+ </para>
+
+ <sect3>
+ <title>Documentation</title>
+ <para>
+ It should not come as any surprise that the key element to any
+ support infrastructure is good documentation. This topic was
+ large covered in <xref linkend="documentation"> and will not be
+ repeated here.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>Mailing lists</title>
+ <para>
+ Aside from documentation, effective mailing lists will be your
+ greatest tool in supporting user support. Running a mailing list
+ well is more complicated than installing mailing list software
+ onto a machine.
+ </para>
+
+ <sect4>
+ <title>Separate lists</title>
+
+ <para>
+ A good idea is too separate your user and development mailing
+ lists (perhaps into project-user@host and project-devel@host)
+ and enforce the division. If people post a development question
+ onto -user, politely ask them to repost it onto -devel and vise
+ versa. Subscribe yourself to both groups and encourage primarily
+ developers to do the same.
+ </para>
+
+ <para>
+ This system provides so that no one person is stuck doing all of
+ the support work and works so that users learn more about the
+ program, they can help new users with their questions.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Choose mailing list software well</title>
+ <para>
+ Please don't make the selection of mailing list software
+ lightly. Please consider easy accessibility by users without a
+ lot of technical experience so you want to be as easy as
+ possible. Web accessibility to an archive of the list is also
+ important.
+ </para>
+
+ <para>
+ The two biggest free software mailing list programs are <ulink
+ url="http://www.greatcircle.com/majordomo/">majordomo</ulink>
+ and <ulink url="http://www.list.org/">GNU Mailman</ulink>. A
+ long time advocate of majordomo, I would now recommend any
+ project choose GNU Mailman. It fulfills the criteria listed above
+ and makes it easier to do. It provides a good mailing list
+ program for a free software project maintainer as opposed to a
+ good mailing list application for a mailing list administrator.
+ </para>
+
+ <para>
+ There are other things you want to take in setting up your
+ list. If it is possible to gate your mailing lists to USENET and
+ provide them in digest form as well as making them accessible on
+ the web, you will please some users and work to make the support
+ infrastructure slightly more accessible.
+ </para>
+ </sect4>
+ </sect3>
+
+ <sect3>
+ <title>Other support ideas</title>
+
+ <para>
+ A mailing list and accessible documentation all you can do to set
+ up good user support infrastructure. Be creative. If you stumble
+ across something works well, email me and I'll include it here in
+ the HOWTO.
+ </para>
+ <sect4>
+ <title>Make your self accessible</title>
+ <para>
+ You can not put to few methods to access you. If you hang out in
+ an <acronym>IRC</acronym> channel, don't hesitate to list in
+ your projects documentation. List email and snail mail
+ addresses, or ways to reach you via <acronym>ICQ</acronym>,
+ <acronym>AIM</acronym>, or Jabber.
+ </para>
+ </sect4>
+
+ <sect4>
+ <title>Bug management software</title>
+ <para>
+ For many large software projects, use of bug management software
+ is essential to keep track of which bugs have been fixed, which
+ bugs have not been fixed, and which bugs are being fixed by
+ which people. Debian uses the <ulink
+ url="http://bugs.debian.org">Debian Bug Tracking System</ulink>
+ (<acronym>BTS</acronym>) although it may not be best choice for
+ every project (it seems to currently be buckling under its own
+ weight. As well as a damn good web browser, the mozilla project
+ has spawned a sub-project resulting in a bug tracking system
+ called <ulink
+ url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>.
+ </para>
+
+ <para>
+ These systems (and others like them) can be unwieldy so
+ developers should be careful to not spend more time on the bug
+ tracking system than on the bugs or the projects themselves. If
+ a project continues to grow, use of a bug tracking system can
+ provide an easy standard way for users and testers to report
+ bugs and for developers and maintainers to fix them in an
+ orderly fashion.
+ </para>
+ </sect4>
+ </sect3>
+ </sect2>
+
+<!-- Section2: releasing -->
+
+ <sect2 id="releasing">
+ <title>Releasing Your Program</title>
+
+ <para>
+ As mentioned earlier in the HOWTO, the first rule or releasing is,
+ <emphasis>release something useful.</emphasis> Non-working or
+ not-useful software will not attract anyone to your
+ project. People will be turned off of your project and be likely
+ to simply gloss over it next time they see a new version
+ announced. Half-working software, if useful, will intrigue people,
+ whet their appetites for the version to come, and encourage them
+ to join the development process.
+ </para>
+
+ <sect3>
+ <title>When to release</title>
+
+ <para>
+ Making the decision to release your software for the first time
+ is an incredibly important and incredibly stressful decision. But
+ it needs to be done. My advice is to try and make something that
+ is complete enough to be usable and incomplete enough to allow
+ for flexibility and imagination by your future developers. It's
+ not an easy decision. Ask for help on a local Linux User Group
+ mailing list or from a group of developer friends.
+ </para>
+
+ <para>
+ One tactic is to first do an <quote>alpha</quote> or
+ <quote>beta</quote> release as described below in <xref
+ linkend="alphabeta">. However, most of the guidelines described
+ above still apply.
+ </para>
+
+ <para>
+ <emphasis>When you feel in your gut it is time and you feel
+ you've weighed the situation well several times, cross your
+ fingers and take the plunge.</emphasis>
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>How to release</title>
+
+ <para>
+ If you've followed the guidelines described in this HOWTO up
+ until this point, the mechanics of doing a release are going to
+ be the easy part of releasing. If you have set up a consistent
+ distribution locations and the other infrastructure described in
+ the preceding sections, releasing should be as simple as
+ building the package, checking it once over, and uploading it
+ into the appropriate place and then reflecting the release on
+ your website.
+ </para>
+ </sect3>
+
+ <sect3 id="alphabeta">
+ <title>Alpha, beta, and development releases</title>
+
+ <para>
+ When contemplating releases, it worth considering the fact that
+ not every release needs to be a full numbered release. Software
+ users are accustomed to pre-releases but you must be careful to
+ label these releases accurately or they cause more problems then
+ they are worth.
+ </para>
+
+ <para>
+ <variablelist>
+
+ <varlistentry>
+ <term>alpha releases</term>
+ <listitem>
+ <para>
+ Alpha releases are expected to be unstable, perhaps a little
+ unsafe, but definitely usable. Alpha versions should have
+ full functionality and limited testing. They can have known
+ bugs and kinks that have yet to be worked out. Before sure to
+ keep in mind that <emphasis>alpha releases are still
+ releases</emphasis> and people are not going to be expecting
+ a nightly build from the CVS source. An alpha should work and
+ have minimal testing and bug fixing already finished.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>beta releases</term>
+ <listitem>
+ <para>
+ Beta releases are general expected to be usable and
+ slightly unstable, although definitely
+ <emphasis>not</emphasis> unsafe. Beta releases usually
+ preclude a full release by under a month. They can contain
+ small known bugs but no major ones. All major functionality
+ should be fully implemented although the exact mechanics can
+ still be worked out. Beta releases are great tool to whet the
+ appetites of potential users by giving them a very
+ realistic view of where your project is going in the very
+ near future and can help keep interest by giving people
+ <emphasis>something.</emphasis>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>development releases</term>
+ <listitem>
+ <para>
+ Development release is much more vague term than
+ <quote>alpha</quote> or <quote>beta</quote>. I usually choose
+ to reserve the term for discussion of a development
+ branch. There are other ways to use the term. So many in
+ fact, that I feel the term has been cheapened. The popular
+ window manager <ulink
+ url="http://www.enlightenment.org">Enlightenment</ulink> has
+ released <emphasis>nothing but</emphasis> development
+ releases. Most often, the term is used to describe releases
+ that are not even to alpha or beta stages though and if I
+ were to release a pre-alpha release in order to keep interest
+ in my project live, this is probably how I would have to label
+ it.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ </para>
+ </sect3>
+ </sect2>
+
+<!-- Section2: announcing -->
+
+ <sect2 id="announcing">
+ <title>Announcing Your Project</title>
+
+ <para>
+ Well, you've done it. You've (at least for the purposes of this
+ HOWTO) designed, built, and released your free software
+ project. All that is left is for you to tell the world so they
+ know to come and try it out and hopefully jump on board with
+ development. If everything is in order as described above, this
+ will be a quick and painless process. A quick announcement is all
+ that it takes to put yourself on the free software communities
+ radar screen.
+ </para>
+
+ <sect3>
+ <title>Mailing lists and USENET</title>
+ <para>
+ Email is still the way that most people on the Internet get their
+ information. Its a good idea to send a message announcing your
+ program to any relevant mailing list you know of and any relevant
+ USENET discussion group. Karl Fogel recommends that use you
+ simple subject describing the fact that the message is an
+ announcement, the name of the program, the version, and a
+ half-line long description of its functionality. This way, any
+ interested user or developer will be immediately attracted to
+ your announcement. Fogel's example looks like:
+ </para>
+
+ <screen>Subject: ANN: aub 1.0, a program to assemble USENET binaries</screen>
+
+ <para>
+ The rest of the email should describe the programs functionality
+ quickly and concisely in no more than two paragraphs and should
+ provide links to the projects webpage and direct links to
+ downloads for those that want it right away.
+ </para>
+
+ <para>
+ You should repeat this announcement process consistently in the
+ same locations for each subsequent release.
+ </para>
+ </sect3>
+
+ <sect3>
+ <title>freshmeat.net</title>
+ <para>
+ Mentioned earlier in <xref linkend="evalwhere">, in today's free
+ software community, announcements of your project on freshmeat
+ are almost more important than announcements on mailing list
+ announcements.
+ </para>
+
+ <para>
+ Visit the <ulink url="http://freshmeat.net">freshmeat
+ website</ulink> or their <ulink
+ url="http://freshmeat.net/add-project/">submit project
+ page</ulink> to post your project on their site and in their
+ database. In addition to a large website, freshmeat provides a
+ daily newsletter that highlights all the days releases and
+ reaches a huge audience (I skim it every night for any
+ interesting new releases).
+ </para>
+
+ <para>
+ Once you've finished this...
+ </para>
+
+ <para>
+ Congratulations. You've now the maintainer of an active free
+ software project. Good luck and feel free to stay in touch with
+ me about your experiences. I'd love to incorporate them into this
+ HOWTO.
+ </para>
+ </sect3>
+ </sect2>
+</sect1>
+
+</article>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:t
+sgml-shorttag:t
+sgml-namecase-general:t
+sgml-general-insert-case:lower
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:nil
+sgml-parent-document:nil
+sgml-exposed-tags:nil
+sgml-local-catalogs:nil
+sgml-local-ecat-files:nil
+End:
+-->
\ No newline at end of file
projects / fspm_howto / blobdiff