os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Chapter cleanup:

Browse source 
- Various grammar fixes.
- Change "ie." to "i.e."
- Convert quotes to <quote> or other more appropriate tags.

PR:		docs/34967
Submitted by:	Ceri <setantae@submonkey.net>
This commit is contained in:
Giorgos Keramidas 2002-02-18 01:57:39 +00:00
parent 45f7d6cff8
commit 5fb578f819
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=12238
1 changed files with 15 additions and 15 deletions

30
en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml
View file

@ -30,7 +30,7 @@
<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
that he is responsible for fixing bugs and answering problem reports
pertaining to that piece of the code, and in the case of contributed
software, for tracking new versions, as appropriate.</para>
@ -100,7 +100,7 @@
not applicable for FreeBSD can be removed. In the case of Tcl, the
<filename>mac</filename>, <filename>win</filename> and
<filename>compat</filename> subdirectories were eliminated before the
import</para>
import.</para>
<para><filename>src/lib/libtcl</filename> contains only a "bmake style"
<filename>Makefile</filename> that uses the standard
@ -118,7 +118,7 @@
<para>The important thing here is that the
<filename>src/contrib/tcl</filename> directory is created according to
the rules: It is supposed to contain the sources as distributed (on a
the rules: it is supposed to contain the sources as distributed (on a
proper CVS vendor-branch and without RCS keyword expansion) with as few
FreeBSD-specific changes as possible. The 'easy-import' tool on
freefall will assist in doing the import, but if there are any doubts on
@ -131,7 +131,7 @@
vendor branches, it is required that <quote>official</quote> patches from
the vendor be applied to the original distributed sources and the result
re-imported onto the vendor branch again. Official patches should never
be patched into the FreeBSD checked out version and "committed", as this
be patched into the FreeBSD checked out version and <quote>committed</quote>, as this
destroys the vendor branch coherency and makes importing future versions
rather difficult as there will be conflicts.</para>
@ -152,11 +152,11 @@
<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>
should state things like:</para>
<itemizedlist>
<listitem>
<para>Which files have been left out</para>
<para>Which files have been left out.</para>
</listitem>
<listitem>
@ -165,7 +165,7 @@
</listitem>
<listitem>
<para>Where to send patches back to the original authors</para>
<para>Where to send patches back to the original authors.</para>
</listitem>
<listitem>
@ -270,7 +270,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
</listitem>
<listitem>
<para>Kernel files;</para>
<para>Kernel files:</para>
<orderedlist>
<listitem>
@ -294,7 +294,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
</listitem>
<listitem>
<para>User-land files;</para>
<para>User-land files:</para>
<orderedlist>
<listitem>
@ -343,17 +343,17 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
<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>
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
<replaceable>x</replaceable>.<replaceable>y</replaceable>.<replaceable>z</replaceable>
well. Any version number after the <replaceable>y</replaceable>
(ie. the third digit) is totally ignored when comparing shared lib
(i.e. the third digit) is totally ignored when comparing shared lib
version numbers to decide which library to link with. Given two shared
libraries that differ only in the <quote>micro</quote> revision,
<command>ld.so</command> will link with the higher one. Ie: if you link
<command>ld.so</command> will link with the higher one. That is, if you link
with <filename>libfoo.so.3.3.3</filename>, the linker only records
<literal>3.3</literal> in the headers, and will link with anything
starting with
@ -363,7 +363,7 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
<note>
<para><command>ld.so</command> will always use the highest
<quote>minor</quote> revision. Ie: it will use
<quote>minor</quote> revision. For instance, it will use
<filename>libc.so.2.2</filename> in preference to
<filename>libc.so.2.0</filename>, even if the program was initially
linked with <filename>libc.so.2.0</filename>.</para>
@ -371,13 +371,13 @@ obrien@FreeBSD.org - 30 March 1997</programlisting>
<para>In addition, our ELF dynamic linker does not handle minor version
numbers at all. However, one should still specify a major and minor
version number as our <filename>Makefile</filename>s "do the right thing"
version number as our <filename>Makefile</filename>s <quote>do the right thing</quote>
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
between major OS releases. Ie: X.0 to (X+1).0. When you make a
between major OS releases (i.e. from 3.0 to 4.0). When you make a
change to a system library that requires the version number to be
bumped, check the <filename>Makefile</filename>'s commit logs. It is the
responsibility of the committer to ensure that the first such change