|author||Doc Manager <doceng@FreeBSD.org>||1996-07-02 23:16:18 +0000|
|committer||Doc Manager <doceng@FreeBSD.org>||1996-07-02 23:16:18 +0000|
Create branch 'RELENG_2_1_0'.
Notes: svn path=/branches/RELENG_2_1_0/; revision=396
2 files changed, 165 insertions, 0 deletions
diff --git a/handbook/isdn.sgml b/handbook/isdn.sgml
new file mode 100644
@@ -0,0 +1,18 @@
+<!-- $Id: isdn.sgml,v 1.1 1996-07-02 23:16:16 wosch Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+<p><em>Contributed by &a.hm;.</em>
+There is the bisdn ISDN package available from ftp.muc.ditec.de supporting
+FreeBSD 2.1R, FreeBSD-current and NetBSD.
+Currently all (passive) Teles cards and their clones are supported for the
+EuroISDN (DSS1) and 1TR6 protocols.
+The latest source can be found on the above mentioned ftp server under
+directory isdn as file bisdn-095.tar.gz.
+A majordomo maintained mailing list is available, to subscribe, send the
+usual majordomo requests to firstname.lastname@example.org.
diff --git a/handbook/policies.sgml b/handbook/policies.sgml
new file mode 100644
@@ -0,0 +1,147 @@
+<!-- $Id: policies.sgml,v 1.1 1996-06-30 18:01:25 phk Exp $ -->
+<!-- The FreeBSD Documentation Project -->
+<chapt><heading>Source Tree Guidelines and Policies
+<p><em>Contributed by &a.phk;.</em>
+This chapter documents various guidelines and policies in force
+for the FreeBSD sourcetree.
+<sect><heading>MAINTAINER on Makefiles</heading>
+<p>If a particular subpart of the FreeBSD is being maintained by a
+person or group of persons, they can communicate this fact to the
+world by adding a
+ MAINTAINER= email-addresses
+<p>line to the makefiles covering this piece of subpart of the tree.
+<p>The semantics of this is as follows:
+<p>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.
+<p>Commits to the directories covered by this shall be sent to the
+maintainer for review. 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.
+<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
+have to be a committer and it can easily to be a group of people.
+<p> 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
+questions that sound like a final exam in system-level Unix
+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?'').
+<p> Fortunately, with the Ports collection, all the hard work involved
+has already been done, and you can just type 'make install' and get a
+<p>Some parts of the FreeBSD distribution consists of software that
+is actively being maintained outside the FreeBSD project. For
+historical reasons, we call this "contributed" software. Some
+examples are perl, gcc and patch.
+<p>Over the last couple of years, various methods have been used in
+dealing with this type of software and all have some number of
+advantages and drawbacks. No clear winner has emerged.
+<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
+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,
+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
+to the primary developers of the contributed software.
+<p>Ultimately, however, it comes down to the people actually doing
+the work. If using this model is particularly unsuited to the
+package being dealt with, exceptions to these rules may be granted
+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.
+<p>The "Tcl" embeddable programming language will be used as example
+of how this model works:
+<p><verb>src/contrib/tcl</verb> contains the source as distributed by the maintainers
+of this package. Parts that are entirely not applicable for FreeBSD
+can be removed. In the case of Tcl, the "mac", "win" and "compat"
+subdirectories were eliminated before the import
+<p><verb>src/lib/libtcl</verb> contains only a "bmake style" Makefile that uses
+the standard bsd.lib.mk makefile rules to produce the library and
+install the documentation.
+<p><verb>src/usr.bin/tclsh</verb> contains only a bmake style Makefile which will
+produce and install the "tclsh" program and its associated man-pages
+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
+when the tcl software needs updated, these are not part of the
+build or installed software.
+<p>The important thing here is that the "src/contrib/tcl" directory
+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
+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
+out major mistakes.
+<p>Because of some unfortunate design limitations with CVS's vendor
+branches, it is required that "official" 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 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.
+<p>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
+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.
+<p>If it seems easier, the "bmake" makefiles can be produced from the
+dist tree automatically by some utility, something which would
+hopefully make it even easier to upgrade to a new version. If this
+is done, be sure to check in such utilities (as necessary) in the
+src/tools directory along with the port itself so that it's available
+to future maintainers.
+<p>In the src/contrib/tcl level directory, a file called README.FreeBSD
+should be added and it should states things like:
+ <item> Which files have been left out
+ <item> Where the original distribution was obtained from and/or the official
+ master site.
+ <item> Where to send patches back to the original authors
+ <item> Perhaps an overview of the FreeBSD-specific changes that have been made.