diff --git a/share/doc/handbook/policies.sgml b/share/doc/handbook/policies.sgml index 45878ce98581..86a505cf0dd4 100644 --- a/share/doc/handbook/policies.sgml +++ b/share/doc/handbook/policies.sgml @@ -1,4 +1,4 @@ - + Source Tree Guidelines and Policies @@ -8,13 +8,13 @@

Contributed by &a.phk;. This chapter documents various guidelines and policies in force -for the FreeBSD sourcetree. +for the FreeBSD source tree. MAINTAINER on Makefiles

June 1996. -

If a particular subpart of the FreeBSD is being maintained by a +

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 @@ -22,25 +22,28 @@ world by adding a MAINTAINER= email-addresses -

line to the makefiles covering this piece of subpart of the tree. +

line to the makefiles covering this portion of the source tree. -

The semantics of this is as follows: +

The semantics of this are as follows:

The maintainer owns and is responsible for that code. This means -that he is responsible for fixing bugs and answer PRs pertaining -to that piece of the code, and in the case of contrib software, -for tracking new versions, as appropriate. +that he is responsible for fixing bugs and answer problem reports +pertaining to that piece of the code, and in the case of contributed +software, for tracking new versions, as appropriate. -

Commits to the directories covered by this shall be sent to the -maintainer for review. Only if the maintainer does not respond +

Changes to directories which have a maintainer defined shall be +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 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.

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 -have to be a committer and it can easily to be a group of people. +unless they agree to assume this duty. On the other hand it doesn't +have to be a committer and it can easily be a group of people. -

Some software distributions have attacked this problem by +

Some software distributions have attacked this problem by providing configuration scripts. Some of these are very clever, but they have an unfortunate tendency to triumphantly announce that your system is something you've never heard of and then ask you lots of @@ -49,17 +52,17 @@ programming (``Does your system's gethitlist function return a const pointer to a fromboz or a pointer to a const fromboz? Do you have Foonix style unacceptable exception handling? And if not, why not?''). -

Fortunately, with the Ports collection, all the hard work involved +

Fortunately, with the Ports collection, all the hard work involved has already been done, and you can just type 'make install' and get a working program. -contributed software +Contributed software

June 1996. -

Some parts of the FreeBSD distribution consists of software that +

Some parts of the FreeBSD distribution consist of software that is actively being maintained outside the FreeBSD project. For -historical reasons, we call this "contributed" software. Some +historical reasons, we call this contributed software. Some examples are perl, gcc and patch.

Over the last couple of years, various methods have been used in @@ -69,8 +72,8 @@ advantages and drawbacks. No clear winner has emerged.

Since this is the case, after some debate one of these methods has been selected as the "official" method and will be required for future imports of software of this kind. Furthermore, it is strongly -suggested that existing contrib software converge on this model -over time as it has significant advantages over the old method, +suggested that existing contributed software converge on this model +over time, as it has significant advantages over the old method, including the ability to easily obtain diffs relative to the "official" versions of the source by everyone (even without cvs 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 package in the future will be a key issue in the decisions. -

The "Tcl" embeddable programming language will be used as example +

The Tcl embedded programming language will be used as example of how this model works:

src/contrib/tcl 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 using the standard bsd.prog.mk rules. -

src/tools/tools/tcl_bmake contains a couple of shell-scrips that can be of help +

src/tools/tools/tcl_bmake contains a couple of shell-scripts that can be of help when the tcl software needs updated, these are not part of the build or installed software. @@ -107,7 +110,7 @@ build or installed software. is created according to the rules: It is supposed to contain the sources as distributed (on a proper CVS vendor-branch) 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 +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 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 @@ -119,14 +122,14 @@ 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 the FreeBSD checked out version and "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.

Since many packages contain files that are meant for compatibility 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 notices and release-note kind of information applicable to the -remaining files shall >not< be removed. +remaining files shall not be removed.

If it seems easier, the "bmake" makefiles can be produced from the dist tree automatically by some utility, something which would