Index: en_US.ISO8859-1/articles/committers-guide/article.xml
===================================================================
--- en_US.ISO8859-1/articles/committers-guide/article.xml
+++ en_US.ISO8859-1/articles/committers-guide/article.xml
@@ -752,7 +752,7 @@
Help
SVN has built in help documentation.
- It can be accessed by typing the following command:
+ It can be accessed by typing:
&prompt.user; svn help
@@ -830,8 +830,7 @@
It is possible to anonymously check out the &os;
repository with Subversion. This will give access to a
read-only tree that can be updated, but not committed back
- to the main repository. To do this, use the following
- command:
+ to the main repository. To do this, use:
&prompt.user; svn co https://svn.FreeBSD.org/base/head /usr/src
@@ -1001,7 +1000,7 @@
&prompt.user; svn diff -r179453:179454 ROADMAP.txt
It can also show all changes for a specific changeset.
- The following will show what changes were made to the
+ This command will show what changes were made to the
current directory and all subdirectories in changeset
179454:
@@ -1024,8 +1023,7 @@
conflict, Subversion will remember which files have
conflicts and refuse to commit any changes to those files
until explicitly told that the conflicts have been resolved.
- The simple, not yet deprecated procedure is the
- following:
+ The simple, not yet deprecated procedure is:
&prompt.user; svn resolved foo
@@ -1121,7 +1119,7 @@
~/freebsd with
ROADMAP.txt and empty subdirectories,
and nothing will happen when svn update
- is executed on the subdirectories. However, the following
+ is executed on the subdirectories. However, this
command will set the depth for
head (in this case) to infinity,
and fully populate it:
@@ -1163,12 +1161,12 @@
- Branching is very fast. The following command would be
+ Branching is very fast. This command would be
used to branch RELENG_8:
&prompt.user; svn copy svn+ssh://repo.freebsd.org/base/head svn+ssh://repo.freebsd.org/base/stable/8
- This is equivalent to the following set of commands
+ This is equivalent to this set of commands
which take minutes and hours as opposed to seconds,
depending on your network connection:
@@ -1213,7 +1211,7 @@
Instead, mergeinfo is explicitly propagated down the tree.
For merging something into
branch/foo/bar/,
- the following rules apply:
+ these rules apply:
@@ -1260,18 +1258,18 @@
stable/10 and Newer
Starting with the stable/10
- branch, all merges should be
+ branch, all merges are
merged to and committed from the root of the
- branch. All merges should look like:
+ branch. All merges looks like:
&prompt.user; svn merge -c r123456 ^/head/ checkout
&prompt.user; svn commit checkout
- Note that checkout should
- be a complete checkout of the branch to which the merge
+ Note that checkout
+ is a complete checkout of the branch to which the merge
occurs.
- Merges to releng/ branches should
+ Merges to releng/ branches
always originate from the corresponding
stable/ branch. For example:
@@ -1288,7 +1286,7 @@
a complete checkout. This procedure proved extremely
error-prone, with the convenience of partial checkouts for
merges significantly outweighed by the complexity of
- picking mergeinfo targets. The below describes this
+ picking mergeinfo targets. The procedure below describes this
now-obsoleted procedure, which should be used
only for merges prior to
stable/10.
@@ -1299,7 +1297,7 @@
The rules for selecting the merge target (the
directory that you will merge the changes to) can be
- summarized as follows:
+ summarized:
@@ -1316,29 +1314,29 @@
- Changes to kernel code should be merged to
+ Changes to kernel code are merged to
sys/. For instance, a change to
- the &man.ichwd.4; driver should be merged to
+ the &man.ichwd.4; driver is merged to
sys/, not
sys/dev/ichwd/. Likewise, a
- change to the TCP/IP stack should be merged to
+ change to the TCP/IP stack is merged to
sys/, not
sys/netinet/.
Changes to code under etc/
- should be merged at etc/, not
+ is merged at etc/, not
below it.
Changes to vendor code (code in
contrib/,
- crypto/ and so on) should be
+ crypto/ and so on) are
merged to the directory where vendor imports happen.
For instance, a change to
- crypto/openssl/util/ should be
+ crypto/openssl/util/ is
merged to crypto/openssl/. This
is rarely an issue, however, since changes to vendor
code are usually merged wholesale.
@@ -1348,8 +1346,8 @@
Changes to userland programs should as a general
rule be merged to the directory that contains the
Makefile for that program. For instance, a change to
- usr.bin/xlint/arch/i386/ should
- be merged to
+ usr.bin/xlint/arch/i386/
+ is merged to
usr.bin/xlint/.
@@ -1372,7 +1370,7 @@
- Changes to manual pages should be merged to
+ Changes to manual pages are merged to
share/man/manN/,
for the appropriate value of
N.
@@ -1380,14 +1378,14 @@
Other changes to share/
- should be merged to the appropriate subdirectory and
+ are merged to the appropriate subdirectory and
not to share/ directly.
Changes to a top-level file in the source tree
such as UPDATING or
- Makefile.inc1 should be merged
+ Makefile.inc1 are merged
directly to that file rather than to the root of the
whole tree. Yes, this is an exception to the first
three rules.
@@ -1511,7 +1509,7 @@
Practical Example
- As a practical example, consider the following
+ As a practical example, consider this
scenario. The changes to netmap.4
in r238987 are to be merged from CURRENT to 9-STABLE.
The file resides in
@@ -1629,7 +1627,7 @@
- Vendor patches should be committed to the vendor
+ Vendor patches are 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
@@ -1640,7 +1638,7 @@
- &os; patches should be committed directly to
+ &os; patches are committed directly to
head.
@@ -1762,7 +1760,7 @@
Now, the sources must be copied into
dist and
the svn add and
- svn rm commands should be used as
+ svn rm commands are used as
needed:
&prompt.user; cd vendor/pf/pf-4.3
@@ -1783,7 +1781,7 @@
application/octet-stream unless there
is a more appropriate media type. Executable files
should have svn:executable set to
- *. No other properties should exist
+ *. No other properties can exist
on any file in the tree.
Committing is now possible, however it is good
@@ -1795,7 +1793,7 @@
Tagging
- Once committed, vendor releases should be tagged for
+ Once committed, vendor releases are tagged for
future reference. The best and quickest way to do this
is directly in the repository:
@@ -1825,8 +1823,8 @@
&prompt.user; svn merge --accept=postpone svn+ssh://repo.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 not to complain about merge
+ conflicts as will be taken care of manually.
The cvs2svn changeover occurred
@@ -1870,7 +1868,7 @@
The --no-diff-deleted tells
Subversion not to complain about files that are in the
- vendor tree but not in the main tree, i.e., things that
+ vendor tree but not in the main tree, that is, things that
would have previously been removed before the vendor
import, like for example the vendor's makefiles
and configure scripts.
@@ -1961,7 +1959,7 @@
It is important to ensure that the mergeinfo
- is correct when reverting a file in order to permit
+ is correct when reverting a file to permit
svn mergeinfo --eligible to work as
expected.
@@ -2024,7 +2022,7 @@
A far better option is to grab a seed file. It is large
(~1GB) but will consume less network traffic and take less
time to fetch than a svnsync will. This is possible in one
- of the following three ways:
+ of these three ways:
&prompt.user; rsync -va --partial --progress freefall:/home/peter/svnmirror-base-r179637.tbz2 .
@@ -2124,10 +2122,10 @@
Some Tips
- In commit logs etc., rev 179872
should be
+ In commit logs etc., rev 179872
is
spelled r179872
as per convention.
- Speeding up svn is possible by adding the following to
+ Speeding up svn is possible by adding to
~/.ssh/config:
Host *
@@ -2205,7 +2203,7 @@
- All src commits should go to
+ All src commits go to
&os.current; first before being merged to &os.stable;.
The &os.stable; branch must maintain
ABI and API
@@ -2584,7 +2582,7 @@
You want to commit a change based on a PR submitted by
John Smith containing a patch. The end of the commit message
- should look something like this.
+ looks something like this.
...
@@ -2680,7 +2678,7 @@
Preferred License for New Files
- Currently the &os; Project suggests and uses the following
+ Currently the &os; Project suggests and uses this
text as the preferred license scheme:
/*-
@@ -2820,8 +2818,8 @@
repository-committers
mailing list that you can really get a feel for just what is and
is not) then consider sending the change to them instead, just
- as you would have before becoming a committer. For ports, you
- should contact the listed MAINTAINER in the
+ as you would have before becoming a committer. For ports,
+ contact the listed MAINTAINER in the
Makefile. For other parts of the
repository, if you are unsure who the active maintainer might
be, it may help to scan the revision history to see who has
@@ -2852,7 +2850,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 &os;, but simply
+ destroy your hard work, personal image, or &os;, but basically
because they have a different outlook on the world. Different
is good.
@@ -2885,7 +2883,7 @@
person that knows the answer. This way everyone will be able to
learn from the question and the answer.
- For project specific or administrative questions you should
+ For project specific or administrative questions
ask, in order:
@@ -2898,7 +2896,7 @@
- Any team with a "hat", as they should give you a
+ Any team with a "hat", as they will give you a
definitive answer.
@@ -3051,8 +3049,8 @@
&a.svn-src-all.name;, &a.svn-ports-all.name; and
&a.svn-doc-all.name; are the mailing lists that the
version control system uses to send commit messages to.
- You should never send email directly
- to these lists. You should only send replies to this list
+ Never send email directly
+ to these lists. Only send replies to this list
when they are short and are directly related to a
commit.
@@ -3068,7 +3066,7 @@
voting, announcements, etc.
The &a.developers; is for the exclusive use of &os;
- committers. In order to develop &os;, committers must
+ committers. 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
@@ -3142,7 +3140,7 @@
- Now you should be able to use &man.ssh-add.1; for
+ Now you are able to use &man.ssh-add.1; for
authentication once per session. This will prompt you for
your private key's pass phrase, and then store it in your
authentication agent (&man.ssh-agent.1;). If you no longer
@@ -3267,7 +3265,7 @@
src/crypto, or
src/sys/contrib trees without
explicit approval from the respective
- maintainer(s).
+ maintainers.
@@ -3337,7 +3335,7 @@
are angry or otherwise behave in a manner which is likely
to strike others as needlessly confrontational. First
calm down, then think about how to communicate in the most
- effective fashion for convincing the other person(s) that
+ effective fashion for convincing the other persons that
your side of the argument is correct, do not just blow off
some steam so you can feel better in the short term at the
cost of a long-term flame war. Not only is this very bad
@@ -3382,14 +3380,14 @@
Discuss any significant change
before committing.
- The repository is not where changes should be
+ The repository is not where changes are
initially submitted for correctness or argued over, that
- should happen first in the mailing lists or by use of the
- Phabricator service and the commit should only happen once
+ happens first in the mailing lists or by use of the
+ Phabricator service and the commit will 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 develop a feel
+ misspelling, basically that you should try to develop a feel
for when a proposed change is not quite such a no-brainer
and requires some feedback first. People really do not
mind sweeping changes if the result is something clearly
@@ -3419,7 +3417,7 @@
maintainer need to be reviewed by at least one other
maintainer. In cases where the
maintainer-ship
of something is not clear,
- you can also look at the repository logs for the file(s)
+ you can also look at the repository logs for the files
in question and see if someone has been working recently
or predominantly in that area.
@@ -3501,8 +3499,8 @@
self-control, tempers are lost and angry words are
exchanged. The best thing that can be done in such cases
is to minimize the effects of this until everyone has
- cooled back down. That means that you should not air your
- angry words in public and you should not forward private
+ cooled back down. That means that you do not air your
+ angry words in public and you do not forward private
correspondence or other private communications to public
mailing lists, mail aliases, instant messaging channels or
social media sites. What people say one-to-one is often
@@ -3583,7 +3581,7 @@
src/crypto, and
src/sys/contrib trees without
explicit approval from the respective
- maintainer(s).
+ maintainers.
The trees mentioned above are for contributed software
usually imported onto a vendor branch. Committing
@@ -3597,7 +3595,7 @@
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
+ than welcome to do so. Ideally, submit your
patches to 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
@@ -3616,7 +3614,7 @@
recent release cycles and is truly no longer an &i386; centric
operating system. In an effort to make it easier to keep
&os; portable across the platforms we support, core has
- developed the following mandate:
+ developed this mandate:
Our 32-bit reference platform is &arch.i386;, and our
@@ -3679,7 +3677,7 @@
Deprecating Features
When it is necessary to remove functionality from software
- in the base system the following guidelines should be followed
+ in the base system, follow theses guidelines
whenever possible:
@@ -3737,7 +3735,7 @@
Where there are security problems that affect many
different operating systems, &os; frequently depends on
- early access in order to be able to prepare advisories for
+ early access to be able to prepare advisories for
coordinated release. Unless &os; developers can be
trusted to maintain security, such early access will not
be made available. The Security Officer is responsible
@@ -3745,7 +3743,7 @@
vulnerabilities, and for timing the release of all
advisories. He may request help under condition of
confidentiality from any developer with relevant knowledge
- in order to prepare security fixes.
+ to prepare security fixes.
@@ -3772,7 +3770,7 @@
- Private communications should not be made
+ Private communications are not made
public without permission.
Beyond the specific requirements above there is a
@@ -3786,13 +3784,13 @@
Communications on project-only or restricted access
- channels should be treated as private.
+ channels are private.
Similarly to personal communications, certain
internal communications channels, including &os; Committer
only mailing lists and restricted access IRC channels
- should be considered as private communications. You need
- permission in order to publish material from these
+ are considered as private communications. You need
+ permission to publish material from these
sources.
@@ -3948,7 +3946,7 @@
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 relatively recent. It should be
+ list must exist and be relatively recent. It is
integrated into the &os; documentation.
Current Tier 2 platforms are &arch.arm;, &arch.arm64;,
@@ -3965,9 +3963,9 @@
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. Initial support for Tier 3 platforms should be worked on
+ use. Initial support for Tier 3 platforms are worked on
in external SCM repositories.
- The transition to &os;'s subversion should take place after
+ The transition to &os;'s subversion takes place after
the platform boots multi-user on hardware; sharing via
subversion is needed for wider exposure; and multiple
developers are actively working on the platform.
@@ -4103,12 +4101,12 @@
- The port's PKGNAME should appear in exactly
+ The port's PKGNAME appears in exactly
one line in a recent INDEX file.
- No other ports should contain any reference
+ No other ports contains any reference
to the port's directory or PKGNAME in their
Makefiles
@@ -4276,7 +4274,7 @@
Another example is when a port is moved from one
subdirectory to another, or when you want to change the
- name of a directory because the author(s) renamed their
+ name of a directory because the authors renamed their
software even though it is a descendant of a port
already in a tree.
@@ -4323,8 +4321,8 @@
PORTNAME instead of adding
PKGNAMEPREFIX or
PKGNAMESUFFIX, but this
- should only be done when it is really needed
- — e.g., using an existing port as the base
+ is only done when it is really needed
+ — for example, using an existing port as the base
for a very similar program with a different
name, or upgrading a port to a new upstream
version which actually changes the distribution
@@ -4333,8 +4331,8 @@
textproc/libxml2. In most
cases, adding or changing
PKGNAMEPREFIX or
- PKGNAMESUFFIX should
- suffice.
+ PKGNAMESUFFIX
+ suffices.
@@ -4449,7 +4447,7 @@
Handbook. Once that procedure has been followed and the
PR has been assigned to the &a.portmgr;, it is their
decision whether or not to approve it. If they do, it
- is their responsibility to do the following:
+ is their responsibility to:
@@ -4490,7 +4488,7 @@
Change the port's
CATEGORIES (this was the
point of the exercise, remember?) The new
- category should be listed
+ category is listed
first. This will help to
ensure that the PKGORIGIN is
correct.
@@ -4526,7 +4524,7 @@
&man.portupgrade.1; fail.
To do this, use the
- chkorigin.sh tool, as follows:
+ chkorigin.sh tool:
env
PORTSDIR=/path/to/ports
sh -e
@@ -4570,8 +4568,7 @@
- Update the documentation by modifying the
- following:
+ Update the documentation by modifying:
@@ -4621,7 +4618,7 @@
This is much simpler than a physical category. You
- only need to modify the following:
+ only need to modify:
@@ -4702,7 +4699,7 @@
When the checksum for a port's distfile is updated
due to the author updating the file without changing the
- port's revision, the commit message should include a
+ port's revision, the commit message includes a
summary of the relevant diffs between the original and
new distfile to ensure that the distfile has not been
corrupted or maliciously altered. If the current
@@ -4736,8 +4733,7 @@
to be merged.
A script is provided to automate merging a specific
- commit: ports/Tools/scripts/mfh.
- It is used as follows:
+ commit: ports/Tools/scripts/mfh.
&prompt.user; /usr/ports/Tools/scripts/mfh 2015Q1 380362
U 2015Q1
@@ -4917,7 +4913,7 @@
linkend="conventions-everyone">Conventions
- You should get your mentor to add you to the
+ Get your mentor to add you to the
Additional Contributors
(doc/en_US.ISO8859-1/articles/contributors/contrib.additional.xml),
if you are not already listed there.
@@ -4948,7 +4944,7 @@
As of December 12, 2012, &ga; was enabled on the
&os; Project website to collect anonymized usage statistics
regarding usage of the site. The information collected is
- valuable to the &os; Documentation Project, in order to
+ valuable to the &os; Documentation Project, to
identify various problems on the &os; website.