PERFORCE change 26448 for review
Chris Costello
chris at freebsd.org
Thu Mar 6 22:02:53 GMT 2003
http://perforce.freebsd.org/chv.cgi?CH=26448
Change 26448 by chris at 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 @@
<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//EN">
%mailing-lists;
+<!ENTITY t.releng.3 "<literal>RELENG_3</literal>">
+<!ENTITY t.releng.4 "<literal>RELENG_4</literal>">
+<!ENTITY t.releng.5 "<literal>RELENG_5</literal>">
+<!ENTITY t.releng.5.1 "<literal>RELENG_5_1</literal>">
+<!ENTITY t.releng.5.2 "<literal>RELENG_5_2</literal>">
+<!ENTITY t.releng.head "<literal>HEAD</literal>">
+
]>
<article>
@@ -24,7 +31,7 @@
<corpauthor>The &os; Release Engineering Team</corpauthor>
</authorgroup>
- <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/5-roadmap/article.sgml,v 1.1 2003/02/17 18:55:14 scottl Exp $</pubdate>
+ <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/5-roadmap/article.sgml,v 1.8 2003/02/17 22:43:35 bmah Exp $</pubdate>
<copyright>
<year>2003</year>
@@ -50,24 +57,24 @@
<para>This is somewhat similar to the situation that &os; faced in the
3.<replaceable>X</replaceable> 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 <quote>just ship it</quote> 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 <quote>stable</quote>. 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;.</para>
<para>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.<replaceable>X</replaceable>, 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.</para>
+ Ethernet layers have been locked.</para>
</listitem>
<listitem>
@@ -161,7 +168,7 @@
</listitem>
<listitem>
- <para>kernel encryption: crypto drivers and core crypto framework are
+ <para>kernel encryption: crypto drivers and core &man.crypto.4; framework are
Giant-free. KAME IPsec and FAST IPSec have not been locked.</para>
</listitem>
@@ -186,7 +193,7 @@
will also help this, as will converting drivers to be as efficient as
possible in their interrupt routines.</para>
- <para>Next, the state of KSE must resolved for RELENG_5. Work on it has
+ <para>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:</para>
@@ -206,11 +213,11 @@
<para>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.</para>
</sect1>
@@ -218,7 +225,7 @@
<sect1 id="goals">
<title>Goals for 5-STABLE</title>
- <para>The goals for the RELENG_5 branch point are:</para>
+ <para>The goals for the &t.releng.5; branch point are:</para>
<itemizedlist>
<listitem>
@@ -241,13 +248,13 @@
Both UP and SMP configurations should be evaluated. SMP has the
potential to perform much better than
4.<replaceable>X</replaceable>, 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.</para>
</listitem>
</itemizedlist>
<para>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.<replaceable>X</replaceable>. 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:</para>
@@ -255,8 +262,8 @@
<itemizedlist>
<listitem>
<para>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.</para>
@@ -267,7 +274,7 @@
<itemizedlist>
<listitem>
<para>VM: Most codepaths, others than the ones that interact with
- VFS, should be Giant-free for RELENG_5.</para>
+ VFS, should be Giant-free for &t.releng.5;.</para>
</listitem>
<listitem>
@@ -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.</para>
+ time for &t.releng.5;.</para>
<para>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 @@
<ulink url="http://www.FreeBSD.org/projects/busdma">
http://www.FreeBSD.org/projects/busdma</ulink> 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.</para>
</listitem>
@@ -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.</para>
+ critical through the lifetime of &t.releng.5;, and therefore is a
+ requirement for the &t.releng.5; branch.</para>
</listitem>
</itemizedlist>
</listitem>
@@ -387,8 +394,8 @@
<listitem>
<para>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 <quote>INTR_MPSAFE</quote> and moving
+ been shown recently in the &man.aac.4; driver by making its
+ interrupt handler be <literal>INTR_MPSAFE</literal> and moving
all processing to a taskqueue.</para>
</listitem>
@@ -431,7 +438,7 @@
</listitem>
<listitem>
- <para>webstone: /usr/ports/www/webstone</para>
+ <para>webstone: <filename role="package">www/webstone</filename></para>
</listitem>
<listitem>
@@ -440,11 +447,11 @@
</listitem>
<listitem>
- <para>ApacheBench: /usr/ports/www/p5-ApacheBench</para>
+ <para>ApacheBench: <filename role="package">www/p5-ApacheBench</filename></para>
</listitem>
<listitem>
- <para>netperf: /usr/ports/benchmarks/netperf</para>
+ <para>netperf: <filename role="package">benchmarks/netperf</filename></para>
</listitem>
<listitem>
@@ -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 <quote>pccardd</quote> to
- <quote>devd</quote>. The power management and
- <quote>dumpcis</quote> functionality of pccardc(1) needs to be
+ OLDCARD to NEWCARD and from &man.pccardd.8; to
+ &man.devd.8;. The power management and
+ <quote>dumpcis</quote> 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 <quote>devd</quote> and
- <quote>devctl</quote>.</para>
+ integrated into &man.devd.8; and
+ &man.devctl.4;.</para>
</listitem>
<listitem>
@@ -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.</para>
+ be available for &t.releng.5;.</para>
</listitem>
<listitem>
@@ -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.</para>
+ requirement for &t.releng.5;.</para>
</listitem>
<listitem>
<para>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.</para>
<para>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.</para>
+ of gcc. This should also be investigated for &t.releng.5;.</para>
</listitem>
<listitem>
<para>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.</para>
</listitem>
<listitem>
- <para>disklabel(8) regressions: The biggest casualty of the
+ <para>&man.disklabel.8; regressions: The biggest casualty of the
introduction of GEOM appears to be the disklabel utility. The
- <quote>-r</quote> option gives unpredictable results in most
+ <option>-r</option> 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.</para>
@@ -566,9 +573,9 @@
</listitem>
<listitem>
- <para>If &os; 5.1 is not the branch point for RELENG_5 then the
+ <para>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.</para>
</listitem>
</itemizedlist>
@@ -579,7 +586,7 @@
<sect1 id="schedule">
<title>Schedule</title>
- <para>If branching RELENG_5 at the 5.1 release is paramount, 5.1 will
+ <para>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:</para>
@@ -588,10 +595,10 @@
<para>Jun 30, 2003: KSE and SMPng feature freeze</para>
</listitem>
<listitem>
- <para>Aug 4, 2003: 5.1-BETA, general code freeze</para>
+ <para>Aug 4, 2003: 5.1-BETA, general code freeze</para>
</listitem>
<listitem>
- <para>Aug 18, 2003: 5.1-RC1, RELENG_5 and RELENG_5_1 branched</para>
+ <para>Aug 18, 2003: 5.1-RC1, &t.releng.5; and &t.releng.5.1; branched</para>
</listitem>
<listitem>
<para>Aug 25, 2003: 5.1-RC2</para>
@@ -614,25 +621,25 @@
<itemizedlist>
<listitem>
- <para>May 5, 2003: 5.1-BETA, general code freeze</para>
+ <para>May 5, 2003: 5.1-BETA, general code freeze</para>
</listitem>
<listitem>
- <para>May 19, 2003: 5.1-RC1, RELENG_5_1 branched</para>
+ <para>May 19, 2003: 5.1-RC1, &t.releng.5.1; branched</para>
</listitem>
<listitem>
- <para>May 27, 2003: 5.1-RC2</para>
+ <para>May 27, 2003: 5.1-RC2</para>
</listitem>
<listitem>
- <para>Jun 2, 2003: 5.1-RELEASE</para>
+ <para>Jun 2, 2003: 5.1-RELEASE</para>
</listitem>
<listitem>
- <para>Jun 30, 2003: KSE and SMPng feature freeze</para>
+ <para>Jun 30, 2003: KSE and SMPng feature freeze</para>
</listitem>
<listitem>
- <para>Sept 1, 2003: 5.2-BETA, general code freeze</para>
+ <para>Sept 1, 2003: 5.2-BETA, general code freeze</para>
</listitem>
<listitem>
- <para>Sept 15, 2003: 5.2-RC1, RELENG_5 and RELENG_5_2 branched</para>
+ <para>Sept 15, 2003: 5.2-RC1, &t.releng.5; and &t.releng.5.2; branched</para>
</listitem>
<listitem>
<para>Sept 22, 2003: 5.2-RC2</para>
@@ -644,20 +651,20 @@
</sect1>
<sect1 id="future">
- <title>Post RELENG_5 direction</title>
+ <title>Post &t.releng.5; direction</title>
<para> 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.</para>
+ in &t.releng.head;.</para>
<para>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.</para>
+ 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;.</para>
</sect1>
</article>
==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/committers-guide/article.sgml#13 (text+ko) ====
@@ -17,7 +17,7 @@
<article>
<articleinfo>
- <title>Committer Guide</title>
+ <title>Committer's Guide</title>
<authorgroup>
<author>
@@ -25,7 +25,7 @@
</author>
</authorgroup>
- <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.154 2003/02/08 23:43:56 will Exp $</pubdate>
+ <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/committers-guide/article.sgml,v 1.161 2003/03/01 23:08:14 ceri Exp $</pubdate>
<copyright>
<year>1999</year>
@@ -76,7 +76,7 @@
<row>
<entry><emphasis>Mailing Lists</emphasis></entry>
<entry>&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 <filename>/home/mail/developers-archive</filename>
and <filename>/home/mail/committers-archive</filename>
on the <hostid role="domainname">FreeBSD.org</hostid>
@@ -145,8 +145,8 @@
<row>
<entry>doc</entry>
- <entry>nik@</entry>
- <entry>doc/, src/ documentation</entry>
+ <entry>doceng@</entry>
+ <entry>doc/, www/, src/ documentation</entry>
</row>
<row>
@@ -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
- <hostid role="fqdn">ncvs.FreeBSD.org</hostid> installed, except
- for the repomeisters.</para>
+ There are no login shells available on
+ <hostid role="fqdn">ncvs.FreeBSD.org</hostid>, except
+ to the repomeisters.</para>
<para>CVS operations are done remotely by setting the
<envar>CVSROOT</envar> environment variable to
@@ -400,7 +400,7 @@
<screen>&prompt.user; <userinput>cvs status shazam</userinput></screen>
<para>This displays the status of the
- <filename>shazam</filename> file or of every file in the
+ file <filename>shazam</filename> or of every file in the
<filename>shazam</filename> directory. For every file, the
status is given as one of:</para>
@@ -446,12 +446,12 @@
</listitem>
<listitem>
- <para>Once you have checked something out, update it with the
+ <para>Once you have checked something out, you can update it with the
<command>update</command> command.</para>
<screen>&prompt.user; <userinput>cvs update shazam</userinput></screen>
- <para>This updates the <filename>shazam</filename> file or the
+ <para>This updates the file <filename>shazam</filename> or the
contents of the <filename>shazam</filename> directory to the
latest version along the branch you checked out. If you
checked out a <quote>point in time</quote>, does nothing
@@ -490,7 +490,7 @@
sticky tags, dates or revisions whereas <option>-r</option>
and <option>-D</option> set new ones.</para>
- <para>Theoretically, specifying <literal>HEAD</literal> as
+ <para>Theoretically, specifying <literal>HEAD</literal> as the
argument to <option>-r</option> will give you the same result
as <option>-A</option>, but that is just theory.</para>
@@ -875,7 +875,7 @@
(<filename role="package">editors/vim5</filename>) 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. </para>
+ and CVS/RCS logs. </para>
<screen>&prompt.user; <userinput>echo "syn on" >> ~/.vimrc </userinput>
&prompt.user; <userinput>cvs diff -Nu shazam | vim -</userinput>
@@ -1036,9 +1036,9 @@
again until the matter is settled. Remember – with CVS we
can always change it back.</para>
- <para>Don't impugn the intentions of someone you disagree with.
+ <para>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.</para>
- <para>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
+ <para>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.</para>
<para>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.</para>
</sect1>
@@ -1090,10 +1090,6 @@
</listitem>
<listitem>
- <para><ulink url="../../../../send-pr.html">http://www.FreeBSD.org/send-pr.html</ulink></para>
- </listitem>
-
- <listitem>
<para>&man.send-pr.1;</para>
</listitem>
</itemizedlist>
@@ -1163,7 +1159,7 @@
#
# FreeBSD categories
#
-docs:Documentation Bug:nik:</programlisting>
+docs:Documentation Bug:freebsd-doc:</programlisting>
</step>
<step>
@@ -1208,6 +1204,8 @@
probably get to know in your role as a committer. Briefly,
and by no means all-inclusively, these are:</para>
+ <!-- XXX The TRB are missing -->
+
<variablelist>
<varlistentry>
@@ -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: <ulink
url="http://www.FreeBSD.org/smp/">
@@ -1391,7 +1389,7 @@
<term>&a.developers;</term>
<listitem>
- <para>developers is all committers. This list was created to be a
+ <para>All committers are subscribed to -developers. This list was created to be a
forum for the committers <quote>community</quote> issues.
Examples are Core
voting, announcements, etc. This list is
@@ -1504,11 +1502,6 @@
</listitem>
<listitem>
- <para>Never touch the repository directly. Ask a
- Repomeister.</para>
- </listitem>
-
- <listitem>
<para>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.</para>
+ maintainer in rule #5.</para>
</listitem>
<listitem>
@@ -1591,8 +1584,8 @@
<para>In all other aspects of project operation, core is a subset
of committers and is bound by the <emphasis>same
- rules</emphasis>. Just because someone is in core does not mean
- that they have special dispensation to step outside of any of
+ rules</emphasis>. 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 <quote>special powers</quote>
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 @@
<para>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 <ulink
- url="../contributors/article.html">
+ url="../contributors/staff-who.html">
http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributors/staff-who.html</ulink>
for more information on this.</para>
</listitem>
<listitem>
- <para>Never touch the repository directly. Ask a
- Repomeister.</para>
-
- <para>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!</para>
-
- <para>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.</para>
- </listitem>
-
- <listitem>
<para>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.</para>
+ #5.</para>
<para>This is another <quote>do not argue about it</quote>
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.</para>
+ <!-- XXX Mention TRB here too -->
</listitem>
<listitem>
@@ -1869,6 +1843,9 @@
<listitem>
<para>Test your changes before committing them.</para>
+ <!-- XXX Needs update re sparc64 + pc98
+ Also, needs more details on which machines are available for testing
+ -->
<para>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 @@
<answer>
<para>First, please read the section about repository
- copy.</para>
+ copies.</para>
<para>The easiest way to add a new port is to use the
<command>addport</command> script on
@@ -2293,7 +2270,7 @@
<step>
<para>Upgrade the copied port to the new version (remember
to change the <makevar>PORTNAME</makevar> so there
- aren't duplicate ports with the same name).</para>
+ are not duplicate ports with the same name).</para>
</step>
<step>
@@ -2552,7 +2529,7 @@
<sect1 id="perks">
<title>Perks of the Job</title>
- <para>Unfortunately, there aren't many perks involved with being a
+ <para>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:</para>
==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/contributors/article.sgml#16 (text+ko) ====
@@ -20,7 +20,7 @@
<articleinfo>
<title>Contributors to FreeBSD</title>
- <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/contributors/article.sgml,v 1.342 2003/02/16 03:00:36 markp Exp $</pubdate>
+ <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/contributors/article.sgml,v 1.355 2003/03/05 16:07:59 obraun Exp $</pubdate>
<abstract>
<para>This article lists individuals and organizations who have
@@ -1444,6 +1444,10 @@
</listitem>
<listitem>
+ <para>&a.das;</para>
+ </listitem>
+
+ <listitem>
<para>&a.schweikh;</para>
</listitem>
@@ -2840,6 +2844,11 @@
</listitem>
<listitem>
+ <para>Brad Davis
+ <email>so14k at so14k.com</email></para>
+ </listitem>
+
+ <listitem>
<para>Brad Hendrickse
<email>bradh at uunet.co.za</email></para>
</listitem>
@@ -3005,6 +3014,11 @@
</listitem>
<listitem>
+ <para>Carl Schmidt
+ <email>carl at perlpimp.codersluts.net</email></para>
+ </listitem>
+
+ <listitem>
<para>Casper
<email>casper at acc.am</email></para>
</listitem>
@@ -5062,6 +5076,11 @@
</listitem>
<listitem>
+ <para>Jon Nistor
+ <email>nistor at snickers.org</email></para>
+ </listitem>
+
+ <listitem>
<para>Jon Wilson
<email>jon at phuq.co.uk</email></para>
</listitem>
@@ -5486,6 +5505,11 @@
</listitem>
<listitem>
+ <para>Koop Mast
+ <email>einekoai at chello.nl</email></para>
+ </listitem>
+
+ <listitem>
<para>Kostya Lukin
<email>lukin at okbmei.msk.su</email></para>
</listitem>
@@ -5736,6 +5760,11 @@
</listitem>
<listitem>
+ <para>Mark Linimon
+ <email>linimon at lonesome.com</email></para>
+ </listitem>
+
+ <listitem>
<para>Mark Mayo
<email>markm at vmunix.com</email></para>
</listitem>
@@ -5806,6 +5835,11 @@
</listitem>
<listitem>
+ <para>Martin Preuss
+ <email>martin at libchipcard.de</email></para>
+ </listitem>
+
+ <listitem>
<para>Martti Kuparinen
<email>martti.kuparinen at ericsson.com</email></para>
</listitem>
@@ -5961,6 +5995,11 @@
</listitem>
<listitem>
+ <para>Maxim Tuliuk
+ <email>mt at primats.org.ua</email></para>
+ </listitem>
+
+ <listitem>
<para>Maxime Romano
<email>verbophobe at hotmail.com</email></para>
</listitem>
@@ -7330,6 +7369,11 @@
</listitem>
<listitem>
+ <para>Rui Lopes
+ <email>rui at ruilopes.com</email></para>
+ </listitem>
+
+ <listitem>
<para>Ruslan Belkin
<email>rus at home2.UA.net</email></para>
</listitem>
@@ -7440,6 +7484,11 @@
</listitem>
<listitem>
+ <para>Sascha Holzleiter
+ <email>sascha at root-login.org</email></para>
+ </listitem>
+
+ <listitem>
<para>Sascha Wildner
<email>swildner at channelz.GUN.de</email></para>
</listitem>
@@ -7700,6 +7749,11 @@
</listitem>
<listitem>
+ <para>Steffen Mazanek
+ <email>steffen.mazanek at unibw-muenchen.de</email></para>
+ </listitem>
+
+ <listitem>
<para>Steffen Vogelreuter
<email>Steffen at Vogelreuter.De</email></para>
</listitem>
@@ -7851,7 +7905,7 @@
<listitem>
<para>Sune Stjerneby
- <email>stjerneby at usa.net</email></para>
+ <email>sst at vmunix.dk</email></para>
</listitem>
<listitem>
@@ -8083,6 +8137,11 @@
<para>Tim Bishop
<email>tim at bishnet.net</email></para>
</listitem>
+
+ <listitem>
+ <para>Tim Daneliuk
+ <email>tundra at tundraware.com</email></para>
+ </listitem>
<listitem>
<para>Tim Kientzle
==== //depot/projects/trustedbsd/doc/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml#3 (text+ko) ====
@@ -19,10 +19,12 @@
<copyright>
<year>2001</year>
+ <year>2002</year>
+ <year>2003</year>
<holder role="mailto:stijn at win.tue.nl">Stijn Hoop</holder>
</copyright>
- <releaseinfo>$FreeBSD: doc/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml,v 1.7 2002/07/25 17:22:43 fanf Exp $</releaseinfo>
+ <releaseinfo>$FreeBSD: doc/en_US.ISO8859-1/articles/cvs-freebsd/article.sgml,v 1.9 2003/02/18 11:14:38 blackend Exp $</releaseinfo>
<abstract>
<para>This article describes the steps I took to setup a CVS repository
@@ -135,7 +137,7 @@
&prompt.user; <userinput>cvs add *</userinput></screen>
Note that you will probably get a few warnings about some directories
- not being copied; this is normal, you don't need those.</para>
+ not being copied; this is normal, you do not need those.</para>
</sect2>
<sect2>
@@ -241,7 +243,7 @@
can edit this as you wish. More information about this file
is available in the <application>CVS</application> manual.
Note that the <literal>-t</literal> and <literal>-f</literal>
- options don't work correctly with client/server
+ options do not work correctly with client/server
<application>CVS</application>.</para>
</listitem>
@@ -257,7 +259,7 @@
functionality, as parsing the log message is done by
<filename>verifymsg</filename> and <filename>logcheck</filename>.
This is because the <filename>editinfo</filename>
- functionality doesn't work properly with remote commits, or ones
+ functionality does not work properly with remote commits, or ones
that use the <literal>-m</literal> or <literal>-F</literal>
options. You should not have to touch this file.</para>
</listitem>
@@ -371,7 +373,7 @@
automatically <quote>unwrap</quote> binary files (see
<filename>cvswrappers</filename>) 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.</para>
</listitem>
@@ -387,7 +389,7 @@
automatically <quote>wrap</quote> binary files (see
<filename>cvswrappers</filename>) 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.</para>
</listitem>
</itemizedlist>
@@ -442,7 +444,7 @@
<para><literal>$MAIL_BRANCH_HDR</literal> - 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 at trustedbsd.org
with "unsubscribe trustedbsd-cvs" in the body of the message
More information about the trustedbsd-cvs
mailing list