From owner-p4-projects Thu Mar 6 14: 3:26 2003 Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 436AB37B405; Thu, 6 Mar 2003 14:02:56 -0800 (PST) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF19837B401 for ; Thu, 6 Mar 2003 14:02:55 -0800 (PST) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12B7043FA3 for ; Thu, 6 Mar 2003 14:02:54 -0800 (PST) (envelope-from chris@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.12.6/8.12.6) with ESMTP id h26M2r0U062299 for ; Thu, 6 Mar 2003 14:02:53 -0800 (PST) (envelope-from chris@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.12.6/8.12.6/Submit) id h26M2rGb062296 for perforce@freebsd.org; Thu, 6 Mar 2003 14:02:53 -0800 (PST) Date: Thu, 6 Mar 2003 14:02:53 -0800 (PST) Message-Id: <200303062202.h26M2rGb062296@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to chris@freebsd.org using -f From: Chris Costello Subject: PERFORCE change 26448 for review To: Perforce Change Reviews Sender: owner-p4-projects@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG http://perforce.freebsd.org/chv.cgi?CH=26448 Change 26448 by chris@chris_holly on 2003/03/06 14:02:06 Integrate. Affected files ... .. //depot/projects/trustedbsd/doc/Makefile#4 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/5-roadmap/article.sgml#2 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/committers-guide/article.sgml#13 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/contributors/article.sgml#16 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml#3 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/dialup-firewall/article.sgml#4 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/euro/article.sgml#5 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/filtering-bridges/article.sgml#5 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/freebsd-questions/article.sgml#2 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/hats/article.sgml#5 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/pam/article.sgml#6 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/releng/article.sgml#10 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/smp/article.sgml#2 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/design-44bsd/book.sgml#2 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/developers-handbook/boot/chapter.sgml#4 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/developers-handbook/isa/chapter.sgml#4 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/developers-handbook/tools/chapter.sgml#6 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/faq/book.sgml#12 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/fdp-primer/writing-style/chapter.sgml#6 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml#12 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/desktop/chapter.sgml#8 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/disks/chapter.sgml#13 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/install/chapter.sgml#13 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/introduction/chapter.sgml#7 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.sgml#10 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/l10n/chapter.sgml#6 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/mail/chapter.sgml#10 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.sgml#15 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/pgpkeys/chapter.sgml#11 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/pgpkeys/das.key#1 branch .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/pgpkeys/pgpkeys.ent#11 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/handbook/ppp-and-slip/chapter.sgml#10 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/books/porters-handbook/book.sgml#16 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/share/sgml/authors.ent#11 integrate .. //depot/projects/trustedbsd/doc/en_US.ISO8859-1/share/sgml/mailing-lists.ent#5 integrate .. //depot/projects/trustedbsd/doc/fr_FR.ISO8859-1/books/handbook/install/chapter.sgml#7 integrate .. //depot/projects/trustedbsd/doc/fr_FR.ISO8859-1/books/handbook/introduction/chapter.sgml#6 integrate .. //depot/projects/trustedbsd/doc/fr_FR.ISO8859-1/books/handbook/l10n/chapter.sgml#6 integrate .. //depot/projects/trustedbsd/doc/fr_FR.ISO8859-1/books/handbook/pgpkeys/chapter.sgml#7 integrate .. //depot/projects/trustedbsd/doc/share/sgml/bibliography.sgml#2 integrate .. //depot/projects/trustedbsd/doc/share/sgml/man-refs.ent#15 integrate Differences ... ==== //depot/projects/trustedbsd/doc/Makefile#4 (text+ko) ==== @@ -1,4 +1,4 @@ -# $FreeBSD: doc/Makefile,v 1.28 2002/10/01 03:15:12 lioux Exp $ +# $FreeBSD: doc/Makefile,v 1.29 2003/03/06 15:06:17 ru Exp $ # # The user can override the default list of languages to build and install # with the DOC_LANG variable. @@ -29,7 +29,7 @@ .endif CVS?= /usr/bin/cvs -CVSFLAGS?= -q +CVSFLAGS?= -R -q update: .if defined(SUP_UPDATE) ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/5-roadmap/article.sgml#2 (text+ko) ==== @@ -14,6 +14,13 @@ %mailing-lists; +RELENG_3"> +RELENG_4"> +RELENG_5"> +RELENG_5_1"> +RELENG_5_2"> +HEAD"> + ]>
@@ -24,7 +31,7 @@ The &os; Release Engineering Team - $FreeBSD: doc/en_US.ISO8859-1/articles/5-roadmap/article.sgml,v 1.1 2003/02/17 18:55:14 scottl Exp $ + $FreeBSD: doc/en_US.ISO8859-1/articles/5-roadmap/article.sgml,v 1.8 2003/02/17 22:43:35 bmah Exp $ 2003 @@ -50,24 +57,24 @@ This is somewhat similar to the situation that &os; faced in the 3.X series. Work on 3-CURRENT trudged along - seemingly forever, and finally a cry was made to 'just ship it' and + seemingly forever, and finally a cry was made to just ship it and clean up later. This decision resulted in the 3.0 and 3.1 releases being very unsatisfying for most, and it wasn't until 3.2 that the - series was considered 'stable'. To make matters worse, the RELENG_3 - branch was created along with the 3.0 release, and the HEAD branch was + series was considered stable. To make matters worse, the &t.releng.3; + branch was created along with the 3.0 release, and the &t.releng.head; branch was allowed to advance immediately towards 4-CURRENT. This resulted in a - quick divergence between HEAD and RELENG_3, making maintenance of the - RELENG_3 branch very difficult. &os; 2.2.8 was left for quite a while + quick divergence between &t.releng.head; and &t.releng.3;, making maintenance of the + &t.releng.3; branch very difficult. &os; 2.2.8 was left for quite a while as the last production-quality version of &os;. Our intent is to avoid repeating that scenario with &os; 5.x. - Delaying the RELENG_5 branch until it is stable and production quality + Delaying the &t.releng.5; branch until it is stable and production quality will ensure that it stays maintainable and provides a compelling reason to upgrade from 4.X, To do this, we must identify the current areas of weakness and set clear goals for resolving them. This document contains what we as the release engineering team feel are the milestones and issues that must be - resolved for the RELENG_5 branch. It does not dictate every aspect of + resolved for the &t.releng.5; branch. It does not dictate every aspect of &os; development, and we welcome further input. Nothing that follows is meant to be a sleight against any person or group, or to trivialize any work that has been done. There are some significant issues, @@ -112,7 +119,7 @@ Work has not started on any of the other protocols such as AppleTalk, XNS, or IPX. Locking of the socket layer is in progress but has been largely untested. None of the hardware drivers or - ethernet layers have been locked. + Ethernet layers have been locked. @@ -161,7 +168,7 @@ - kernel encryption: crypto drivers and core crypto framework are + kernel encryption: crypto drivers and core &man.crypto.4; framework are Giant-free. KAME IPsec and FAST IPSec have not been locked. @@ -186,7 +193,7 @@ will also help this, as will converting drivers to be as efficient as possible in their interrupt routines. - Next, the state of KSE must resolved for RELENG_5. Work on it has + Next, the state of KSE must resolved for &t.releng.5;. Work on it has slowed noticeably in the past 6 months but appears to be picking up again. There are a number of issues that must be addressed: @@ -206,11 +213,11 @@ According to the release schedule below, KSE kernel and userland components must be functionality complete by June 2003 in order to be - included in the RELENG_5 branch. For security and stability reasons, + included in the &t.releng.5; branch. For security and stability reasons, if KSE cannot be finished in time then, by default, all KSE-specific syscalls should be modified to return ENOSYS and all other KSE-specific - interfaces disabled. Deprecating KSE from RELENG_5 but keeping it in - the HEAD branch will pose problems in porting bugfixes and features + interfaces disabled. Deprecating KSE from &t.releng.5; but keeping it in + the &t.releng.head; branch will pose problems in porting bugfixes and features between the two branches, so every effort should be made to finish it on time. @@ -218,7 +225,7 @@ Goals for 5-STABLE - The goals for the RELENG_5 branch point are: + The goals for the &t.releng.5; branch point are: @@ -241,13 +248,13 @@ Both UP and SMP configurations should be evaluated. SMP has the potential to perform much better than 4.X, though for the purposes of creating - the RELENG_5 branch, comparable performance between the two should + the &t.releng.5; branch, comparable performance between the two should be acceptable. It is unrealistic to expect that the SMPng project will be fully - complete by RELENG_5, or that performance will be significantly better + complete by &t.releng.5;, or that performance will be significantly better than 4.X. However, focusing on a subset of the outstanding tasks will give enough benefit for the branch to be viable and maintainable. To break it down: @@ -255,8 +262,8 @@ ABI/API/Infrastructure stability - Enough infrastructure must - be in place and stable to allow fixes from HEAD to easily and - safely be merged into RELENG_5. Also, we must draw a line as to + be in place and stable to allow fixes from &t.releng.head; to easily and + safely be merged into &t.releng.5;. Also, we must draw a line as to what subsystems are to be locked down when we go into 5-STABLE. @@ -267,7 +274,7 @@ VM: Most codepaths, others than the ones that interact with - VFS, should be Giant-free for RELENG_5. + VFS, should be Giant-free for &t.releng.5;. @@ -275,10 +282,10 @@ the risk of uncovering latent bugs and races. Locking it down but not removing Giant imposes further performance penalties. A decision on which parts of the network stack should be locked and - taken out from under Giant for RELENG_5 should be made no later + taken out from under Giant for &t.releng.5; should be made no later than March 15. Work on the IP, TCP, UDP,raw IP, routing sockets, and Unix domain sockets stands a good chance of being complete in - time for RELENG_5. + time for &t.releng.5;. If the decision is made to not lift Giant from the stack, then the locks in these layers could be optimized out with a @@ -324,7 +331,7 @@ demonstrate a real-world application running correctly on it using the standard POSIX Threads API. Examples would be apache 2.0, Java, and/or mozilla. A functional regression test suite is also a - requirement for RELENG_5 and should test signal delivery, + requirement for &t.releng.5; and should test signal delivery, scheduling, performance, and process security/credentials for both KSE and non-KSE processes. KSE kernel and userland components must also reach the same level of functionality for all Tier-1 platforms @@ -343,10 +350,10 @@ http://www.FreeBSD.org/projects/busdma tracks the progress of this and should be used to determine which drivers - must be converted for RELENG_5 and which can be left behind. + must be converted for &t.releng.5; and which can be left behind. Also, there has been talk by several developers and the original author to give the busdma interface a minor overhaul. If this is - to happen, it needs to happen before RELENG_5. Otherwise, + to happen, it needs to happen before &t.releng.5;. Otherwise, differences between the old and new API will make driver maintenance difficult. @@ -358,8 +365,8 @@ manage and allocate PCI memory resources on its own. Implementing this should take into account cardbus, PCI-HotPlug, and laptop dockstation requirements. This feature will become increasingly - critical through the lifetime of RELENG_5, and therefore is a - requirement for the RELENG_5 branch. + critical through the lifetime of &t.releng.5;, and therefore is a + requirement for the &t.releng.5; branch. @@ -387,8 +394,8 @@ Make all drivers defer most of their processing out of their interrupt thread. Significant performance gains have - been shown recently in the aac(4) driver by making its - interrupt handler be INTR_MPSAFE and moving + been shown recently in the &man.aac.4; driver by making its + interrupt handler be INTR_MPSAFE and moving all processing to a taskqueue. @@ -431,7 +438,7 @@ - webstone: /usr/ports/www/webstone + webstone: www/webstone @@ -440,11 +447,11 @@ - ApacheBench: /usr/ports/www/p5-ApacheBench + ApacheBench: www/p5-ApacheBench - netperf: /usr/ports/benchmarks/netperf + netperf: benchmarks/netperf @@ -485,16 +492,16 @@ problems on some laptops. The classic 16-bit bridge support, OLDCARD, still exists and can be compiled in, but this is highly inconvenient for users of older laptops. If OLDCARD cannot be - completely deprecated for RELENG_5, then provisions must be made + completely deprecated for &t.releng.5;, then provisions must be made to allow users to easily install an OLDCARD-enabled kernel. Documentation should be written to help trasition users from - OLDCARD to NEWCARD and from pccardd to - devd. The power management and - dumpcis functionality of pccardc(1) needs to be + OLDCARD to NEWCARD and from &man.pccardd.8; to + &man.devd.8;. The power management and + dumpcis functionality of &man.pccardc.8; needs to be brought forward to work with NEWCARD, along with the ability to load CIS quirk entries. Most of this functionality can be - integrated into devd and - devctl. + integrated into &man.devd.8; and + &man.devctl.4;. @@ -503,7 +510,7 @@ and the new ULE scheduler. A scheduler that demonstrates processor affinity, HyperThreading and KSE awareness, and no regressions in performance or interactivity characteristics must - be available for RELENG_5. + be available for &t.releng.5;. @@ -512,34 +519,34 @@ console support. This is a major support hole for what is a Tier 1 platform. Whether syscons can be shoe-horned in or wscons be adopted from NetBSD is up for debate. However, - sparc64 must have local console support for RELENG_5. Having + sparc64 must have local console support for &t.releng.5;. Having this will also enable the XFree86 server to run, which is also a - requirement for RELENG_5. + requirement for &t.releng.5;. gcc/toolchain: gcc 3.3 might be available in time for - RELENG_5 and might offer some attractive benefits, but also + &t.releng.5; and might offer some attractive benefits, but also likely to introduce ABI incompatibility with prior gcc versions. - ABI compatibility should be locked down for the RELENG_5 + ABI compatibility should be locked down for the &t.releng.5; branch. There has also been a request to move /usr/include/g++ to /usr/include/g++-v3 to be more compliant with the stock behavior - of gcc. This should also be investigated for RELENG_5. + of gcc. This should also be investigated for &t.releng.5;. gdb: gdb from the base system should work for sparc64. It should also understand KSE thread semantics, assuming that KSE - is included in the RELENG_5 branch. gdb 5.3 is available and + is included in the &t.releng.5; branch. gdb 5.3 is available and there are reports that it should address the sparc64 issue. - disklabel(8) regressions: The biggest casualty of the + &man.disklabel.8; regressions: The biggest casualty of the introduction of GEOM appears to be the disklabel utility. The - -r option gives unpredictable results in most + option gives unpredictable results in most cases now and should be removed or fixed. Work is planned for a new unified interface for modifying labels and slices, however this should not preclude disklabel from being fixed. @@ -566,9 +573,9 @@ - If &os; 5.1 is not the branch point for RELENG_5 then the + If &os; 5.1 is not the branch point for &t.releng.5; then the Early Adopters Guide needs to be updated. This document should - then be removed just before the release closest to the RELENG_5 + then be removed just before the release closest to the &t.releng.5; branch point. @@ -579,7 +586,7 @@ Schedule - If branching RELENG_5 at the 5.1 release is paramount, 5.1 will + If branching &t.releng.5; at the 5.1 release is paramount, 5.1 will probably need to move out by at least 3 months. The schedule would be: @@ -588,10 +595,10 @@ Jun 30, 2003: KSE and SMPng feature freeze - Aug 4, 2003: 5.1-BETA, general code freeze + Aug 4, 2003: 5.1-BETA, general code freeze - Aug 18, 2003: 5.1-RC1, RELENG_5 and RELENG_5_1 branched + Aug 18, 2003: 5.1-RC1, &t.releng.5; and &t.releng.5.1; branched Aug 25, 2003: 5.1-RC2 @@ -614,25 +621,25 @@ - May 5, 2003: 5.1-BETA, general code freeze + May 5, 2003: 5.1-BETA, general code freeze - May 19, 2003: 5.1-RC1, RELENG_5_1 branched + May 19, 2003: 5.1-RC1, &t.releng.5.1; branched - May 27, 2003: 5.1-RC2 + May 27, 2003: 5.1-RC2 - Jun 2, 2003: 5.1-RELEASE + Jun 2, 2003: 5.1-RELEASE - Jun 30, 2003: KSE and SMPng feature freeze + Jun 30, 2003: KSE and SMPng feature freeze - Sept 1, 2003: 5.2-BETA, general code freeze + Sept 1, 2003: 5.2-BETA, general code freeze - Sept 15, 2003: 5.2-RC1, RELENG_5 and RELENG_5_2 branched + Sept 15, 2003: 5.2-RC1, &t.releng.5; and &t.releng.5.2; branched Sept 22, 2003: 5.2-RC2 @@ -644,20 +651,20 @@ - Post RELENG_5 direction + Post &t.releng.5; direction As with all -STABLE development streams, the focus should be bug fixes and incremental improvements. Just like normal, everything - should be vetted through the HEAD branch first and committed to - RELENG_5 with caution. As before, new device drivers, incremental + should be vetted through the &t.releng.head; branch first and committed to + &t.releng.5; with caution. As before, new device drivers, incremental features, etc, will be welcome in the branch once they have been proven - in HEAD. + in &t.releng.head;. Further SMPng lockdowns will be divided into two categories, driver and subsystem. The only subsystem that will be sufficiently locked - down for RELENG_5 will be GEOM, so incrementally locking down device + down for &t.releng.5; will be GEOM, so incrementally locking down device drivers under it is a worthy goal for the branch. Full subsystem - lockdowns will have to be fully tested and proven in HEAD before - consideration will be given to merging them into RELENG_5. + lockdowns will have to be fully tested and proven in &t.releng.head; before + consideration will be given to merging them into &t.releng.5;.
==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/committers-guide/article.sgml#13 (text+ko) ==== @@ -17,7 +17,7 @@
- Committer Guide + Committer's Guide @@ -25,7 +25,7 @@ - $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.154 2003/02/08 23:43:56 will Exp $ + $FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.161 2003/03/01 23:08:14 ceri Exp $ 1999 @@ -76,7 +76,7 @@ Mailing Lists &a.developers;, &a.committers; - (Both of these are private list; archives can be found + (Both of these are private lists; archives can be found in /home/mail/developers-archive and /home/mail/committers-archive on the FreeBSD.org @@ -145,8 +145,8 @@ doc - nik@ - doc/, src/ documentation + doceng@ + doc/, www/, src/ documentation @@ -188,9 +188,9 @@ operation, mail the &a.cvs; (or call one of them) and report the problem to one of them. The only ones able to directly fiddle the repository bits on the repository hosts are the repomeisters. - There are no login shells on - ncvs.FreeBSD.org installed, except - for the repomeisters. + There are no login shells available on + ncvs.FreeBSD.org, except + to the repomeisters. CVS operations are done remotely by setting the CVSROOT environment variable to @@ -400,7 +400,7 @@ &prompt.user; cvs status shazam This displays the status of the - shazam file or of every file in the + file shazam or of every file in the shazam directory. For every file, the status is given as one of: @@ -446,12 +446,12 @@ - Once you have checked something out, update it with the + Once you have checked something out, you can update it with the update command. &prompt.user; cvs update shazam - This updates the shazam file or the + This updates the file shazam or the contents of the shazam directory to the latest version along the branch you checked out. If you checked out a point in time, does nothing @@ -490,7 +490,7 @@ sticky tags, dates or revisions whereas and set new ones. - Theoretically, specifying HEAD as + Theoretically, specifying HEAD as the argument to will give you the same result as , but that is just theory. @@ -875,7 +875,7 @@ (editors/vim5) have color support and when used as a pager with color syntax highlighting switched on will highlight many types of file, including diffs, patches, - and cvs/rcs logs. + and CVS/RCS logs. &prompt.user; echo "syn on" >> ~/.vimrc &prompt.user; cvs diff -Nu shazam | vim - @@ -1036,9 +1036,9 @@ again until the matter is settled. Remember – with CVS we can always change it back. - Don't impugn the intentions of someone you disagree with. + Do not impugn the intentions of someone you disagree with. If they see a different solution to a problem than you, or even - a different problem, it's not because they are stupid, because + a different problem, it is not because they are stupid, because they have questionable parentage, or because they are trying to destroy your hard work, personal image, or FreeBSD, but simply because they have a different outlook on the world. Different @@ -1049,15 +1049,15 @@ seeing their solution, or even their vision of the problem, with an open mind. - Accept correction. We're all fallible. When you've made - a mistake, apologize and get on with life. Don't beat up - yourself, and certainly don't beat up others for your mistake. - Don't waste time on embarassment or recrimination, just fix + Accept correction. We are all fallible. When you have made + a mistake, apologize and get on with life. Do not beat up + yourself, and certainly do not beat up others for your mistake. + Do not waste time on embarrassment or recrimination, just fix the problem and move on. Ask for help. Seek out (and give) peer reviews. One of the ways open source software is supposed to excel is in the - number of eyeballs applied to it; this doesn't apply if nobody + number of eyeballs applied to it; this does not apply if nobody will review code. @@ -1090,10 +1090,6 @@ - http://www.FreeBSD.org/send-pr.html - - - &man.send-pr.1; @@ -1163,7 +1159,7 @@ # # FreeBSD categories # -docs:Documentation Bug:nik: +docs:Documentation Bug:freebsd-doc: @@ -1208,6 +1204,8 @@ probably get to know in your role as a committer. Briefly, and by no means all-inclusively, these are: + + @@ -1218,7 +1216,7 @@ authority over the architectural design and implementation of the move to fine-grained kernel threading and locking. He's also the editor of the SMPng Architecture Document. - If you're working on fine-grained SMP and locking, please + If you are working on fine-grained SMP and locking, please coordinate with John. You can learn more about the SMPng Project on its home page: @@ -1391,7 +1389,7 @@ &a.developers; - developers is all committers. This list was created to be a + All committers are subscribed to -developers. This list was created to be a forum for the committers community issues. Examples are Core voting, announcements, etc. This list is @@ -1504,11 +1502,6 @@ - Never touch the repository directly. Ask a - Repomeister. - - - Any disputed change must be backed out pending resolution of the dispute if requested by a maintainer. Security related changes may @@ -1526,7 +1519,7 @@ merging so that it can be given sufficient testing. The release engineer has the same authority over the &os.stable; branch as outlined for the - maintainer in rule #6. + maintainer in rule #5. @@ -1591,8 +1584,8 @@ In all other aspects of project operation, core is a subset of committers and is bound by the same - rules. Just because someone is in core does not mean - that they have special dispensation to step outside of any of + rules. Just because someone is in core this does not mean + that they have special dispensation to step outside any of the lines painted here; core's special powers only kick in when it acts as a group, not on an individual basis. As individuals, the core team members are all committers @@ -1672,8 +1665,8 @@ The CVS repository is not where changes should be initially submitted for correctness or argued over, that - should happen first in the mailing lists and then - committed only once something resembling consensus has + should happen first in the mailing lists and the commit should + only happen once something resembling consensus has been reached. This does not mean that you have to ask permission before correcting every obvious syntax error or manual page misspelling, simply that you should try to @@ -1715,32 +1708,12 @@ someone who manages an overall category of FreeBSD evolution, such as internationalization or networking. See + url="../contributors/staff-who.html"> http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-who.html for more information on this. - Never touch the repository directly. Ask a - Repomeister. - - This is pretty clear - you are not allowed to make - direct modifications to the CVS repository, period. In - case of difficulty, ask one of the repository meisters by - sending mail to the &a.cvs; and simply - wait for them to fix the problem and get back to you. Do - not attempt to fix the problem yourself! - - If you are thinking about putting down a tag or doing a - new import of code on a vendor branch, you might also find - it useful to ask for advice first. A lot of people get - this wrong the first few times and the consequences are - expensive in terms of files touched and angry CVSup/CTM - folks who are suddenly getting a lot of changes sent over - unnecessarily. - - - Any disputed change must be backed out pending resolution of the dispute if requested by a maintainer. Security related changes may @@ -1775,7 +1748,7 @@ 3 days before merging so that it can be given sufficient testing. The release engineer has the same authority over the &os.stable; branch as outlined in rule - #6. + #5. This is another do not argue about it issue since it is the release engineer who is ultimately @@ -1835,6 +1808,7 @@ to resolve the dispute. All parties involved must then agree to be bound by the decision reached by this 3rd party. + @@ -1869,6 +1843,9 @@ Test your changes before committing them. + This may sound obvious, but if it really were so obvious then we probably would not see so many cases of people clearly not doing this. If your changes are to the @@ -2167,7 +2144,7 @@ First, please read the section about repository - copy. + copies. The easiest way to add a new port is to use the addport script on @@ -2293,7 +2270,7 @@ Upgrade the copied port to the new version (remember to change the PORTNAME so there - aren't duplicate ports with the same name). + are not duplicate ports with the same name). @@ -2552,7 +2529,7 @@ Perks of the Job - Unfortunately, there aren't many perks involved with being a + Unfortunately, there are not many perks involved with being a committer. Recognition as a competent software engineer is probably the only thing that will be of benefit in the long run. However, there are at least some perks: ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/contributors/article.sgml#16 (text+ko) ==== @@ -20,7 +20,7 @@ Contributors to FreeBSD - $FreeBSD: doc/en_US.ISO8859-1/articles/contributors/article.sgml,v 1.342 2003/02/16 03:00:36 markp Exp $ + $FreeBSD: doc/en_US.ISO8859-1/articles/contributors/article.sgml,v 1.355 2003/03/05 16:07:59 obraun Exp $ This article lists individuals and organizations who have @@ -1444,6 +1444,10 @@ + &a.das; + + + &a.schweikh; @@ -2840,6 +2844,11 @@ + Brad Davis + so14k@so14k.com + + + Brad Hendrickse bradh@uunet.co.za @@ -3005,6 +3014,11 @@ + Carl Schmidt + carl@perlpimp.codersluts.net + + + Casper casper@acc.am @@ -5062,6 +5076,11 @@ + Jon Nistor + nistor@snickers.org + + + Jon Wilson jon@phuq.co.uk @@ -5486,6 +5505,11 @@ + Koop Mast + einekoai@chello.nl + + + Kostya Lukin lukin@okbmei.msk.su @@ -5736,6 +5760,11 @@ + Mark Linimon + linimon@lonesome.com + + + Mark Mayo markm@vmunix.com @@ -5806,6 +5835,11 @@ + Martin Preuss + martin@libchipcard.de + + + Martti Kuparinen martti.kuparinen@ericsson.com @@ -5961,6 +5995,11 @@ + Maxim Tuliuk + mt@primats.org.ua + + + Maxime Romano verbophobe@hotmail.com @@ -7330,6 +7369,11 @@ + Rui Lopes + rui@ruilopes.com + + + Ruslan Belkin rus@home2.UA.net @@ -7440,6 +7484,11 @@ + Sascha Holzleiter + sascha@root-login.org + + + Sascha Wildner swildner@channelz.GUN.de @@ -7700,6 +7749,11 @@ + Steffen Mazanek + steffen.mazanek@unibw-muenchen.de + + + Steffen Vogelreuter Steffen@Vogelreuter.De @@ -7851,7 +7905,7 @@ Sune Stjerneby - stjerneby@usa.net + sst@vmunix.dk @@ -8083,6 +8137,11 @@ Tim Bishop tim@bishnet.net + + + Tim Daneliuk + tundra@tundraware.com + Tim Kientzle ==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml#3 (text+ko) ==== @@ -19,10 +19,12 @@ 2001 + 2002 + 2003 Stijn Hoop - $FreeBSD: doc/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml,v 1.7 2002/07/25 17:22:43 fanf Exp $ + $FreeBSD: doc/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml,v 1.9 2003/02/18 11:14:38 blackend Exp $ This article describes the steps I took to setup a CVS repository @@ -135,7 +137,7 @@ &prompt.user; cvs add * Note that you will probably get a few warnings about some directories - not being copied; this is normal, you don't need those. + not being copied; this is normal, you do not need those. @@ -241,7 +243,7 @@ can edit this as you wish. More information about this file is available in the CVS manual. Note that the -t and -f - options don't work correctly with client/server + options do not work correctly with client/server CVS. @@ -257,7 +259,7 @@ functionality, as parsing the log message is done by verifymsg and logcheck. This is because the editinfo - functionality doesn't work properly with remote commits, or ones + functionality does not work properly with remote commits, or ones that use the -m or -F options. You should not have to touch this file. @@ -371,7 +373,7 @@ automatically unwrap binary files (see cvswrappers) on checkout. It is not used in the current FreeBSD setup because the functionality it hooks into - doesn't work well with remote commits. You should not have to + does not work well with remote commits. You should not have to touch this file. @@ -387,7 +389,7 @@ automatically wrap binary files (see cvswrappers) on checkin. It is not used in the current FreeBSD setup because the functionality it - hooks into doesn't work well with remote commits. You should + hooks into does not work well with remote commits. You should not have to touch this file. @@ -442,7 +444,7 @@ $MAIL_BRANCH_HDR - if you want to insert a header into each commit mail describing the branch on which the commit was made, define this to match - your setup. Or leave it empty if you don't want such a >>> TRUNCATED FOR MAIL (1000 lines) <<< To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe p4-projects" in the body of the message