Committer's Guide: fix nits
Rene Ladan
rene at freebsd.org
Mon Dec 15 00:43:45 UTC 2008
Hi,
below is a patch which fixes a lot of tiny nits in the Committer's Guide,
based on revision 1.279 + perforce change 154510 (http://perforce.freebsd.org/chv.cgi?CH=154510)
Would this be suitable to commit?
Thanks,
Rene
-------- Originele bericht --------
Onderwerp: PERFORCE change 154670 for review
Datum: Mon, 15 Dec 2008 00:20:25 GMT
Van: Rene Ladan <rene at FreeBSD.org>
Aan: Perforce Change Reviews <perforce at FreeBSD.org>
http://perforce.freebsd.org/chv.cgi?CH=154670
Change 154670 by rene at rene_self on 2008/12/15 00:20:10
Fix a lot of nits in the Committers Guide, like capitalization,
entity usage, language fixes, and some tiny content fixes.
Affected files ...
.. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#8 edit
Differences ...
==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/committers-guide/article.sgml#8 (text+ko) ====
@@ -9,7 +9,7 @@
<authorgroup>
<author>
- <surname>The FreeBSD Documentation Project</surname>
+ <surname>The &os; Documentation Project</surname>
</author>
</authorgroup>
@@ -25,7 +25,8 @@
<year>2005</year>
<year>2006</year>
<year>2007</year>
- <holder>The FreeBSD Documentation Project</holder>
+ <year>2008</year>
+ <holder>The &os; Documentation Project</holder>
</copyright>
<legalnotice id="trademarks" role="trademarks">
@@ -39,18 +40,18 @@
</legalnotice>
<abstract>
- <para>This document provides information for the FreeBSD committer
+ <para>This document provides information for the &os; committer
community. All new committers should read this document before they
start, and existing committers are strongly encouraged to review it
from time to time.</para>
- <para>Almost all FreeBSD developers have commmit rights to one or
+ <para>Almost all &os; developers have commmit rights to one or
more repositories. However, a few developers do not, and some of
the information here applies to them as well. (For instance, some
people only have rights to work with the Problem Report database).
Please see <xref linkend="non-committers"> for more information.</para>
- <para>This document may also be of interest to members of the FreeBSD
+ <para>This document may also be of interest to members of the &os;
community who want to learn more about how the project works.</para>
</abstract>
</articleinfo>
@@ -86,7 +87,7 @@
<row>
<entry><emphasis>&a.bugmeister;</emphasis></entry>
- <entry>&a.ceri; &a.linimon;, and &a.remko</entry>
+ <entry>&a.ceri; &a.linimon;, and &a.remko;</entry>
</row>
<row>
@@ -139,10 +140,10 @@
<sect1 id="committer.types">
<title>Commit Bit Types</title>
- <para>The FreeBSD CVS repository has a number of components which,
+ <para>The &os; CVS repository has a number of components which,
when combined, support the basic operating system source,
documentation, third party application ports infrastructure, and
- various maintained utilities. When FreeBSD commit bits are
+ various maintained utilities. When &os; commit bits are
allocated, the areas of the tree where the bit may be used are
specified. Generally, the areas associated with a bit reflect who
authorized the allocation of the commit bit. Additional areas of
@@ -185,9 +186,9 @@
<para>Commit bits allocated prior to the development of the notion of
areas of authority may be appropriate for use in many parts of the
tree. However, common sense dictates that a committer who has not
- previously worked in an area of the tree seek review prior to
- committing, seek approval from the appropriate responsible party,
- and/or work with a mentor. Since the rules regarding code
+ previously worked in an area of the tree seeks review prior to
+ committing, seeks approval from the appropriate responsible party,
+ and/or works with a mentor. Since the rules regarding code
maintenance differ by area of the tree, this is as much for the
benefit of the committer working in an area of less familiarity as
it is for others working on the tree.</para>
@@ -281,7 +282,7 @@
via <application>CVSup</application> for the convenience of our users.</para>
<note><para>Note that the <literal>www</literal> module containing sources
- for the <ulink url="http://www.FreeBSD.org">FreeBSD website</ulink> is
+ for the <ulink url="http://www.FreeBSD.org">&os; website</ulink> is
contained within the <literal>doc</literal> repository.</para></note>
<para>The CVS repositories are hosted on the repository machines.
@@ -382,7 +383,7 @@
linkend="repomeisters">repomeister</link> will copy the file(s)
to their new name and/or location and let you know when it is
done. The purpose of a repository copy is to preserve file
- change history, or logs. We in the FreeBSD Project greatly
+ change history, or logs. We in the &os; Project greatly
value the change history that CVS gives to the project.</para>
<para>CVS reference information, tutorials, and FAQs can be found at:
@@ -435,7 +436,7 @@
</tgroup>
</table>
- <para>Practical FreeBSD examples:</para>
+ <para>Practical &os; examples:</para>
<itemizedlist>
<listitem>
@@ -690,7 +691,7 @@
</informaltable>
<para>Merging is what happens if you check out a copy of
- some source code, modify it, then someone else commits a
+ some file, modify it, then someone else commits a
change, and you run <command>cvs update</command>. CVS notices
that you have made local changes, and tries to merge your
changes with the changes between the version you originally
@@ -750,7 +751,7 @@
</itemizedlist>
<para>You will almost certainly get a conflict because
- of the <literal>$Id$</literal> (or in FreeBSD's case,
+ of the <literal>$Id$</literal> (or in &os;'s case,
<literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>)
lines, so you will have to edit the file to resolve the conflict
(remove the marker lines and the second <literal>$Id$</literal> line,
@@ -1187,7 +1188,7 @@
will have any idea who you are or what you are working on. You do
not have to write a comprehensive biography, just write a paragraph
or two about who you are and what you plan to be working on as a
- developer in FreeBSD. (You should also mention who your mentor
+ developer in &os;. (You should also mention who your mentor
will be). Email this to the &a.developers; and you will
be on your way!</para>
</listitem>
@@ -1213,7 +1214,7 @@
check in place but that may change. Some people blame these
checks for bouncing valid email. If you want these checks
turned off for your email you can place a file named
- <filename>~/.spam_lover</filename> in your home directory
+ <filename>~/.spam_lover</filename>
on <hostid role="fqdn">freefall.FreeBSD.org</hostid> to
disable the checks for your email.</para>
</listitem>
@@ -1232,7 +1233,7 @@
<para>All new developers also have a mentor assigned to them for
the first few months. Your mentor is responsible for teaching
you the rules and conventions of the project and guiding your
- first steps in the developer community. He or she is also
+ first steps in the developer community. Your mentor is also
personally responsible for your actions during this initial
period.</para>
@@ -1339,7 +1340,7 @@
person has made. It can be found on <hostid>freefall</hostid>
at <filename>~fenner/bin/whodid</filename>. If your queries go
unanswered or the committer otherwise indicates a lack of
- proprietary interest in the area affected, go ahead and commit
+ interest in the area affected, go ahead and commit
it.</para>
<para>If you are unsure about a commit for any reason at
@@ -1355,7 +1356,7 @@
If they see a different solution to a problem than you, or even
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
+ destroy your hard work, personal image, or &os;, but simply
because they have a different outlook on the world. Different
is good.</para>
@@ -1379,7 +1380,7 @@
<sect1 id="gnats">
<title>GNATS</title>
- <para>The FreeBSD Project utilizes
+ <para>The &os; Project utilizes
<application>GNATS</application> for tracking bugs and change
requests. Be sure that if you commit a fix or suggestion found
in a <application>GNATS</application> PR, you use
@@ -1408,8 +1409,8 @@
</listitem>
</itemizedlist>
- <para>You can run a local copy of GNATS, and then integrate the FreeBSD
- GNATS tree in to it using CVSup. Then you can run GNATS commands
+ <para>You can run a local copy of GNATS, and then integrate the &os;
+ GNATS tree in to it using CVSup. Then you can run the GNATS commands
locally.
This lets you query the PR database without needing to be connected to
the Internet.</para>
@@ -1427,7 +1428,7 @@
<programlisting>gnats release=current prefix=/usr</programlisting>
- <para>This will place the FreeBSD GNATS tree in
+ <para>This will place the &os; GNATS tree in
<filename>/usr/gnats</filename>. You can use a
<emphasis>refuse</emphasis> file to control which categories to
receive. For example, to only receive <literal>docs</literal> PRs,
@@ -1471,7 +1472,7 @@
<programlisting># This category is mandatory
pending:Category for faulty PRs:gnats-admin:
#
-# FreeBSD categories
+# &os; categories
#
docs:Documentation Bug:freebsd-doc:</programlisting>
</step>
@@ -1511,7 +1512,7 @@
<title>Who's Who</title>
<para>Besides the repository
- meisters, there are other FreeBSD project members and teams whom you will
+ meisters, there are other &os; project members and teams whom you will
probably get to know in your role as a committer. Briefly,
and by no means all-inclusively, these are:</para>
@@ -1524,7 +1525,7 @@
<para>John is the manager of the SMPng Project, and has
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.
+ He is also the editor of the SMPng Architecture Document.
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:
@@ -1538,7 +1539,7 @@
<listitem>
<para>doceng is the group responsible for the documentation build
infrastructure, approving new documentation committers, and
- ensuring that the FreeBSD website and documentation on the FTP
+ ensuring that the &os; website and documentation on the FTP
site is up to date with respect to the CVS tree. It is not a
conflict resolution body. The vast majority of documentation
related discussion takes place on the &a.doc;. More details regarding the doceng team can be found in its <ulink url="http://www.FreeBSD.org/internal/doceng.html">charter</ulink>. Committers
@@ -1567,7 +1568,7 @@
When you do a commit that could have been done better,
Bruce will be there to tell you. Be thankful that someone
is. Bruce is also very knowledgeable on the various
- standards applicable to FreeBSD.</para>
+ standards applicable to &os;.</para>
</listitem>
</varlistentry>
@@ -1603,7 +1604,7 @@
<listitem>
<para>Colin is the
- <ulink url="&url.base;/security/">FreeBSD Security
+ <ulink url="&url.base;/security/">&os; Security
Officer</ulink>
and oversees the &a.security-officer;.
</para>
@@ -1618,7 +1619,7 @@
are not sure of some potential change to the networking
subsystem you have in mind, Garrett is someone to talk
to. Garrett is also very knowledgeable on the various
- standards applicable to FreeBSD.</para>
+ standards applicable to &os;.</para>
</listitem>
</varlistentry>
@@ -1643,12 +1644,12 @@
voting, announcements, etc.</para>
<para>The &a.developers; is for the exclusive use of
- FreeBSD committers. In order to develop FreeBSD, committers must
+ &os; committers. In order to develop &os;, committers must
have the ability to openly discuss matters that will be resolved
before they are publicly announced. Frank discussions of work in
- progress are not suitable for open publication and may harm FreeBSD.</para>
+ progress are not suitable for open publication and may harm &os;.</para>
- <para>All FreeBSD committers are reminded to obey the copyright of the
+ <para>All &os; committers are reminded to obey the copyright of the
original author(s) of &a.developers; mail. Do not publish or
forward messages from the &a.developers; outside the list
membership without permission of all of the authors.</para>
@@ -1661,12 +1662,12 @@
<para>This list is
<emphasis>not</emphasis> intended as a place for code reviews or a
replacement for the &a.arch; or the &a.audit;. In fact
- using it as such hurts the FreeBSD Project as it gives a sense of a
- closed list where general decisions affecting all of the FreeBSD
+ using it as such hurts the &os; Project as it gives a sense of a
+ closed list where general decisions affecting all of the &os;
using community are made without being <quote>open</quote>.
Last, but not least <emphasis>never, never ever, email
- the &a.developers; and CC:/BCC: another FreeBSD list</emphasis>.
- Never, ever email another FreeBSD email list and CC:/BCC:
+ the &a.developers; and CC:/BCC: another &os; list</emphasis>.
+ Never, ever email another &os; email list and CC:/BCC:
the &a.developers;. Doing so can greatly diminish the benefits
of this list.</para>
</listitem>
@@ -1679,7 +1680,7 @@
<procedure>
<step>
- <para>If you do not wish to type your password in every
+ <para>If you do not wish to type in your password every
time you use &man.ssh.1;, and you use RSA or DSA keys to
authenticate, &man.ssh-agent.1; is there for your
convenience. If you want to use &man.ssh-agent.1;, make
@@ -1702,7 +1703,7 @@
(<filename><envar>$HOME</envar>/.ssh/id_dsa.pub</filename>
or <filename><envar>$HOME</envar>/.ssh/id_rsa.pub</filename>)
to the person setting you up as a committer so it can be put
- into <filename><replaceable>yourlogin</replaceable></filename> file in
+ into <filename><replaceable>yourlogin</replaceable></filename> in
<filename class="directory">/etc/ssh-keys/</filename> on
<hostid>freefall</hostid>.
</para>
@@ -1789,7 +1790,7 @@
</sect1>
<sect1 id="rules">
- <title>The FreeBSD Committers' Big List of Rules</title>
+ <title>The &os; Committers' Big List of Rules</title>
<orderedlist>
<listitem>
@@ -1858,7 +1859,7 @@
<listitem>
<para>Do not commit to anything under the
<filename>src/contrib</filename>,
- <filename>src/crypto</filename>, and
+ <filename>src/crypto</filename>, or
<filename>src/sys/contrib</filename> trees without
<emphasis>explicit</emphasis> approval from the respective
maintainer(s).</para>
@@ -1997,7 +1998,7 @@
<listitem>
<para>Respect existing maintainers if listed.</para>
- <para>Many parts of FreeBSD are not <quote>owned</quote> in
+ <para>Many parts of &os; are not <quote>owned</quote> in
the sense that any specific individual will jump up and
yell if you commit a change to <quote>their</quote> area,
but it still pays to check first. One convention we use
@@ -2016,8 +2017,8 @@
question and see if someone has been working recently or
predominantly in that area.</para>
- <para>Other areas of FreeBSD fall under the control of
- someone who manages an overall category of FreeBSD
+ <para>Other areas of &os; fall under the control of
+ someone who manages an overall category of &os;
evolution, such as internationalization or networking.
See <ulink
url="&url.base;/administration.html">
@@ -2111,7 +2112,7 @@
flame-o-gram at least had the grace to send it privately,
then have the grace to keep it private yourself. If you
feel you are being unfairly treated by another developer,
- and it is causing you anguish, bring the matter up with
+ and it is causing you anguish, bring up the matter with
core rather than taking it public. Core will do its best to
play peace makers and get things back to sanity. In cases
where the dispute involves a change to the codebase and
@@ -2134,7 +2135,7 @@
and committing 10 megabytes worth of accumulated stuff.
People who abuse this on a regular basis will have their
commit privileges suspended until they get back from the
- FreeBSD Happy Reeducation Camp we run in Greenland.</para>
+ &os; Happy Reeducation Camp we run in Greenland.</para>
</listitem>
<listitem>
@@ -2167,9 +2168,9 @@
running that code. If you have a change which also may
break another architecture, be sure and test on all
supported architectures. Please refer to the <ulink
- url="http://www.FreeBSD.org/internal/">FreeBSD Internal
+ url="http://www.FreeBSD.org/internal/">&os; Internal
Page</ulink> for a list of available resources. As other
- architectures are added to the FreeBSD supported platforms
+ architectures are added to the &os; supported platforms
list, the appropriate shared testing resources will be
made available.</para>
</listitem>
@@ -2194,7 +2195,7 @@
<para>Please note that this does not mean you should not try to
improve the software in question; you are still more than
welcome to do so. Ideally, you should submit your patches to
- the vendor. If your changes are FreeBSD-specific, talk to the
+ the vendor. If your changes are &os;-specific, talk to the
maintainer; they may be willing to apply them locally. But
whatever you do, do <emphasis>not</emphasis> commit there by
yourself!</para>
@@ -2208,9 +2209,9 @@
<sect2>
<title>Policy on Multiple Architectures</title>
- <para>FreeBSD has added several new arch ports during recent
+ <para>&os; has added several new architecture ports during recent
release cycles and is truly no longer an &i386; centric operating
- system. In an effort to make it easier to keep FreeBSD portable
+ system. In an effort to make it easier to keep &os; portable
across the platforms we support, core has developed the following
mandate:</para>
@@ -2223,7 +2224,7 @@
to the source tree.</para>
</blockquote>
- <para>The i386 and Sparc64 platforms were chosen due to being more
+ <para>The Sparc64 and i386 platforms were chosen due to being more
readily available to developers and as representatives of more
diverse processor and system designs - big vs little endian,
register file vs register stack, different DMA and cache
@@ -2306,39 +2307,39 @@
<sect1 id="archs">
<title>Support for Multiple Architectures</title>
- <para>FreeBSD is a highly portable operating system intended to
+ <para>&os; is a highly portable operating system intended to
function on many different types of hardware architectures.
Maintaining clean separation of Machine Dependent (MD) and Machine
Independent (MI) code, as well as minimizing MD code, is an important
part of our strategy to remain agile with regards to current
hardware trends. Each new hardware architecture supported by
- FreeBSD adds substantially to the cost of code maintenance,
+ &os; adds substantially to the cost of code maintenance,
toolchain support, and release engineering. It also dramatically
increases the cost of effective testing of kernel changes. As such,
there is strong motivation to differentiate between classes of
support for various architectures while remaining strong in a few
- key architectures that are seen as the FreeBSD "target audience".
+ key architectures that are seen as the &os; "target audience".
</para>
<sect2>
<title>Statement of General Intent</title>
- <para>The FreeBSD Project targets "production quality commercial
+ <para>The &os; Project targets "production quality commercial
off-the-shelf (COTS) workstation, server, and high-end embedded
systems". By retaining a focus on a narrow set of architectures
- of interest in these environments, the FreeBSD Project is able
+ of interest in these environments, the &os; Project is able
to maintain high levels of quality, stability, and performance,
as well as minimize the load on various support teams on the
project, such as the ports team, documentation team,
security officer, and release engineering teams. Diversity in
- hardware support broadens the options for FreeBSD consumers by
+ hardware support broadens the options for &os; consumers by
offering new features and usage opportunities (such as support
- for 64-bit CPUs, use in embedded environments, etc.), but these
+ for 64 bit CPUs, use in embedded environments, etc.), but these
benefits must always be carefully considered in terms of the real-world
maintenance cost associated with additional platform support.
</para>
- <para>The FreeBSD Project differentiates platform targets into
+ <para>The &os; Project differentiates platform targets into
four tiers. Each tier includes a specification of the
requirements for an architecture to be in that tier,
as well as specifying the obligations of developers with
@@ -2357,13 +2358,13 @@
(features which are inherently architecture-specific, such as
support for hardware device drivers, may be exempt from this
requirement). In general, all Tier 1 platforms must have build
- and tinderbox support either in the FreeBSD.org cluster, or
+ and Tinderbox support either in the FreeBSD.org cluster, or be
easily available for all developers. Embedded platforms may
- substitute an emulator available in the FreeBSD cluster for
+ substitute an emulator available in the &os; cluster for
actual hardware.</para>
<para>Tier 1 architectures are expected to be Production Quality
- with respects to all aspects of the FreeBSD operating system,
+ with respects to all aspects of the &os; operating system,
including installation and development environments.</para>
<para>Tier 1 architectures are expected to be completely
@@ -2377,12 +2378,12 @@
platform, or have the appropriate filters to prevent the
inappropriate ones from building there. The packaging system
must support all Tier 1 architectures. To ensure an
- architectures Tier 1 status, proponents of that architecture
+ architecture's Tier 1 status, proponents of that architecture
must show that all relevant packages can be built on that
platform.</para>
<para>Tier 1 embedded architectures must be able to cross-build
- packages on at least one other tier 1 architecture. The
+ packages on at least one other Tier 1 architecture. The
packages must be the most relevant for the platform, but may
be a non-empty subset of those that build natively.</para>
@@ -2403,19 +2404,19 @@
maintainer is expected to work with the platform maintainers
to refine these changes. Major new toolchain components are
allowed to break support for Tier 2 architectures if the
- FreeBSD-local changes haven't been incorporated upstream. The
+ &os;-local changes have not been incorporated upstream. The
toolchain maintainers are expected to provide prompt review of
any proposed changes and cannot block, through their inaction,
- changes going into the tree. New features added to FreeBSD
+ changes going into the tree. New features added to &os;
should be feasible to implement on these platforms, but an
implementation is not required before the feature may be added
- to the FreeBSD source tree. New features that may be difficult
+ to the &os; source tree. New features that may be difficult
to implement on Tier 2 architectures should provide a means of
disabling them on those architectures. The implementation of
- a Tier 2 architecture may be committed to the main FreeBSD
+ a Tier 2 architecture may be committed to the main &os;
tree as long as it does not interfere with production work on
Tier 1 platforms, or substantially with other Tier 2 platforms.
- Before a Tier 2 platform can be added to the FreeBSD base
+ Before a Tier 2 platform can be added to the &os; base
source tree, the platform must be able to boot multi-user on
actual hardware. Generally, there must be at least three active
developers working on the platform.</para>
@@ -2425,22 +2426,22 @@
reaching end of life may also be moved from Tier 1 status to Tier
2 status as the availability of resources to continue to maintain
the system in a Production Quality state diminishes. Well supported
- niche architectures may also be tier 2.</para>
+ niche architectures may also be Tier 2.</para>
<para>Tier 2 architectures may have some support for them
integrated into the ports infrastructure. They may have cross
compilation support added, at the discretion of portmgr. Some
- ports must built natively, into packages if the package system
+ ports must built natively into packages if the package system
supports that architecture. If not integrated into the base
system, some external patches for the architecture for ports
must be available.</para>
- <para>Tier 2 architectures can be integrated into the FreeBSD
+ <para>Tier 2 architectures can be integrated into the &os;
handbook. The basics for how to get a system running must be
documented, although not necessarily for every single board or
- system a tier 2 architecture supports. The supported hardware
+ system a Tier 2 architecture supports. The supported hardware
list must exist and should be no more than a couple of months
- old. It should be integrated into the FreeBSD
+ old. It should be integrated into the &os;
documentation.</para>
<para>Current Tier 2 platforms are ARM, PowerPC, ia64, Sparc64 and
@@ -2456,13 +2457,13 @@
Tier 3 platforms are architectures in the early stages of
development, for non-mainstream hardware platforms, or which
are considered legacy systems unlikely to see broad future
- use. New tier 3 systems will not be committed to the base
+ use. New Tier 3 systems will not be committed to the base
source tree. Support for Tier 3 systems may be worked on in
- the FreeBSD Perforce Repository, providing source control and
- easier change integration from the main FreeBSD tree.
+ the &os; Perforce Repository, providing source control and
+ easier change integration from the main &os; tree.
Platforms that transition to Tier 3 status may be removed from
the tree if they are no longer actively supported by the
- FreeBSD developer community at the discretion of the release
+ &os; developer community at the discretion of the release
engineer.</para>
<para>Tier 3 platforms may have ports support, either integrated
@@ -2471,7 +2472,7 @@
<para>Tier 3 platforms must have the basics documented for how
to build a kernel and how to boot it on at least one target
hardware or emulation environment. This documentation need
- not be integrated into the FreeBSD tree.</para>
+ not be integrated into the &os; tree.</para>
<para>Current Tier 3 platforms are MIPS and &s390;.</para>
</sect2>
@@ -2490,7 +2491,7 @@
<title>Policy on Changing the Tier of an Architecture</title>
<para>Systems may only be moved from one tier to another by
- approval of the FreeBSD Core Team, which shall make that
+ approval of the &os; Core Team, which shall make that
decision in collaboration with the Security Officer, Release
Engineering, and toolchain maintenance teams.</para>
</sect2>
@@ -2555,10 +2556,10 @@
make sure you have fixed the simple ones.</para>
<para>If the port came from a submitter who has not
- contributed to the project before, add that person's
+ contributed to the Project before, add that person's
name to the <ulink
url="&url.articles.contributors;/contrib-additional.html">Additional
- Contributors</ulink> section of the FreeBSD Contributors
+ Contributors</ulink> section of the &os; Contributors
List.</para>
<para>Close the PR if the port came in as a PR. To close
@@ -3232,7 +3233,7 @@
<sect1 id="non-committers">
<title>Issues Specific To Developers Who Are Not Committers</title>
- <para>A few people who have access to the FreeBSD machines do not
+ <para>A few people who have access to the &os; machines do not
have commit bits. For instance, the project is willing to give
access to the GNATS database to contributors who have shown interest
and dedication in working on Problem Reports.</para>
@@ -3276,7 +3277,7 @@
<listitem>
<para>
- <link linkend="rules">The FreeBSD Committers' Big List of Rules</link>
+ <link linkend="rules">The &os; Committers' Big List of Rules</link>
<para>
</listitem>
</itemizedlist>
@@ -3392,7 +3393,7 @@
well.</para>
<para>This information consists of one or more lines containing the
- key word or phrase, a colon, tabs for formatting, and then the
+ key word or phrase, a colon, tabs and/or spaces for formatting, and then the
additional information.</para>
<para>The key words or phrases are:</para>
@@ -3410,14 +3411,14 @@
<entry><literal>Submitted by:</literal></entry>
<entry>The name and e-mail address of the person that
submitted the fix; for committers, just the username on
- the FreeBSD cluster.</entry>
+ the &os; cluster.</entry>
</row>
<row>
<entry><literal>Reviewed by:</literal></entry>
<entry>The name and e-mail address of the person or people
that reviewed the change; for committers, just the
- username on the FreeBSD cluster. If a patch was
+ username on the &os; cluster. If a patch was
submitted to a mailing list for review, and the review
was favorable, then just include the list name.</entry>
</row>
@@ -3426,7 +3427,7 @@
<entry><literal>Approved by:</literal></entry>
<entry>The name and e-mail address of the person or people
that approved the change; for committers, just the
- username on the FreeBSD cluster. It is customary to get
+ username on the &os; cluster. It is customary to get
prior approval for a commit if it is to an area of the
tree to which you do not usually commit. In addition,
during the run up to a new release all commits
@@ -3586,7 +3587,7 @@
<answer>
<para>The mailing lists are archived under <filename>/g/mail</filename>
which will show up as <filename>/hub/g/mail</filename> with &man.pwd.1;.
- This location is accessible from any machine on the FreeBSD cluster.</para>
+ This location is accessible from any machine on the &os; cluster.</para>
</answer>
</qandaentry>
--
http://www.rene-ladan.nl/
GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net)
More information about the freebsd-doc
mailing list