os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Properly break some overflowing lines that textproc/igor was reporting.

Browse source 
No visible content changes.
This commit is contained in:
Benedict Reuschling 2018-06-14 17:14:31 +00:00
parent 39722aa78c
commit d2dcb18a50
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=51831
1 changed files with 116 additions and 111 deletions
Download patch file Download diff file Expand all files Collapse all files

227
en_US.ISO8859-1/articles/committers-guide/article.xml
View file

@ -156,7 +156,8 @@
<entry><emphasis>Noteworthy <literal>src/</literal> SVN
Branches</emphasis></entry>
<entry>
<literal>stable/</literal><replaceable>n</replaceable> (<replaceable>n</replaceable>-STABLE),
<literal>stable/</literal><replaceable>n</replaceable>
(<replaceable>n</replaceable>-STABLE),
<literal>head</literal> (-CURRENT)</entry>
</row>
</tbody>
@ -477,8 +478,8 @@ You need a Passphrase to protect your secret key.</screen>
<sect1 xml:id="subversion-primer">
<title>Subversion Primer</title>
<para>New committers are assumed to already be familiar with the basic
operation of Subversion. If not, start by reading the
<para>New committers are assumed to already be familiar with the
basic operation of Subversion. If not, start by reading the
<link xlink:href="http://svnbook.red-bean.com/">Subversion
Book</link>.</para>
@ -958,15 +959,15 @@ You need a Passphrase to protect your secret key.</screen>
<para>This command creates a copy of
<filename>foo.c</filename> named <filename>bar.c</filename>,
with the new file also under version control and with the full
history of <filename>foo.c</filename>:</para>
with the new file also under version control and with the
full history of <filename>foo.c</filename>:</para>
<screen>&prompt.user; <userinput>svn copy <replaceable>foo.c</replaceable> <replaceable>bar.c</replaceable></userinput></screen>
<para>This is usually preferred to copying the file with
<command>cp</command> and adding it to the repository with
<command>svn add</command> because this way the new file does not
inherit the original one's history.</para>
<command>svn add</command> because this way the new file
does not inherit the original one's history.</para>
<para>To move and rename a file:</para>
@ -1301,8 +1302,8 @@ You need a Passphrase to protect your secret key.</screen>
<screen>&prompt.user; svn merge -c <replaceable>r123456</replaceable> ^/head/ <replaceable>checkout</replaceable>
&prompt.user; svn commit <replaceable>checkout</replaceable></screen>
<para>Note that <replaceable>checkout</replaceable>
must be a complete checkout of the branch to which the merge
<para>Note that <replaceable>checkout</replaceable> must be
a complete checkout of the branch to which the merge
occurs.</para>
<para>Merges to <literal>releng/</literal> branches must
@ -1679,8 +1680,8 @@ U stable/9/share/man/man4/netmap.4
on any file in the tree.</para>
<para>Committing is now possible. However, it is good
practice to make sure that everything is okay by using the
<command>svn stat</command> and
practice to make sure that everything is okay by using
the <command>svn stat</command> and
<command>svn diff</command> commands.</para>
</sect5>
@ -1907,12 +1908,12 @@ U stable/9/share/man/man4/netmap.4
<para>Avoid setting up a <application>svnsync</application>
mirror unless there is a very good reason for it. Such
reasons might be to support
multiple local read-only client machines, or if the network
bandwidth is limited. Starting a fresh mirror from empty
would take a very long time. Expect a minimum of 10 hours
for high speed connectivity. If international links are
involved, expect this to take four to ten times longer.</para>
reasons might be to support multiple local read-only client
machines, or if the network bandwidth is limited. Starting
a fresh mirror from empty would take a very long time.
Expect a minimum of 10 hours for high speed connectivity.
If international links are involved, expect this to take
four to ten times longer.</para>
<para>A far better option is to grab a seed file. It is large
(~1GB) but will consume less network traffic and take less
@ -1976,9 +1977,9 @@ U stable/9/share/man/man4/netmap.4
while and is finally committed back to the original branch.
During development code migration in one direction (from
head to the branch only). No code is committed back to head
until the end. After the branch is committed back at the end,
it is dead (although a new branch with the same name can be
created after the dead one is deleted).</para>
until the end. After the branch is committed back at the
end, it is dead (although a new branch with the same name
can be created after the dead one is deleted).</para>
<para>As per <link
xlink:href="https://people.FreeBSD.org/~peter/svn_notes.txt">https://people.FreeBSD.org/~peter/svn_notes.txt</link>,
@ -2227,10 +2228,10 @@ freebsd-mfc-after = 2 weeks</programlisting>
<para>Wiki Information - After gaining access to the wiki,
some people add entries to the <link
xlink:href="https://wiki.freebsd.org/HowWeGotHere">How We
Got Here</link>,
<link xlink:href="https://wiki.freebsd.org/IRC/Nicknames">
IRC Nicks</link>, and <link
xlink:href="https://wiki.freebsd.org/HowWeGotHere">How
We Got Here</link>, <link
xlink:href="https://wiki.freebsd.org/IRC/Nicknames">IRC
Nicks</link>, and <link
xlink:href="https://wiki.freebsd.org/Community/Dogs">
Dogs of FreeBSD</link> pages.</para>
</step>
@ -2480,7 +2481,8 @@ freebsd-mfc-after = 2 weeks</programlisting>
<row>
<entry><literal>Differential Revision:</literal></entry>
<entry>The full URL of the Phabricator review. This line
<emphasis>must be the last line</emphasis>. For example:
<emphasis>must be the last line</emphasis>. For
example:
<literal>https://reviews.freebsd.org/D1708</literal>.</entry>
</row>
</tbody>
@ -2718,26 +2720,27 @@ Relnotes: yes</programlisting>
<sect1 xml:id="developer.relations">
<title>Developer Relations</title>
<para>When working directly on your own code or on code
which is already well established as your responsibility, then
there is probably little need to check with other committers
before jumping in with a commit. Working on a bug in an area of
the system which is clearly orphaned (and there are a few such
areas, to our shame), the same applies. Trying
to modify something which is clearly being actively
maintained by someone else (and it is only by watching the
<para>When working directly on your own code or on code which is
already well established as your responsibility, then there is
probably little need to check with other committers before
jumping in with a commit. Working on a bug in an area of the
system which is clearly orphaned (and there are a few such
areas, to our shame), the same applies. Trying to modify
something which is clearly being actively maintained by someone
else (and it is only by watching the
<literal><replaceable>repository</replaceable>-committers</literal>
mailing list that a developer can really get a feel for just what is and
is not) then consider sending the change to them instead, just
as a developer would have before becoming a committer. For ports,
contact the listed <varname>MAINTAINER</varname> in the
mailing list that a developer can really get a feel for just
what is and is not) then consider sending the change to them
instead, just as a developer would have before becoming a
committer. For ports, contact the listed
<varname>MAINTAINER</varname> in the
<filename>Makefile</filename>. For other parts of the
repository, if it is not clear who the active maintainer
is, it may help to scan the revision history to see who has
committed changes in the past. An example script that lists
each person who has committed to
a given file along with the number of commits each person has
made can be found at on <systemitem>freefall</systemitem> at
repository, if it is not clear who the active maintainer is, it
may help to scan the revision history to see who has committed
changes in the past. An example script that lists each person
who has committed to a given file along with the number of
commits each person has made can be found at on
<systemitem>freefall</systemitem> at
<filename>~eadler/bin/whodid</filename>. If queries go
unanswered or the committer otherwise indicates a lack of
interest in the area affected, go ahead and commit it.</para>
@ -2748,22 +2751,22 @@ Relnotes: yes</programlisting>
output.</para>
</note>
<para>If there is any doubt about a commit for any reason at all, have
it reviewed by <literal>-hackers</literal> before committing.
Better to have it flamed then and there rather than when it is
part of the repository. If a commit does
results in controversy erupting, it may be advisable to
consider backing the change out again until the matter is
settled. Remember, with a version control system we can
always change it back.</para>
<para>If there is any doubt about a commit for any reason at all,
have it reviewed by <literal>-hackers</literal> before
committing. Better to have it flamed then and there rather than
when it is part of the repository. If a commit does results in
controversy erupting, it may be advisable to consider backing
the change out again until the matter is settled. Remember,
with a version control system we can always change it
back.</para>
<para>Do not impugn the intentions of others.
If they see a different solution to a problem, or even
a different problem, it is probably not because they are stupid, because
they have questionable parentage, or because they are trying to
destroy hard work, personal image, or &os;, but basically
because they have a different outlook on the world. Different
is good.</para>
<para>Do not impugn the intentions of others. If they see a
different solution to a problem, or even a different problem, it
is probably not because they are stupid, because they have
questionable parentage, or because they are trying to destroy
hard work, personal image, or &os;, but basically because they
have a different outlook on the world. Different is
good.</para>
<para>Disagree honestly. Argue your position from its merits,
be honest about any shortcomings it may have, and be open to
@ -2843,19 +2846,19 @@ Relnotes: yes</programlisting>
</step>
<step>
<para>Open new bug. Choose
<literal>Services</literal> as the Product, and
<literal>Bug Tracker</literal> as the Component.
In bug description list acounts you wish to be merged.</para>
<para>Open new bug. Choose <literal>Services</literal> as the
Product, and <literal>Bug Tracker</literal> as the
Component. In bug description list acounts you wish to be
merged.</para>
</step>
<step>
<para>Log in using
<systemitem class="domainname">&os;.org</systemitem> account and
post comment to newly opened bug to confirm ownership. See
<xref linkend="kerberos-ldap"/> for more details on how to
generate or set a password for your
<systemitem class="domainname">&os;.org</systemitem> account.</para>
<para>Log in using <systemitem
class="domainname">&os;.org</systemitem> account and post
comment to newly opened bug to confirm ownership. See <xref
linkend="kerberos-ldap"/> for more details on how to
generate or set a password for your <systemitem
class="domainname">&os;.org</systemitem> account.</para>
</step>
<step>
@ -3346,21 +3349,21 @@ Relnotes: yes</programlisting>
<para>Discuss any significant change
<emphasis>before</emphasis> committing.</para>
<para>The repository is not where changes are
initially submitted for correctness or argued over, that
happens first in the mailing lists or by use of the
Phabricator service. The commit will only happen once
something resembling consensus has been reached. This
does not mean that permission is required before
correcting every obvious syntax error or manual page
misspelling, just that it is good 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
better than what they had before, they just do not like
being <emphasis>surprised</emphasis> by those changes.
The very best way of making sure that things are on the right
track is to have code reviewed by one or more other
<para>The repository is not where changes are initially
submitted for correctness or argued over, that happens
first in the mailing lists or by use of the Phabricator
service. The commit will only happen once something
resembling consensus has been reached. This does not mean
that permission is required before correcting every
obvious syntax error or manual page misspelling, just that
it is good 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 better than what they had
before, they just do not like being
<emphasis>surprised</emphasis> by those changes. The very
best way of making sure that things are on the right track
is to have code reviewed by one or more other
committers.</para>
<para>When in doubt, ask for review!</para>
@ -3828,10 +3831,10 @@ Relnotes: yes</programlisting>
(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 test automation support either in the FreeBSD.org cluster,
or easily available for all developers. Embedded platforms
may substitute an emulator available in the FreeBSD.org cluster
for actual hardware.</para>
build and test automation support either in the FreeBSD.org
cluster, or easily available for all developers. Embedded
platforms may substitute an emulator available in the
FreeBSD.org cluster for actual hardware.</para>
<para>Tier 1 architectures are expected to be Production Quality
with respects to all aspects of the &os; operating system,
@ -4296,13 +4299,13 @@ Relnotes: yes</programlisting>
rare cases it may be necessary to change the
<varname>PORTNAME</varname> instead of adding
<varname>PKGNAMEPREFIX</varname> or
<varname>PKGNAMESUFFIX</varname>, but this
is only done when it is really needed
&mdash; 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
name, like the transition from
<varname>PKGNAMESUFFIX</varname>, but this is
only done when it is really needed &mdash; 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 name, like the
transition from
<filename>textproc/libxml</filename> to
<filename>textproc/libxml2</filename>. In most
cases, adding or changing
@ -4424,14 +4427,15 @@ Relnotes: yes</programlisting>
<programlisting>MFH: <replaceable>2014Q1</replaceable></programlisting>
<para>It will automatically notify the &a.ports-secteam; and
the &a.portmgr;. They will then decide if the commit can be
merged and answer with the procedure.</para>
<para>It will automatically notify the &a.ports-secteam;
and the &a.portmgr;. They will then decide if the
commit can be merged and answer with the
procedure.</para>
<para>If the commit has already been made, send an email
to the &a.ports-secteam; and the &a.portmgr; with the revision
number and a small description of why the commit needs
to be merged.</para>
to the &a.ports-secteam; and the &a.portmgr; with the
revision number and a small description of why the
commit needs to be merged.</para>
</answer>
</qandaentry>
@ -4442,7 +4446,8 @@ Relnotes: yes</programlisting>
</question>
<answer>
<para>The following blanket approvals are in effect:</para>
<para>The following blanket approvals are in
effect:</para>
<important>
<para>These fixes <emphasis>must</emphasis> be
@ -4459,7 +4464,7 @@ Relnotes: yes</programlisting>
<listitem>
<para><filename>pkg-descr</filename>:
<literal>WWW:</literal> URL updates (existing
404, moved or incorrect)</para>
404, moved or incorrect)</para>
</listitem>
</itemizedlist>
</listitem>
@ -4490,12 +4495,13 @@ Relnotes: yes</programlisting>
</listitem>
<listitem>
<para>Adding/fixing <varname>CONFLICTS</varname>.</para>
<para>Adding/fixing
<varname>CONFLICTS</varname>.</para>
</listitem>
<listitem>
<para>Web Browsers, browser plugins, and their required
dependencies.</para>
<para>Web Browsers, browser plugins, and their
required dependencies.</para>
</listitem>
</itemizedlist>
@ -4599,12 +4605,11 @@ Do you want to commit? (no = start a shell) [y/n]</screen>
been merged because they were not security related.
Add the different revisions <emphasis>in the order
they were committed</emphasis> on the
<command>mfh</command> command line.
The new commit log message will contain the combined
log messages from all the original commits. These
messages <emphasis>must</emphasis> be edited to show
what is actually being done with the new
commit.</para>
<command>mfh</command> command line. The new commit
log message will contain the combined log messages
from all the original commits. These messages
<emphasis>must</emphasis> be edited to show what is
actually being done with the new commit.</para>
<screen>&prompt.user; <userinput>/usr/ports/Tools/scripts/mfh r407208 r407713 r407722 r408567 r408943 r410728</userinput></screen>
</tip>