Whitespace cleanup.

svn path=/head/; revision=16286

en_US.ISO8859-1/books/handbook/policies/chapter.sgml

@@ -14,16 +14,16 @@
   </chapterinfo>
 
   <title>Source Tree Guidelines and Policies</title>
-  
+
   <para>This chapter documents various guidelines and policies in force for
     the FreeBSD source tree.</para>
-  
+
   <sect1 id="policies-maintainer">
     <title><makevar>MAINTAINER</makevar> on Makefiles</title>
     <indexterm><primary>ports maintainer</primary></indexterm>
-    
+
     <para>June 1996.</para>
-    
+
     <para>If a particular portion of the FreeBSD distribution is being
       maintained by a person or group of persons, they can communicate this
       fact to the world by adding a
@@ -34,7 +34,7 @@
       source tree.</para>
 
     <para>The semantics of this are as follows:</para>
-    
+
     <para>The maintainer owns and is responsible for that code.  This means
       that he is responsible for fixing bugs and answer problem reports
       pertaining to that piece of the code, and in the case of contributed
@@ -52,7 +52,7 @@
       does not have to be a committer and it can easily be a group of
       people.</para>
   </sect1>
-  
+
   <sect1 id="policies-contributed">
     <sect1info>
       <authorgroup>
@@ -70,13 +70,13 @@
     </sect1info>
 
     <title>Contributed Software</title>
-    
+
     <indexterm><primary>contributed software</primary></indexterm>
-        
+
     <para>Some parts of the FreeBSD distribution consist of software that is
       actively being maintained outside the FreeBSD project.  For historical
       reasons, we call this <emphasis>contributed</emphasis> software.  Some
-      examples are <command>perl</command>, <command>gcc</command> and 
+      examples are <command>perl</command>, <command>gcc</command> and
       <command>patch</command>.</para>
 
     <para>Over the last couple of years, various methods have been used in
@@ -110,7 +110,7 @@
 	revision 1.1.x.x.  The repository bloat impact from a single character
 	change can be rather dramatic.</para>
     </note>
-    
+
     <para>The <application>Tcl</application> embedded programming
       language will be used as example of how this model works:</para>
 
@@ -126,7 +126,7 @@
       <filename>bsd.lib.mk</filename> makefile rules to produce the library
       and install the documentation.</para>
 
-    <para><filename>src/usr.bin/tclsh</filename> contains only a 
+    <para><filename>src/usr.bin/tclsh</filename> contains only a
       <command>bmake</command> style
       <filename>Makefile</filename> which will produce and install the
       <command>tclsh</command> program and its associated man-pages using the
@@ -147,7 +147,7 @@
       ahead and hope it <quote>works out</quote>.  CVS is not forgiving of
       import accidents and a fair amount of effort is required to back out
       major mistakes.</para>
-    
+
     <para>Because of the previously mentioned design limitations with CVS's
       vendor branches, it is required that <quote>official</quote> patches from
       the vendor be applied to the original distributed sources and the result
@@ -162,7 +162,7 @@
       interest to FreeBSD in order to save space.  Files containing copyright
       notices and release-note kind of information applicable to the remaining
       files shall <emphasis>not</emphasis> be removed.</para>
-    
+
     <para>If it seems easier, the <command>bmake</command>
       <filename>Makefile</filename>s can be produced from the dist tree
       automatically by some utility, something which would hopefully make it
@@ -174,27 +174,27 @@
     <para>In the <filename>src/contrib/tcl</filename> level directory, a file
       called <filename>FREEBSD-upgrade</filename> should be added and it
       should states things like:</para>
-    
+
     <itemizedlist>
       <listitem>
 	<para>Which files have been left out</para>
       </listitem>
-      
+
       <listitem>
 	<para>Where the original distribution was obtained from and/or the
 	  official master site.</para>
       </listitem>
-      
+
       <listitem>
 	<para>Where to send patches back to the original authors</para>
       </listitem>
-      
+
       <listitem>
 	<para>Perhaps an overview of the FreeBSD-specific changes that have
 	  been made.</para>
       </listitem>
     </itemizedlist>
-    
+
     <para>However, please do not import <filename>FREEBSD-upgrade</filename>
       with the contributed source. Rather you should <command>cvs add
 	FREEBSD-upgrade ; cvs ci</command> after the initial import.  Example
