I fixed a weird rending problem that was causing one character

Author: mako
Date: 2001/03/27 22:15:51
I fixed a weird rending problem that was causing one character
indentation on all variable lists. <shrug>

I've also reread first section (intro) of the documention on the
initial reread.

diff --git a/FreeSoftwareDevelopmentHOWTO.sgml b/FreeSoftwareDevelopmentHOWTO.sgml
index 66fd9c60e98fbecc0b3d9463e2bc8fe69169dda6..713938b94825226c8a9a152ff435ee735b36eb4b 100644 (file)
--- a/FreeSoftwareDevelopmentHOWTO.sgml
+++ b/FreeSoftwareDevelopmentHOWTO.sgml
@@ -332,6 +332,7 @@
     I'd love for this HOWTO to gain the kind of international reach
     afforded by a translated version.
    </para>
     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 currently
    <para>
     However, this HOWTO is still young and I have to yet to be
     contacted about a translation so English is all that is currently


@@ -1016,14 +1017,12 @@ pages for more information and options.
        <term>README or Readme</term>
 
        <listitem>
        <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>
+       <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>
        </listitem>
 
       </varlistentry>


@@ -1031,18 +1030,16 @@ pages for more information and options.
        <term>INSTALL or Install</term>
 
        <listitem>
        <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>
+       <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>
        </listitem>
 
       </varlistentry>


@@ -1050,19 +1047,17 @@ pages for more information and options.
        <term>Changelog, ChangeLog, CHANGELOG, or changelog</term>
 
        <listitem>
        <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>
+       <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>
        </listitem>
 
       </varlistentry>


@@ -1070,17 +1065,15 @@ pages for more information and options.
        <term><acronym>FAQ</acronym></term>
 
        <listitem>
        <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>
+       <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>
        </listitem>
 
       </varlistentry>


@@ -1089,7 +1082,7 @@ pages for more information and options.
    </sect3>
 
    <sect3>
    </sect3>
 
    <sect3>

-    <title>Website</title>
+    <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
     <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


@@ -1615,30 +1608,26 @@ pages for more information and options.
      <varlistentry>
       <term>Minimize the number of branches</term>
       <listitem>
      <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>
+       <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>
       </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>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
 
        <para>
         I might also recommend against a mistake that I think Debian


@@ -1665,27 +1654,25 @@ pages for more information and options.
      <varlistentry>
       <term>Make sure all your branches are always available</term>
       <listitem>
      <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>
+       <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>
 
       </listitem>
      </varlistentry>
 


@@ -2181,56 +2168,50 @@ pages for more information and options.
       <varlistentry>
        <term>alpha releases</term>
        <listitem>
       <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>
+       <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>
        </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>
+       <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>
        </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>
+       <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>
 
        </listitem>
       </varlistentry>
 

diff --git a/FreeSoftwareProjectManagementHOWTO.sgml b/FreeSoftwareProjectManagementHOWTO.sgml
index 66fd9c60e98fbecc0b3d9463e2bc8fe69169dda6..713938b94825226c8a9a152ff435ee735b36eb4b 100644 (file)
--- a/FreeSoftwareProjectManagementHOWTO.sgml
+++ b/FreeSoftwareProjectManagementHOWTO.sgml
@@ -332,6 +332,7 @@
     I'd love for this HOWTO to gain the kind of international reach
     afforded by a translated version.
    </para>
     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 currently
    <para>
     However, this HOWTO is still young and I have to yet to be
     contacted about a translation so English is all that is currently


@@ -1016,14 +1017,12 @@ pages for more information and options.
        <term>README or Readme</term>
 
        <listitem>
        <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>
+       <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>
        </listitem>
 
       </varlistentry>


@@ -1031,18 +1030,16 @@ pages for more information and options.
        <term>INSTALL or Install</term>
 
        <listitem>
        <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>
+       <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>
        </listitem>
 
       </varlistentry>


@@ -1050,19 +1047,17 @@ pages for more information and options.
        <term>Changelog, ChangeLog, CHANGELOG, or changelog</term>
 
        <listitem>
        <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>
+       <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>
        </listitem>
 
       </varlistentry>


@@ -1070,17 +1065,15 @@ pages for more information and options.
        <term><acronym>FAQ</acronym></term>
 
        <listitem>
        <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>
+       <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>
        </listitem>
 
       </varlistentry>


@@ -1089,7 +1082,7 @@ pages for more information and options.
    </sect3>
 
    <sect3>
    </sect3>
 
    <sect3>

-    <title>Website</title>
+    <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
     <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


@@ -1615,30 +1608,26 @@ pages for more information and options.
      <varlistentry>
       <term>Minimize the number of branches</term>
       <listitem>
      <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>
+       <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>
       </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>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
 
        <para>
         I might also recommend against a mistake that I think Debian


@@ -1665,27 +1654,25 @@ pages for more information and options.
      <varlistentry>
       <term>Make sure all your branches are always available</term>
       <listitem>
      <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>
+       <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>
 
       </listitem>
      </varlistentry>
 


@@ -2181,56 +2168,50 @@ pages for more information and options.
       <varlistentry>
        <term>alpha releases</term>
        <listitem>
       <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>
+       <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>
        </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>
+       <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>
        </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>
+       <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>
 
        </listitem>
       </varlistentry>