From owner-freebsd-doc Fri Feb 15 7:50:16 2002 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D77AC37B419 for ; Fri, 15 Feb 2002 07:50:00 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g1FFo0o73798; Fri, 15 Feb 2002 07:50:00 -0800 (PST) (envelope-from gnats) Received: from relay3-gui.server.ntli.net (relay3-gui.server.ntli.net [194.168.4.200]) by hub.freebsd.org (Postfix) with ESMTP id 7321037B402 for ; Fri, 15 Feb 2002 07:48:09 -0800 (PST) Received: from pc4-card4-0-cust162.cdf.cable.ntl.com ([80.4.14.162] helo=rhadamanth.private.submonkey.net ident=mailnull) by relay3-gui.server.ntli.net with esmtp (Exim 3.03 #2) id 16bkaf-0004O1-00 for FreeBSD-gnats-submit@freebsd.org; Fri, 15 Feb 2002 15:48:01 +0000 Received: from setantae by rhadamanth.private.submonkey.net with local (Exim 3.34 #1) id 16bkaf-000Ex8-00 for FreeBSD-gnats-submit@freebsd.org; Fri, 15 Feb 2002 15:48:01 +0000 Message-Id: Date: Fri, 15 Feb 2002 15:48:01 +0000 From: Ceri Reply-To: Ceri To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.113 Subject: docs/34967: Developer's Handbook, cont : Policies chapter Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 34967 >Category: docs >Synopsis: Developer's Handbook, cont : Policies chapter >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 15 07:50:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: Ceri >Release: FreeBSD 4.5-STABLE i386 >Organization: >Environment: System: FreeBSD rhadamanth.private.submonkey.net 4.5-STABLE FreeBSD 4.5-STABLE #0: Tue Feb 12 17:56:57 GMT 2002 setantae@rhadamanth.private.submonkey.net:/usr/obj/usr/src/sys/RHADAMANTH i386 >Description: Silly nitpicking fixes Ceri >How-To-Repeat: >Fix: --- doc/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml.old Fri Feb 15 15:27:31 2002 +++ doc/en_US.ISO8859-1/books/developers-handbook/policies/chapter.sgml Fri Feb 15 15:43:58 2002 @@ -30,7 +30,7 @@ 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 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. @@ -100,7 +100,7 @@ not applicable for FreeBSD can be removed. In the case of Tcl, the mac, win and compat subdirectories were eliminated before the - import + import. src/lib/libtcl contains only a "bmake style" Makefile that uses the standard @@ -118,7 +118,7 @@ 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 + 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 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 FreeBSD checked out version and "committed", as this + be patched into the FreeBSD checked out version and committed, as this destroys the vendor branch coherency and makes importing future versions rather difficult as there will be conflicts. @@ -152,11 +152,11 @@ In the src/contrib/tcl level directory, a file called FREEBSD-upgrade should be added and it - should states things like: + should state things like: - Which files have been left out + Which files have been left out. @@ -165,7 +165,7 @@ - Where to send patches back to the original authors + Where to send patches back to the original authors. @@ -270,7 +270,7 @@ - Kernel files; + Kernel files: @@ -294,7 +294,7 @@ - User-land files; + User-land files: @@ -343,17 +343,17 @@ 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. + call syntax, etc. will force the major version number to change. Stick to version numbers of the form major.minor (x.y). Our a.out dynamic linker does not handle version numbers of the form x.y.z well. Any version number after the y - (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 micro revision, - ld.so will link with the higher one. Ie: if you link + ld.so will link with the higher one. i.e.: if you link with libfoo.so.3.3.3, the linker only records 3.3 in the headers, and will link with anything starting with @@ -363,7 +363,7 @@ ld.so will always use the highest - minor revision. Ie: it will use + minor revision. i.e.: it will use libc.so.2.2 in preference to libc.so.2.0, even if the program was initially linked with libc.so.2.0. @@ -371,13 +371,13 @@ 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 Makefiles "do the right thing" - based on the type of system. + version number as our Makefiles do the right + thing based on the type of system. 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.: X.0 to (X+1).0. When you make a change to a system library that requires the version number to be bumped, check the Makefile's commit logs. It is the responsibility of the committer to ensure that the first such change >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message