d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Some grammer/typo fixes. I also added some additional sgml

Browse Source 
formatting as phk suggested I might want to do.
This commit is contained in:
Mike Pritchard 1996-07-03 04:23:26 +00:00
parent 41e4eb70b4
commit 2388ee9a46
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=16940
1 changed files with 28 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
share/doc/handbook/policies.sgml
View File

@ -1,4 +1,4 @@
<!-- $Id$ --> <!-- $Id: policies.sgml,v 1.1 1996/06/30 18:01:25 phk Exp $ -->
<!-- The FreeBSD Documentation Project --> <!-- The FreeBSD Documentation Project -->
<chapt><heading>Source Tree Guidelines and Policies <chapt><heading>Source Tree Guidelines and Policies
@ -14,7 +14,7 @@ for the FreeBSD sourcetree.
<p>June 1996. <p>June 1996.
<p>If a particular subpart of the FreeBSD is being maintained by a <p>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 person or group of persons, they can communicate this fact to the
world by adding a world by adding a
@ -22,23 +22,26 @@ world by adding a
MAINTAINER= email-addresses MAINTAINER= email-addresses
</verb> </verb>
<p>line to the makefiles covering this piece of subpart of the tree. <p>line to the makefiles covering this portion of the source tree.
<p>The semantics of this is as follows: <p>The semantics of this are as follows:
<p>The maintainer owns and is responsible for that code. This means <p>The maintainer owns and is responsible for that code. This means
that he is responsible for fixing bugs and answer PRs pertaining that he is responsible for fixing bugs and answer problem reports
to that piece of the code, and in the case of contrib software, pertaining to that piece of the code, and in the case of contributed
for tracking new versions, as appropriate. software, for tracking new versions, as appropriate.
<p>Commits to the directories covered by this shall be sent to the <p>Changes to directories which have a maintainer defined shall be
maintainer for review. Only if the maintainer does not respond sent to the
maintainer for review before being committed. Only if the maintainer does not respond
for un unacceptable period of time, to several emails, will it be for un unacceptable period of time, to several emails, will it be
acceptable to commit changes without review by the maintainer. acceptable to commit changes without review by the maintainer.
However, it is suggested that you try and have the changes reviewed
by someone else if at all possible.
<p>It is of course not acceptable to add a person or group as maintainer <p>It is of course not acceptable to add a person or group as maintainer
unless they agree to assume this duty, on the other hand it doesn't unless they agree to assume this duty. On the other hand it doesn't
have to be a committer and it can easily to be a group of people. have to be a committer and it can easily be a group of people.
<p>Some software distributions have attacked this problem by <p>Some software distributions have attacked this problem by
providing configuration scripts. Some of these are very clever, but providing configuration scripts. Some of these are very clever, but
@ -53,13 +56,13 @@ Foonix style unacceptable exception handling? And if not, why not?'').
has already been done, and you can just type 'make install' and get a has already been done, and you can just type 'make install' and get a
working program. working program.
<sect><heading>contributed software</heading> <sect><heading>Contributed software</heading>
<p>June 1996. <p>June 1996.
<p>Some parts of the FreeBSD distribution consists of software that <p>Some parts of the FreeBSD distribution consist of software that
is actively being maintained outside the FreeBSD project. For is actively being maintained outside the FreeBSD project. For
historical reasons, we call this "contributed" software. Some historical reasons, we call this <em>contributed</em> software. Some
examples are perl, gcc and patch. examples are perl, gcc and patch.
<p>Over the last couple of years, various methods have been used in <p>Over the last couple of years, various methods have been used in
@ -69,8 +72,8 @@ advantages and drawbacks. No clear winner has emerged.
<p>Since this is the case, after some debate one of these methods has <p>Since this is the case, after some debate one of these methods has
been selected as the "official" method and will be required for been selected as the "official" method and will be required for
future imports of software of this kind. Furthermore, it is strongly future imports of software of this kind. Furthermore, it is strongly
suggested that existing contrib software converge on this model suggested that existing contributed software converge on this model
over time as it has significant advantages over the old method, over time, as it has significant advantages over the old method,
including the ability to easily obtain diffs relative to the including the ability to easily obtain diffs relative to the
"official" versions of the source by everyone (even without cvs "official" versions of the source by everyone (even without cvs
access). This will make it significantly easier to return changes access). This will make it significantly easier to return changes
@ -83,7 +86,7 @@ only with the approval of the core team and with the general
consensus of the other developers. The ability to maintain the consensus of the other developers. The ability to maintain the
package in the future will be a key issue in the decisions. package in the future will be a key issue in the decisions.
<p>The "Tcl" embeddable programming language will be used as example <p>The <tt>Tcl</tt> embedded programming language will be used as example
of how this model works: of how this model works:
<p><verb>src/contrib/tcl</verb> contains the source as distributed by the maintainers <p><verb>src/contrib/tcl</verb> contains the source as distributed by the maintainers
@ -99,7 +102,7 @@ install the documentation.
produce and install the "tclsh" program and its associated man-pages produce and install the "tclsh" program and its associated man-pages
using the standard bsd.prog.mk rules. using the standard bsd.prog.mk rules.
<p><verb>src/tools/tools/tcl_bmake</verb> contains a couple of shell-scrips that can be of help <p><verb>src/tools/tools/tcl_bmake</verb> contains a couple of shell-scripts that can be of help
when the tcl software needs updated, these are not part of the when the tcl software needs updated, these are not part of the
build or installed software. build or installed software.
@ -107,7 +110,7 @@ build or installed software.
is created according to the rules: It is supposed to contain the is created according to the rules: It is supposed to contain the
sources as distributed (on a proper CVS vendor-branch) with as few sources as distributed (on a proper CVS vendor-branch) with as few
FreeBSD-specific changes as possible. The 'easy-import' tool on FreeBSD-specific changes as possible. The 'easy-import' tool on
freefall will assist in doing the import but, if there are any freefall will assist in doing the import, but if there are any
doubts on how to go about it, it is imperative that you ask first doubts on how to go about it, it is imperative that you ask first
and not blunder ahead and hope it "works out". CVS is not forgiving and not blunder ahead and hope it "works out". CVS is not forgiving
of import accidents and a fair amount of effort is required to back of import accidents and a fair amount of effort is required to back
@ -119,14 +122,14 @@ be applied to the original distributed sources and the result
re-imported onto the vendor branch again. Official patches should re-imported onto the vendor branch again. Official patches should
never be patched into the the FreeBSD checked out version and never be patched into the the FreeBSD checked out version and
"committed", as this destroys the vendor branch coherency and makes "committed", as this destroys the vendor branch coherency and makes
imports future versions rather difficult as there will be conflicts. importing future versions rather difficult as there will be conflicts.
<p>Since many packages contain files that are meant for compatibility <p>Since many packages contain files that are meant for compatibility
with other architectures and environments that FreeBSD, it is with other architectures and environments that FreeBSD, it is
permissible to remove parts of the dist tree that are of no interest permissible to remove parts of the distribution tree that are of no interest
to FreeBSD in order to save space. Files containing copyright to FreeBSD in order to save space. Files containing copyright
notices and release-note kind of information applicable to the notices and release-note kind of information applicable to the
remaining files shall >not< be removed. remaining files shall <em>not</em> be removed.
<p>If it seems easier, the "bmake" makefiles can be produced from the <p>If it seems easier, the "bmake" makefiles can be produced from the
dist tree automatically by some utility, something which would dist tree automatically by some utility, something which would