From owner-svn-doc-all@FreeBSD.ORG Sun Jun 30 01:00:51 2013
Return-Path:
Delivered-To: svn-doc-all@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
by hub.freebsd.org (Postfix) with ESMTP id 38ED3A07;
Sun, 30 Jun 2013 01:00:51 +0000 (UTC)
(envelope-from wblock@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org
[IPv6:2001:1900:2254:2068::e6a:0])
by mx1.freebsd.org (Postfix) with ESMTP id 2AF9C1BE5;
Sun, 30 Jun 2013 01:00:51 +0000 (UTC)
Received: from svn.freebsd.org ([127.0.1.70])
by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5U10p1Z081624;
Sun, 30 Jun 2013 01:00:51 GMT (envelope-from wblock@svn.freebsd.org)
Received: (from wblock@localhost)
by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5U10pVY081623;
Sun, 30 Jun 2013 01:00:51 GMT (envelope-from wblock@svn.freebsd.org)
Message-Id: <201306300100.r5U10pVY081623@svn.freebsd.org>
From: Warren Block
Date: Sun, 30 Jun 2013 01:00:51 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
Subject: svn commit: r42087 - head/en_US.ISO8859-1/articles/committers-guide
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: svn-doc-all@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "SVN commit messages for the entire doc trees \(except for "
user" , " projects" , and " translations"
\)"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Jun 2013 01:00:51 -0000
Author: wblock
Date: Sun Jun 30 01:00:50 2013
New Revision: 42087
URL: http://svnweb.freebsd.org/changeset/doc/42087
Log:
Whitespace-only changes. Translators, please ignore.
Modified:
head/en_US.ISO8859-1/articles/committers-guide/article.xml
Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml Sat Jun 29 22:59:48 2013 (r42086)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Sun Jun 30 01:00:50 2013 (r42087)
@@ -83,16 +83,15 @@
src/ Subversion
Root
-
- svn+ssh://svn+ssh://svn.FreeBSD.org/base
(see also ).
+
doc/ Subversion
Root
-
- svn+ssh://svn+ssh://svn.FreeBSD.org/doc
(see also ).
@@ -100,8 +99,7 @@
ports/ Subversion
Root
-
- svn+ssh://svn+ssh://svn.FreeBSD.org/ports
(see also ).
@@ -128,8 +126,7 @@
reports
/home/core/public/monthly-reports
on the FreeBSD.org
- cluster.
-
+ cluster.
@@ -147,32 +144,35 @@
stable/8 (8.X-STABLE),
stable/9 (9.X-STABLE),
- head (-CURRENT)
-
+ head (-CURRENT)
- It is required that you use &man.ssh.1;
- to connect to the project hosts.
- If you do
- not know anything about &man.ssh.1;, please see
- .
+ It is required that you use &man.ssh.1; to connect to the
+ project hosts. If you do not know anything about &man.ssh.1;,
+ please see .Useful links:
- FreeBSD
- Project Internal Pages
+
+ FreeBSD
+ Project Internal Pages
+
-
+ FreeBSD Project
- Hosts
+ Hosts
+
-
+ FreeBSD Project
- Administrative Groups
+ Administrative Groups
+
@@ -238,7 +238,7 @@
Policy for doc/ Committer Activity
- in src/
+ in src/doc committers may commit documentation
@@ -274,13 +274,13 @@
operation of the version control systems in use. Traditionally
this was CVS. Subversion is used for the src
tree as of May 2008, the doc/www tree as of
- May 2012 and the ports tree as of July 2012.
-
+ May 2012 and the ports tree as of July
+ 2012.
There
- is a list of things missing in Subversion when compared to CVS
- . The notes at
+ is a list of things missing in Subversion when compared to
+ CVS. The notes at
might also be useful.
@@ -489,26 +489,29 @@
- /head/
- which corresponds to HEAD, also known as
- -CURRENT.
-
+ /head/ which corresponds to
+ HEAD, also known as
+ -CURRENT.
+
/stable/n
which corresponds to
RELENG_n.
+
/releng/n.n
which corresponds to
RELENG_n_n.
+
/release/n.n.n
which corresponds to
RELENG_n_n_n_RELEASE.
+
/vendor* is the vendor branch
import work area. This directory itself does not
@@ -532,8 +535,8 @@
Layout
In svn+ssh://svn.freebsd.org/doc,
- doc refers to the repository root of the
- source tree.
+ doc refers to the repository root of
+ the source tree.In general, most &os; Documentation Project work will be
done within the head/ branch of the
@@ -580,17 +583,20 @@
- /branches/RELENG_n_n_n
- which corresponds to
- RELENG_n_n_n
+ /branches/RELENG_n_n_n
+ which corresponds to
+ RELENG_n_n_n
is used to merge back security updates in preparation
for a release.
+
/tags/RELEASE_n_n_n
- which corresponds to RELEASE_n_n_n
+ which corresponds to
+ RELEASE_n_n_n
represents a release tag of the ports tree.
+
/tags/RELEASE_n_EOL
represents the end of life tag of a specific &os;
@@ -615,9 +621,9 @@
&prompt.user; svn help
- Additional information can be found in the
- Subversion Book.
+ Additional information can be found in the
+ Subversion
+ Book.
@@ -717,7 +723,8 @@
&prompt.user; svn status
- To show local changes and files that are out-of-date do:
+ To show local changes and files that are out-of-date
+ do:&prompt.user; svn status --show-updates
@@ -766,9 +773,8 @@
svn rm --keep-local for just added
files, fix your config file and re-add them again. The
initial config file is created when you first run a svn
- command, even something as simple as svn
- help.
-
+ command, even something as simple as
+ svn help.Files are added to a
@@ -1079,21 +1085,23 @@
- If branch/foo/bar/ does not
- already have a mergeinfo record, but a direct ancestor
- (for instance, branch/foo/) does,
- then that record will be propagated down to
+ If
+ branch/foo/bar/
+ does not already have a mergeinfo record, but a direct
+ ancestor (for instance,
+ branch/foo/)
+ does, then that record will be propagated down to
branch/foo/bar/
- before information
- about the current merge is recorded.
+ before information about the current merge is
+ recorded.
+
Information about the current merge will
not be propagated back up that
ancestor.
+
If a direct descendant of branch/foo/bar/ (for
@@ -1132,13 +1140,16 @@
Never merge directly to a file.
+
Never, ever merge directly to a file.
+
Never, ever, ever merge
directly to a file.
+
Changes to kernel code should be merged to
sys/. For
@@ -1151,12 +1162,14 @@
not sys/netinet/.
+
Changes to code under etc/ should be merged
at etc/, not
below it.
+
Changes to vendor code (code in contrib/,
+
Changes to userland programs should as a general
rule be merged to the directory that contains the
@@ -1178,6 +1192,7 @@
should be merged to usr.bin/xlint/.
+
Changes to userland libraries should as a general
rule be merged to the directory that contains the
@@ -1186,6 +1201,7 @@
should be merged to lib/libc/.
+
There may be cases where it makes sense to deviate
from the rules for userland programs and libraries.
@@ -1195,12 +1211,15 @@
even though the library itself and all of the modules
each have their own Makefile.
+
- Changes to manual pages should be merged to Changes to manual pages should be merged to
+ share/man/manN/,
for the appropriate value of
N.
+
Other changes to share/ should be merged
@@ -1208,6 +1227,7 @@
share/
directly.
+
Changes to a top-level file in the source tree
such as UPDATING or
@@ -1216,6 +1236,7 @@
whole tree. Yes, this is an exception to the first
three rules.
+
When in doubt, ask.
@@ -1332,21 +1353,26 @@ $target - head/$source:$P,$Q,$R
Practical Example
- As a practical example, consider the following scenario:
- The changes to netmap.4 in r238987 is
- to be merged from CURRENT to 9-STABLE. The file resides in
- head/share/man/man4 and
- according to this
- is also where to do the merge. Note that in this example
- all paths are relative to the top of the svn repository.
- for more information on the directory layout, see
+
+ As a practical example, consider the following
+ scenario: The changes to netmap.4
+ in r238987 is to be merged from CURRENT to 9-STABLE.
+ The file resides in head/share/man/man4 and
+ according to
+ this is also where to do the merge. Note that in this
+ example all paths are relative to the top of the svn
+ repository. for more information on the directory
+ layout, see
.
- The first step is to inspect the existing mergeinfo.
+
+ The first step is to inspect the existing
+ mergeinfo.&prompt.user; svn propget svn:mergeinfo -R stable/9/share/man/man4
- Take a quick note of how it looks before moving on to the next
- step; doing the actual merge:
+ Take a quick note of how it looks before moving on
+ to the next step; doing the actual merge:&prompt.user; svn merge -c r238987 svn+ssh://svn.freebsd.org/base/head/share/man/man4 stable/9/share/man/man4
--- Merging r238987 into 'stable/9/share/man/man4':
@@ -1355,11 +1381,11 @@ U stable/9/share/man/man4/netmap.4
'stable/9/share/man/man4':
U stable/9/share/man/man4
- Check that the revision number of the merged revision
- has been added. Once this is verified, the only thing left
- is the actual commit.
-
- &prompt.user; svn commit stable/9/share/man/man4
+ Check that the revision number of the merged
+ revision has been added. Once this is verified, the
+ only thing left is the actual commit.
+
+ &prompt.user; svn commit stable/9/share/man/man4
@@ -1419,24 +1445,26 @@ U stable/9/share/man/man4/netmap.4
Vendor Imports with SVN
- Please read this entire section before starting a vendor
- import.
+ Please read this entire section before starting a
+ vendor import.
- Patches to vendor code fall into two categories:
+ Patches to vendor code fall into two
+ categories:Vendor patches: these are patches that have been
- issued by the vendor, or that have been extracted from
- the vendor's version control system, which address
- issues which in your opinion cannot wait until the next
- vendor release.
+ issued by the vendor, or that have been extracted from
+ the vendor's version control system, which address
+ issues which in your opinion cannot wait until the
+ next vendor release.
+
&os; patches: these are patches that modify the
- vendor code to address &os;-specific issues.
+ vendor code to address &os;-specific issues.
@@ -1446,17 +1474,18 @@ U stable/9/share/man/man4/netmap.4
Vendor patches should be committed to the vendor
- branch, and merged from there to head. If the patch
- addresses an issue in a new release that is currently
- being imported, it must not be
- committed along with the new release: the release must
- be imported and tagged first, then the patch can be
- applied and committed. There is no need to re-tag the
- vendor sources after committing the patch.
+ branch, and merged from there to head. If the patch
+ addresses an issue in a new release that is currently
+ being imported, it must not be
+ committed along with the new release: the release must
+ be imported and tagged first, then the patch can be
+ applied and committed. There is no need to re-tag the
+ vendor sources after committing the patch.
+
&os; patches should be committed directly to
- head.
+ head.
@@ -1509,22 +1538,22 @@ U stable/9/share/man/man4/netmap.4
as necessary. Disabling keyword expansion is
recommended, as it makes no sense on unmodified vendor
code and in some cases it can even be harmful.
- OpenSSH, for example, includes
- two files that originated with &os; and still contain the
- original version tags. To do this:
+ OpenSSH, for example,
+ includes two files that originated with &os; and still
+ contain the original version tags. To do this:
&prompt.user; svn propdel svn:keywords -R .
&prompt.root; svn commit
+
Bootstrapping Merge HistoryIf importing for the first time after the switch to
- Subversion, bootstrap
- svn:mergeinfo on the target directory
- in the main tree to the revision that corresponds
- to the last related change to the vendor tree, prior to
- importing new sources:
+ Subversion, bootstrap svn:mergeinfo
+ on the target directory in the main tree to the revision
+ that corresponds to the last related change to the
+ vendor tree, prior to importing new sources:
&prompt.user; cd head/contrib/pf
&prompt.user; svn merge --record-only svn+ssh://svn.freebsd.org/base/vendor/pf/dist@180876 .
@@ -1543,11 +1572,11 @@ U stable/9/share/man/man4/netmap.4
Preparing the Vendor Sources
- Unlike in CVS where only the needed
- parts were imported into the vendor tree to avoid bloating
- the main tree, Subversion is able to store a full
- distribution in the vendor tree. So, import everything,
- but merge only what is required.
+ Unlike in CVS where only the
+ needed parts were imported into the vendor tree to avoid
+ bloating the main tree, Subversion is able to store a
+ full distribution in the vendor tree. So, import
+ everything, but merge only what is required.A svn add is required to add any
files that were added since the last vendor import, and
@@ -1563,12 +1592,13 @@ U stable/9/share/man/man4/netmap.4
&prompt.user; find . -type f | cut -c 3- | sort >../newWith these two files,
- comm -23 ../old ../new
- will list removed files (files only in
- old), while
- comm -13 ../old ../new
- will list added files only in new.
+ comm -23 ../old ../new will list
+ removed files (files only in old),
+ while comm -13 ../old ../new will
+ list added files only in
+ new.
+
Importing into the Vendor Tree
@@ -1584,17 +1614,18 @@ U stable/9/share/man/man4/netmap.4
&prompt.user; comm -23 ../old ../new | xargs svn rm
&prompt.user; comm -13 ../old ../new | xargs svn --parents add
- If any directories were removed, they will have to be
- svn rmed manually. Nothing will break
- if they are not, but they will remain in the tree.
+ If any directories were removed, they will have to
+ be svn rmed manually. Nothing will
+ break if they are not, but they will remain in the
+ tree.
- Check properties on any new files. All text files
+ Check properties on any new files. All text files
should have svn:eol-style set to
native. All binary files should have
svn:mime-type set to
application/octet-stream unless there
- is a more appropriate media type. Executable files should
- have svn:executable set to
+ is a more appropriate media type. Executable files
+ should have svn:executable set to
*. No other properties should exist
on any file in the tree.
@@ -1619,13 +1650,15 @@ U stable/9/share/man/man4/netmap.4
needed.If creating the tag in the working copy of the tree,
- svn:mergeinfo results must be removed:
+ svn:mergeinfo results must be
+ removed:
&prompt.user; cd vendor/pf
&prompt.user; svn cp dist 4.3
&prompt.user; svn propdel svn:mergeinfo -R 4.3
+
Merging to Head
@@ -1634,8 +1667,8 @@ U stable/9/share/man/man4/netmap.4
&prompt.user; svn merge --accept=postpone svn+ssh://svn.freebsd.org/base/vendor/pf/dist .The --accept=postpone tells
- Subversion that it should not complain because merge conflicts
- will be taken care of manually.
+ Subversion that it should not complain because merge
+ conflicts will be taken care of manually.
It is necessary to resolve any merge conflicts.
This process is the same in SVN as in
@@ -1643,7 +1676,8 @@ U stable/9/share/man/man4/netmap.4
Make sure that any files that were added or removed in
the vendor tree have been properly added or removed in the
- main tree. To check diffs against the vendor branch:
+ main tree. To check diffs against the vendor
+ branch:&prompt.user; svn diff --no-diff-deleted --old=svn+ssh://svn.freebsd.org/base/vendor/pf/dist --new=.
@@ -1659,13 +1693,15 @@ U stable/9/share/man/man4/netmap.4
Subversion, there is no concept of on or off the vendor
branch. If a file that previously had local
modifications, to make it not show up in diffs in the
- vendor tree, all that has to be done is remove any left-over
- cruft like &os; version tags, which is much easier.
+ vendor tree, all that has to be done is remove any
+ left-over cruft like &os; version tags, which is much
+ easier.
If any changes are required for the world to build
with the new sources, make them now, and keep testing
until everything builds and runs perfectly.
+
Committing the Vendor Import
@@ -1694,11 +1730,11 @@ U stable/9/share/man/man4/netmap.4
&prompt.user; svn mkdir byacc/distNow, import the sources into the
- dist directory. Once
- the files are in place, svn add the new
- ones, then svn commit and tag the
- imported version. To save time and bandwidth, direct remote
- committing and tagging is possible:
+ dist directory.
+ Once the files are in place, svn add
+ the new ones, then svn commit and tag
+ the imported version. To save time and bandwidth,
+ direct remote committing and tagging is possible:
&prompt.user; svn cp -m "Tag byacc 20120115"$FSVN/vendor/byacc/dist$FSVN/vendor/byacc/20120115
@@ -1715,9 +1751,9 @@ U stable/9/share/man/man4/netmap.4
possible.
-
+
-
+ Reverting a CommitReverting a commit to a previous version is fairly
@@ -1906,8 +1942,8 @@ U stable/9/share/man/man4/netmap.4
Do not remove and re-add the same file in a single commit
as this will break the CVS exporter.
- Speeding up svn is
- possible by adding the following to ~/.ssh/config:
+ Speeding up svn is possible by adding the following to
+ ~/.ssh/config:Host *
ControlPath ~/.ssh/sockets/master-%l-%r@%h:%p
@@ -1919,10 +1955,10 @@ ControlPersist yesChecking out a working copy with a stock Subversion client
without &os;-specific patches
- (OPTIONS_SET=FREEBSD_TEMPLATE) will mean that
- $FreeBSD$ tags will not be
- expanded. Once the correct version has been installed, trick
- Subversion into expanding them like so:
+ (OPTIONS_SET=FREEBSD_TEMPLATE) will mean
+ that $FreeBSD$ tags will not
+ be expanded. Once the correct version has been installed,
+ trick Subversion into expanding them like so:&prompt.user; svn propdel -R svn:keywords .
&prompt.user; svn revert -R .
@@ -1934,10 +1970,10 @@ ControlPersist yes
Conventions and Traditions
- As a new developer there are a number of things you should do
- first. The first set is specific to committers only. (If you are
- not a committer, e.g., have GNATS-only access, then your mentor needs
- to do these things for you.)
+ As a new developer there are a number of things you should
+ do first. The first set is specific to committers only. (If
+ you are not a committer, e.g., have GNATS-only access, then your
+ mentor needs to do these things for you.)Guidelines for Committers
@@ -1952,130 +1988,139 @@ ControlPersist yes
If you have been given commit rights to one or more of the
repositories:
-
-
- Add your author entity to
- head/share/xml/authors.ent;
- this should be done first since an omission of this commit will
- cause the next commits to break the doc/ build.
-
- This is a relatively easy task, but remains a good first test of
- your version control skills.
-
-
- New files that do not have the
- FreeBSD=%Hsvn:keywords
- property will be rejected when attempting to commit them to the
- repository. Be sure to read
- regarding adding and removing files, in addition
- to verifying that ~/.subversion/config
- contains the necessary "auto-props"
- entries from auto-props.txt mentioned
- there.
-
-
-
- Do not forget to get mentor approval for these patches!
-
-
-
-
-
- Also add your author entity to
- head/share/xml/developers.ent.
-
-
-
- Add yourself to the Developers section of
- the Contributors List
- (head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml) and remove yourself from the Additional
- Contributors section (head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml).
- Please note that entries are sorted by last name.
-
+
+
+ Add your author entity to
+ head/share/xml/authors.ent; this
+ should be done first since an omission of this commit will
+ cause the next commits to break the doc/ build.
+
+ This is a relatively easy task, but remains a good
+ first test of your version control skills.
+
+
+ New files that do not have the
+ FreeBSD=%H
+ svn:keywords property will be
+ rejected when attempting to commit them to the
+ repository. Be sure to read
+ regarding
+ adding and removing files, in addition to verifying that
+ ~/.subversion/config contains the
+ necessary "auto-props" entries from
+ auto-props.txt mentioned
+ there.
+
+
+
+ Do not forget to get mentor approval for these
+ patches!
+
+
-
- Add an entry for yourself to
- head/share/xml/news.xml. Look for the other
- entries that look like A new committer and follow the
- format.
-
+
+ Also add your author entity to
+ head/share/xml/developers.ent.
+
-
- You should add your PGP or GnuPG key to
- head/share/pgpkeys (and if you do not
- have a key, you should create one). Do not forget to commit
- the updated head/share/pgpkeys/pgpkeys.ent
- and head/share/pgpkeys/pgpkeys-developers.xml.
- Please note that entries are sorted by last name.
+
+ Add yourself to the Developers section
+ of the Contributors
+ List
+ (head/en_US.ISO8859-1/articles/contributors/contrib.committers.xml)
+ and remove yourself from the
+ Additional Contributors section
+ (head/en_US.ISO8859-1/articles/contributors/contrib.additional.xml).
+ Please note that entries are sorted by last name.
+
- &a.des; has
- written a shell script (head/share/pgpkeys/addkey.sh) to make this extremely simple. See the
- README
- file for more information.
+
+ Add an entry for yourself to
+ head/share/xml/news.xml. Look for
+ the other entries that look like
+ A new committer and follow the
+ format.
+
-
- It is important to have an up-to-date PGP/GnuPG key in
- the Handbook, since the key may be required for positive
- identification of a committer, e.g., by the &a.admins; for
- account recovery. A complete keyring of FreeBSD.org users is available
- for download from http://www.FreeBSD.org/doc/pgpkeyring.txt.
-
-
+
+ You should add your PGP or GnuPG key to
+ head/share/pgpkeys (and if you do not
+ have a key, you should create one). Do not forget to
+ commit the updated
+ head/share/pgpkeys/pgpkeys.ent and
+ head/share/pgpkeys/pgpkeys-developers.xml.
+ Please note that entries are sorted by last name.
+
+ &a.des; has written a shell script
+ (head/share/pgpkeys/addkey.sh) to
+ make this extremely simple. See the README
+ file for more information.
+
+
+ It is important to have an up-to-date PGP/GnuPG key
+ in the Handbook, since the key may be required for
+ positive identification of a committer, e.g., by the
+ &a.admins; for account recovery. A complete keyring of
+ FreeBSD.org users is
+ available for download from http://www.FreeBSD.org/doc/pgpkeyring.txt.
+
+
-
- Add an entry for yourself to
- src/share/misc/committers-repository.dot,
- where repository is either doc, ports or src, depending on the commit privileges
- you obtained.
-
+
+ Add an entry for yourself to
+ src/share/misc/committers-repository.dot,
+ where repository is either doc, ports or src, depending on
+ the commit privileges you obtained.
+
-
- Some people add an entry for themselves to
- ports/astro/xearth/files/freebsd.committers.markers.
-
+
+ Some people add an entry for themselves to
+ ports/astro/xearth/files/freebsd.committers.markers.
+
-
- Some people add an entry for themselves to
- src/usr.bin/calendar/calendars/calendar.freebsd.
-
+
+ Some people add an entry for themselves to
+ src/usr.bin/calendar/calendars/calendar.freebsd.
+
-
- If you already have an account at the &os; wiki,
- make sure your mentor moves you from the
- Contributors group
- to the
- Developers group.
- Otherwise, consider signing up for an account so you can publish
- projects and ideas you are working on.
-
+
+ If you already have an account at the
+ &os; wiki,
+ make sure your mentor moves you from the Contributors
+ group to the Developers
+ group. Otherwise, consider signing up for an
+ account so you can publish projects and ideas you are
+ working on.
+
-
- Once you get access to the wiki, you may
- add yourself to the How We Got
- Here and Irc Nicks
- pages.
-
+
+ Once you get access to the wiki, you may add yourself
+ to the
+ How We
+ Got Here and
+ Irc
+ Nicks pages.
+
-
- If you subscribe to &a.svn-src-all.name;,
- &a.svn-ports-all.name; or &a.svn-doc-all.name;,
- you will probably want to unsubscribe to avoid receiving duplicate
- copies of commit messages and their followups.
-
-
+
+ If you subscribe to &a.svn-src-all.name;,
+ &a.svn-ports-all.name; or &a.svn-doc-all.name;, you will
+ probably want to unsubscribe to avoid receiving duplicate
+ copies of commit messages and their followups.
+
+
-
- All src commits should go to
- &os.current; first before being merged to &os.stable;. No major
- new features or high-risk modifications should be made to the
- &os.stable; branch.
-
+
+ All src commits should go to
+ &os.current; first before being merged to &os.stable;. No
+ major new features or high-risk modifications should be made
+ to the &os.stable; branch.
+
@@ -2083,69 +2128,72 @@ ControlPersist yes
Whether or not you have commit rights:
-
-
- Introduce yourself to the other developers, otherwise no one
- 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
- will be). Email this to the &a.developers; and you will
- be on your way!
-
+
+
+ Introduce yourself to the other developers, otherwise
+ no one 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 will
+ be). Email this to the &a.developers; and you will be on
+ your way!
+
-
- Log into hub.FreeBSD.org and create a
- /var/forward/user
- (where user is your username) file
- containing the e-mail address where you want mail addressed to
- yourusername@FreeBSD.org to be forwarded.
- This includes all of the commit messages as well as any other mail
- addressed to the &a.committers; and the &a.developers;. Really
- large mailboxes which have taken up permanent residence on
- hub often get accidentally truncated
- without warning, so forward it or read it and you will not lose
- it.
-
- Due to the severe load dealing with SPAM places on
- the central mail servers that do the mailing list processing
- the front-end server does do some basic checks and will
- drop some messages based on these checks. At the moment
- proper DNS information for the connecting host is the only
- 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
- .spam_lover in your home directory
- on freefall.FreeBSD.org to
- disable the checks for your email.
-
-
+
+ Log into hub.FreeBSD.org and create a
+ /var/forward/user
+ (where user is your username)
+ file containing the e-mail address where you want mail
+ addressed to
+ yourusername@FreeBSD.org to be
+ forwarded. This includes all of the commit messages as
+ well as any other mail addressed to the &a.committers; and
+ the &a.developers;. Really large mailboxes which have
+ taken up permanent residence on hub often
+ get accidentally truncated without warning,
+ so forward it or read it and you will not lose it.
+
+ Due to the severe load dealing with SPAM places on the
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
From owner-svn-doc-all@FreeBSD.ORG Sun Jun 30 01:37:37 2013
Return-Path:
Delivered-To: svn-doc-all@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
by hub.freebsd.org (Postfix) with ESMTP id AA804FBB;
Sun, 30 Jun 2013 01:37:37 +0000 (UTC)
(envelope-from wblock@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org
[IPv6:2001:1900:2254:2068::e6a:0])
by mx1.freebsd.org (Postfix) with ESMTP id 8CB621CC5;
Sun, 30 Jun 2013 01:37:37 +0000 (UTC)
Received: from svn.freebsd.org ([127.0.1.70])
by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5U1bbQn091552;
Sun, 30 Jun 2013 01:37:37 GMT (envelope-from wblock@svn.freebsd.org)
Received: (from wblock@localhost)
by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5U1bbqA091551;
Sun, 30 Jun 2013 01:37:37 GMT (envelope-from wblock@svn.freebsd.org)
Message-Id: <201306300137.r5U1bbqA091551@svn.freebsd.org>
From: Warren Block
Date: Sun, 30 Jun 2013 01:37:37 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
Subject: svn commit: r42088 - head/en_US.ISO8859-1/articles/committers-guide
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: svn-doc-all@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "SVN commit messages for the entire doc trees \(except for "
user" , " projects" , and " translations"
\)"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Jun 2013 01:37:37 -0000
Author: wblock
Date: Sun Jun 30 01:37:37 2013
New Revision: 42088
URL: http://svnweb.freebsd.org/changeset/doc/42088
Log:
Additional whitespace-only fixes. Translators, please ignore.
Modified:
head/en_US.ISO8859-1/articles/committers-guide/article.xml
Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml Sun Jun 30 01:00:50 2013 (r42087)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Sun Jun 30 01:37:37 2013 (r42088)
@@ -140,7 +140,6 @@
Noteworthy src/ SVN
Branches
-
stable/8 (8.X-STABLE),
stable/9 (9.X-STABLE),
@@ -241,30 +240,36 @@
in src/
- doc committers may commit documentation
- changes to src files, such as man pages, READMEs, fortune
- databases, calendar files, and comment fixes without
- approval from a src committer, subject to the normal care
- and tending of commits.
-
- doc committers may commit minor src changes
- and fixes, such as build fixes, small features, etc, with an
- "Approved by" from a src committer.
-
- doc committers may seek an upgrade to a src
- commit bit by acquiring a mentor, who will propose the doc
- committer to core. When approved, they will be added to
- 'access' and the normal mentoring period will ensue, which
- will involve a continuing of Approved by for
- some period.
-
- "Approved by" is only acceptable from
- non-mentored src committers -- mentored committers can
- provide a "Reviewed by" but not an "Approved
- by".
+
+ doc committers may commit documentation changes to src
+ files, such as man pages, READMEs, fortune databases,
+ calendar files, and comment fixes without approval from a
+ src committer, subject to the normal care and tending of
+ commits.
+
+
+
+ doc committers may commit minor src changes and fixes,
+ such as build fixes, small features, etc, with an
+ "Approved by" from a src committer.
+
+
+
+ doc committers may seek an upgrade to a src commit bit
+ by acquiring a mentor, who will propose the doc committer
+ to core. When approved, they will be added to 'access'
+ and the normal mentoring period will ensue, which will
+ involve a continuing of Approved by for
+ some period.
+
+
+
+ "Approved by" is only acceptable from non-mentored src
+ committers -- mentored committers can provide a "Reviewed
+ by" but not an "Approved by".
+
-
@@ -336,30 +341,37 @@
Commits are atomic.
+
Revision numbers apply across the repository—all
files that were modified in the same commit have the same
revision number.
+
Branching and tagging are namespace operations.
+
Directories are versioned.
+
Files and directories can have arbitrary, versioned
metadata attached to them.
+
Files and directories can be copied, with full history
tracking.
+
No more contortions due to CVS
weakness such as applying &man.patch.1; files at compile
time in order to avoid touching vendor branch code.
+
No more repo-copies.
@@ -520,6 +532,7 @@
releng and
release directories.
+
/projects and
/user feature a branch work area,
@@ -557,11 +570,13 @@
code for articles written by various &os;
contributors.
+
/books/ contains the source
code for the different books, such as the
&os; Handbook.
+
/htdocs/ contains the source
code for the &os; website.
@@ -909,18 +924,21 @@
working directory (which one presumes has been edited to
resolve the conflicts).
+
base: use a pristine copy of the
version you had before svn update,
discarding your own changes, the conflicting changes,
and possibly other intervening changes as well.
+
mine-full: use what you had
before svn update, including your own
changes, but discarding the conflicting changes, and
possibly other intervening changes as well.
+
theirs-full: use the version that
was retrieved when you did svn
@@ -961,10 +979,12 @@
empty: the directory itself
without any of its contents.
+
files: the directory and any
files it contains.
+
immediates: the directory and any
files and directories it contains, but none of the
@@ -1013,18 +1033,22 @@
log,
diff
+
mkdir
+
remove, copy,
rename
+
propset,
propedit,
propdel
+
merge
@@ -1311,13 +1335,16 @@
revision $R
+
in directory $target in stable branch
$B
+
from directory $source in head
+
$FSVN is
svn+ssh://svn.freebsd.org/base
@@ -1531,6 +1558,7 @@ U stable/9/share/man/man4/netmap.4
similar, and putting the svn commit
off until the end of the process.
+
Cleaning Up
@@ -1634,6 +1662,7 @@ U stable/9/share/man/man4/netmap.4
svn stat and
svn diff commands.
+
Tagging
@@ -1858,9 +1887,9 @@ U stable/9/share/man/man4/netmap.4
The seed mirror is set to fetch from
svn://svn.freebsd.org/base. The
- configuration for the mirror is stored in revprop
- 0 on the local mirror. To see the
- configuration, try:
+ configuration for the mirror is stored in
+ revprop 0 on the local mirror. To see
+ the configuration, try:
&prompt.user; svn proplist -v --revprop -r 0 file:///home/svnmirror/base
@@ -1929,6 +1958,7 @@ U stable/9/share/man/man4/netmap.4
To collapse everything back at the end:&prompt.user; svn write me
+
-->
@@ -1950,8 +1980,9 @@ ControlPath ~/.ssh/sockets/master-%l-%r@
ControlMaster auto
ControlPersist yes
- and then typing
- mkdir ~/.ssh/sockets
+ and then typing
+
+ mkdir ~/.ssh/socketsChecking out a working copy with a stock Subversion client
without &os;-specific patches
From owner-svn-doc-all@FreeBSD.ORG Sun Jun 30 01:52:07 2013
Return-Path:
Delivered-To: svn-doc-all@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
by hub.freebsd.org (Postfix) with ESMTP id 663D7127;
Sun, 30 Jun 2013 01:52:07 +0000 (UTC)
(envelope-from wblock@FreeBSD.org)
Received: from svn.freebsd.org (svn.freebsd.org
[IPv6:2001:1900:2254:2068::e6a:0])
by mx1.freebsd.org (Postfix) with ESMTP id 48DDE1D0A;
Sun, 30 Jun 2013 01:52:07 +0000 (UTC)
Received: from svn.freebsd.org ([127.0.1.70])
by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5U1q7rV096551;
Sun, 30 Jun 2013 01:52:07 GMT (envelope-from wblock@svn.freebsd.org)
Received: (from wblock@localhost)
by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5U1q7sC096550;
Sun, 30 Jun 2013 01:52:07 GMT (envelope-from wblock@svn.freebsd.org)
Message-Id: <201306300152.r5U1q7sC096550@svn.freebsd.org>
From: Warren Block
Date: Sun, 30 Jun 2013 01:52:07 +0000 (UTC)
To: doc-committers@freebsd.org, svn-doc-all@freebsd.org,
svn-doc-head@freebsd.org
Subject: svn commit: r42089 - head/en_US.ISO8859-1/articles/committers-guide
X-SVN-Group: doc-head
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-BeenThere: svn-doc-all@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: "SVN commit messages for the entire doc trees \(except for "
user" , " projects" , and " translations"
\)"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 30 Jun 2013 01:52:07 -0000
Author: wblock
Date: Sun Jun 30 01:52:06 2013
New Revision: 42089
URL: http://svnweb.freebsd.org/changeset/doc/42089
Log:
Content updates: replace FreeBSD with &os; where appropriate, rewrite a
stilted paragraph on SSH.
Modified:
head/en_US.ISO8859-1/articles/committers-guide/article.xml
Modified: head/en_US.ISO8859-1/articles/committers-guide/article.xml
==============================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml Sun Jun 30 01:37:37 2013 (r42088)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Sun Jun 30 01:52:06 2013 (r42089)
@@ -26,7 +26,7 @@
201120122013
- The FreeBSD Documentation Project
+ The &os; Documentation Project
@@ -43,12 +43,12 @@
$FreeBSD$
- This document provides information for the FreeBSD
+ 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.
- Almost all FreeBSD developers have commit rights to one or
+ Almost all &os; developers have commit 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
@@ -56,7 +56,7 @@
linkend="non-committers"/> for more information.This document may also be of interest to members of the
- FreeBSD community who want to learn more about how the project
+ &os; community who want to learn more about how the project
works.
@@ -149,27 +149,26 @@
- It is required that you use &man.ssh.1; to connect to the
- project hosts. If you do not know anything about &man.ssh.1;,
- please see .
+ &man.ssh.1; is required to connect to the projecte hosts.
+ For more information, see .Useful links:
- FreeBSD
+ &os;
Project Internal PagesFreeBSD Project
+ url="&url.base;/internal/machines.html">&os; Project
HostsFreeBSD Project
+ url="&url.base;/administration.html">&os; Project
Administrative Groups
@@ -178,10 +177,10 @@
Commit Bit Types
- The FreeBSD repository has a number of components which,
+ The &os; 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
@@ -1389,7 +1388,7 @@ $target - head/$source:$P,$Q,$R
according to
this is also where to do the merge. Note that in this
example all paths are relative to the top of the svn
- repository. for more information on the directory
+ repository. For more information on the directory
layout, see
.
@@ -2166,7 +2165,7 @@ ControlPersist yes
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 will
+ &os;. (You should also mention who your mentor will
be). Email this to the &a.developers; and you will be on
your way!
@@ -2334,7 +2333,7 @@ ControlPersist yes
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.
@@ -2358,7 +2357,7 @@ ControlPersist yes
GNATS
- The FreeBSD Project utilizes
+ The &os; Project utilizes
GNATS for tracking bugs and change
requests. Be sure that if you commit a fix or suggestion found
in a GNATS PR, you use
@@ -2376,7 +2375,7 @@ ControlPersist yes
FreeBSD
+ url="&url.articles.pr-guidelines;/index.html">&os;
Problem Report Handling Guidelines
@@ -2396,7 +2395,7 @@ ControlPersist yes
You can run a local copy of GNATS, and then integrate the
- FreeBSD GNATS tree by creating an
+ &os; GNATS tree by creating an
rsync mirror. Then you can run GNATS
commands locally, allowing you to query the PR database without
an Internet connection.
@@ -2441,7 +2440,7 @@ ControlPersist yes
Who's Who
- Besides the repository meisters, there are other FreeBSD
+ Besides the repository 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:
@@ -2453,7 +2452,7 @@ ControlPersist yes
doceng is the group responsible for the documentation
build infrastructure, approving new documentation
- committers, and ensuring that the FreeBSD website and
+ committers, and 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
@@ -2485,7 +2484,7 @@ ControlPersist yes
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.
+ applicable to &os;.
@@ -2515,7 +2514,7 @@ ControlPersist yes
Dag-Erling is the
- FreeBSD Security
+ &os; Security
Officer and oversees the
&a.security-officer;.
@@ -2529,7 +2528,7 @@ ControlPersist yes
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.
+ standards applicable to &os;.
@@ -2556,14 +2555,14 @@ ControlPersist yes
community issues. Examples are Core
voting, announcements, etc.
- The &a.developers; is for the exclusive use of FreeBSD
- committers. In order to develop FreeBSD, committers must
+ The &a.developers; is for the exclusive use of &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.
+ publication and may harm &os;.
- All FreeBSD committers are reminded to obey the
+ 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
@@ -2576,13 +2575,13 @@ ControlPersist yes
This list is not intended as a
place for code reviews or a replacement for the &a.arch;.
- In fact using it as such hurts the FreeBSD Project as it
+ In fact using it as such hurts the &os; Project as it
gives a sense of a closed list where general decisions
- affecting all of the FreeBSD using community are made
+ affecting all of the &os; using community are made
without being open. Last, but not least
never, never ever, email the &a.developers; and
- CC:/BCC: another FreeBSD list. Never, ever
- email another FreeBSD email list and CC:/BCC: the
+ CC:/BCC: another &os; list. Never, ever
+ email another &os; email list and CC:/BCC: the
&a.developers;. Doing so can greatly diminish the
benefits of this list.
@@ -2713,7 +2712,7 @@ ControlPersist yes
- The FreeBSD Committers' Big List of Rules
+ The &os; Committers' Big List of Rules
@@ -2922,7 +2921,7 @@ ControlPersist yes
Respect existing maintainers if listed.
- Many parts of FreeBSD are not owned in
+ Many parts of &os; are not owned in
the sense that any specific individual will jump up and
yell if you commit a change to their area,
but it still pays to check first. One convention we use
@@ -2940,8 +2939,8 @@ ControlPersist yes
in question and see if someone has been working recently
or predominantly in that area.
- Other areas of FreeBSD fall under the control of
- someone who manages an overall category of FreeBSD
+ Other areas of &os; fall under the control of
+ someone who manages an overall category of &os;
evolution, such as internationalization or networking.
See http://www.FreeBSD.org/administration.html
@@ -3054,7 +3053,7 @@ ControlPersist yes
long absence 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
+ they get back from the &os; Happy Reeducation Camp we
run in Greenland.
@@ -3089,9 +3088,9 @@ ControlPersist yes
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 FreeBSD Internal
+ url="http://www.FreeBSD.org/internal/">&os; Internal
Page 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.
@@ -3118,7 +3117,7 @@ ControlPersist yes
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 maintainer; they may be
+ &os;-specific, talk to the maintainer; they may be
willing to apply them locally. But whatever you do, do
not commit there by yourself!
@@ -3131,10 +3130,10 @@ ControlPersist yes
Policy on Multiple Architectures
- FreeBSD has added several new architecture ports during
+ &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 across the platforms we support, core has
+ &os; portable across the platforms we support, core has
developed the following mandate:
@@ -3229,39 +3228,39 @@ ControlPersist yes
Support for Multiple Architectures
- FreeBSD is a highly portable operating system intended to
+ &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
+ supported by &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".
+ that are seen as the &os; target audience.Statement of General Intent
- The FreeBSD Project targets "production quality commercial
+ 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
+ architectures 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 offering new features and usage
+ &os; consumers by offering new features and usage
opportunities (such as support 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.
- The FreeBSD Project differentiates platform targets into
+ 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
@@ -3282,11 +3281,11 @@ ControlPersist yes
requirement). In general, all Tier 1 platforms must have
build 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
+ may substitute an emulator available in the &os; cluster
for actual hardware.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.Tier 1 architectures are expected to be completely
@@ -3327,20 +3326,20 @@ ControlPersist yes
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 have not been incorporated upstream.
+ &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 should be feasible to implement on these platforms,
+ &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
+ be added 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 tree as long as it does not interfere with
+ 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 source tree, the platform must be able to
+ 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.
@@ -3361,12 +3360,12 @@ ControlPersist yes
system, some external patches for the architecture for ports
must be available.
- Tier 2 architectures can be integrated into the FreeBSD
+ 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
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.Current Tier 2 platforms are &arch.arm;, &arch.ia64;,
@@ -3384,11 +3383,11 @@ ControlPersist yes
are considered legacy systems unlikely to see broad future
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.Tier 3 platforms may have ports support, either integrated
@@ -3397,7 +3396,7 @@ ControlPersist yes
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.
+ not be integrated into the &os; tree.Current Tier 3 platforms are &arch.mips; and
&s390;.
@@ -3417,7 +3416,7 @@ ControlPersist yes
Policy on Changing the Tier of an ArchitectureSystems 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.
@@ -3486,7 +3485,7 @@ ControlPersist yes
contributed to the Project before, add that person's
name to the Additional
- Contributors section of the FreeBSD
+ Contributors section of the &os;
Contributors List.
Thanks to all the reporters for the excellent work! This report
- contains 5 entries and we hope you enjoy reading it.
+ contains 6 entries and we hope you enjoy reading it.
The deadline for submissions covering between July and September 2013
@@ -26,6 +26,12 @@
+ team
+
+ &os; Team Reports
+
+
+ projProjects
@@ -247,4 +253,37 @@
allows to monitor and manage HAST via the SNMP protocol.