@@ -208,26 +208,26 @@ official-patch versions must be imported.  Please remember to import with
 
 For the import of GNU cpio 2.4.2, the following files were removed:
 
-        INSTALL         cpio.info       mkdir.c             
+	INSTALL         cpio.info       mkdir.c
-        Makefile.in     cpio.texi       mkinstalldirs
+	Makefile.in     cpio.texi       mkinstalldirs
 
 To upgrade to a newer version of cpio, when it is available:
-        1. Unpack the new version into an empty directory.
+	1. Unpack the new version into an empty directory.
-           [Do not make ANY changes to the files.]
+	   [Do not make ANY changes to the files.]
 
-        2. Remove the files listed above and any others that don't apply to
+	2. Remove the files listed above and any others that don't apply to
-           FreeBSD.
+	   FreeBSD.
 
-        3. Use the command:
+	3. Use the command:
-                cvs import -ko -m 'Virgin import of GNU cpio v&lt;version&gt;' \
+		cvs import -ko -m 'Virgin import of GNU cpio v&lt;version&gt;' \
-                        src/contrib/cpio GNU cpio_&lt;version&gt;
+			src/contrib/cpio GNU cpio_&lt;version&gt;
 
-           For example, to do the import of version 2.4.2, I typed:
+	   For example, to do the import of version 2.4.2, I typed:
-                cvs import -ko -m 'Virgin import of GNU v2.4.2' \
+		cvs import -ko -m 'Virgin import of GNU v2.4.2' \
-                        src/contrib/cpio GNU cpio_2_4_2
+			src/contrib/cpio GNU cpio_2_4_2
 
-        4. Follow the instructions printed out in step 3 to resolve any
+	4. Follow the instructions printed out in step 3 to resolve any
-           conflicts between local FreeBSD changes and the newer version.
+	   conflicts between local FreeBSD changes and the newer version.
 
 Do not, under any circumstances, deviate from this procedure.
 
@@ -246,94 +246,94 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
     <para>It might occasionally be necessary to include an encumbered file in
       the FreeBSD source tree.  For example, if a device requires a small
       piece of binary code to be loaded to it before the device will operate,
-      and we do not have the source to that code, then the binary file is said 
+      and we do not have the source to that code, then the binary file is said
       to be encumbered.  The following policies apply to including encumbered
       files in the FreeBSD source tree.</para>
 
     <orderedlist>
       <listitem>
-        <para>Any file which is interpreted or executed by the system CPU(s)
+	<para>Any file which is interpreted or executed by the system CPU(s)
 	  and not in source format is encumbered.</para>
       </listitem>
 
       <listitem>
-        <para>Any file with a license more restrictive than BSD or GNU is
+	<para>Any file with a license more restrictive than BSD or GNU is
 	  encumbered.</para>
       </listitem>
 
       <listitem>
-        <para>A file which contains downloadable binary data for use by the
+	<para>A file which contains downloadable binary data for use by the
 	  hardware is not encumbered, unless (1) or (2) apply to it.  It must
 	  be stored in an architecture neutral ASCII format (file2c or
 	  uuencoding is recommended).</para>
       </listitem>
 
       <listitem>
-        <para>Any encumbered file requires specific approval from the <link
+	<para>Any encumbered file requires specific approval from the <link
 	    linkend="staff-core">Core team</link> before it is added to the
 	  CVS repository.</para>
       </listitem>
 
       <listitem>
-        <para>Encumbered files go in <filename>src/contrib</filename> or
+	<para>Encumbered files go in <filename>src/contrib</filename> or
 	  <filename>src/sys/contrib</filename>.</para>
       </listitem>
 
       <listitem>
-        <para>The entire module should be kept together.  There is no point in 
+	<para>The entire module should be kept together.  There is no point in
 	  splitting it, unless there is code-sharing with non-encumbered
 	  code.</para>
       </listitem>
 
       <listitem>
-        <para>Object files are named
+	<para>Object files are named
 	  <filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename>.</para>
       </listitem>
 
       <listitem>
-        <para>Kernel files:</para>
+	<para>Kernel files:</para>
 
