From f7c49acb48d99a0ac835328c6839bcd0ec429584 Mon Sep 17 00:00:00 2001 From: Doc Manager Date: Tue, 2 Jul 1996 23:16:18 +0000 Subject: Create branch 'RELENG_2_1_0'. --- handbook/isdn.sgml | 18 ++++++ handbook/policies.sgml | 147 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 165 insertions(+) create mode 100644 handbook/isdn.sgml create mode 100644 handbook/policies.sgml diff --git a/handbook/isdn.sgml b/handbook/isdn.sgml new file mode 100644 index 0000000000..aa58835342 --- /dev/null +++ b/handbook/isdn.sgml @@ -0,0 +1,18 @@ + + + +ISDN + +

Contributed by &a.hm;. + +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 isdn-request@muc.ditec.de. diff --git a/handbook/policies.sgml b/handbook/policies.sgml new file mode 100644 index 0000000000..f77ae49a96 --- /dev/null +++ b/handbook/policies.sgml @@ -0,0 +1,147 @@ + + + +Source Tree Guidelines and Policies + + +

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

June 1996. + +

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 + + +

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

The semantics of this is 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. + +

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. + +

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. + +

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?''). + +

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 + +

June 1996. + +

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. + +

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. + +

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. + +

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. + +

The "Tcl" embeddable programming language will be used as example +of how this model works: + +

src/contrib/tcl 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 + +

src/lib/libtcl contains only a "bmake style" Makefile that uses +the standard bsd.lib.mk makefile rules to produce the library and +install the documentation. + +

src/usr.bin/tclsh 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. + +

src/tools/tools/tcl_bmake 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. + +

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. + +

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. + +

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. + +

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. + +

In the src/contrib/tcl level directory, a file called README.FreeBSD +should be added and it should states things like: + + + Which files have been left out + Where the original distribution was obtained from and/or the official + master site. + Where to send patches back to the original authors + Perhaps an overview of the FreeBSD-specific changes that have been made. + -- cgit v1.2.3