-        <orderedlist>
+	<orderedlist>
-          <listitem>
+	  <listitem>
-            <para>Should always be referenced in
+	    <para>Should always be referenced in
-              <filename>conf/files.*</filename> (for build simplicity).</para>
+	      <filename>conf/files.*</filename> (for build simplicity).</para>
 	  </listitem>
 
-          <listitem>
+	  <listitem>
-            <para>Should always be in <filename>LINT</filename>, but the <link 
+	    <para>Should always be in <filename>LINT</filename>, but the <link
-              linkend="staff-core">Core team</link> decides per case if it
+	      linkend="staff-core">Core team</link> decides per case if it
 	      should be commented out or not.  The <link
 	      linkend="staff-core">Core team</link> can, of course, change
 	      their minds later on.</para>
-          </listitem>
+	  </listitem>
 
-          <listitem>
+	  <listitem>
-            <para>The <link linkend="staff-who">Release Engineer</link>
+	    <para>The <link linkend="staff-who">Release Engineer</link>
-              decides whether or not it goes into the release.</para>
+	      decides whether or not it goes into the release.</para>
-          </listitem>
+	  </listitem>
-        </orderedlist>
+	</orderedlist>
       </listitem>
 
       <listitem>
-        <para>User-land files:</para>
+	<para>User-land files:</para>
 
-        <orderedlist>
+	<orderedlist>
-          <listitem>
+	  <listitem>
-            <indexterm><primary>core team</primary></indexterm>
+	    <indexterm><primary>core team</primary></indexterm>
-            <para>The <link linkend="staff-core">Core team</link> decides if
+	    <para>The <link linkend="staff-core">Core team</link> decides if
-              the code should be part of <command>make world</command>.</para>
+	      the code should be part of <command>make world</command>.</para>
-          </listitem>
+	  </listitem>
-         
+
-          <listitem>
+	  <listitem>
-            <indexterm><primary>release engineer</primary></indexterm>
+	    <indexterm><primary>release engineer</primary></indexterm>
-            <para>The <link linkend="staff-who">Release Engineer</link>
+	    <para>The <link linkend="staff-who">Release Engineer</link>
-              decides if it goes into the release.</para>
+	      decides if it goes into the release.</para>
-          </listitem>
+	  </listitem>
-        </orderedlist>
+	</orderedlist>
       </listitem>
     </orderedlist>
   </sect1>
-  
+
   <sect1 id="policies-shlib">
     <sect1info>
       <authorgroup>
@@ -362,26 +362,26 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
       the release version of the software.</para>
 
     <para>The three principles of shared library building are:</para>
-    
+
     <itemizedlist>
       <listitem>
 	<para>Start from <literal>1.0</literal></para>
       </listitem>
-      
+
       <listitem>
 	<para>If there is a change that is backwards compatible, bump minor
 	  number (note that ELF systems ignore the minor number)</para>
       </listitem>
-      
+
       <listitem>
 	<para>If there is an incompatible change, bump major number</para>
       </listitem>
     </itemizedlist>
-    
+
     <para>For instance, added functions and bugfixes result in the minor
       version number being bumped, while deleted functions, changed function
       call syntax etc.  will force the major version number to change.</para>
-    
+
     <para>Stick to version numbers of the form major.minor
       (<replaceable>x</replaceable>.<replaceable>y</replaceable>).  Our a.out
       dynamic linker does not handle version numbers of the form
@@ -397,7 +397,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
       <replaceable>libfoo.so.3</replaceable>.<replaceable>(anything &gt;=
 	3)</replaceable>.<replaceable>(highest
 	available)</replaceable>.</para>
-    
+
     <note>
       <para><command>ld.so</command> will always use the highest
 	<quote>minor</quote> revision.  Ie: it will use
@@ -410,7 +410,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
     numbers at all.  However, one should still specify a major and minor
     version number as our <filename>Makefile</filename>s "do the right thing"
     based on the type of system.</para>
-    
+
     <para>For non-port libraries, it is also our policy to change the shared
       library version number only once between releases.  In addition, it is
       our policy to change the major shared library version number only once
@@ -424,7 +424,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
   </sect1>
 </chapter>
 
-<!-- 
+<!--
      Local Variables:
      mode: sgml
      sgml-declaration: "../chapter.decl"
@@ -434,4 +434,3 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
      sgml-parent-document: ("../book.sgml" "part" "chapter")
      End:
 -->
-