svn commit: r51831 - head/en_US.ISO8859-1/articles/committers-guide
Benedict Reuschling <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
Author: bcr
Date: Thu Jun 14 17:14:31 2018
New Revision: 51831
URL: https://svnweb.freebsd.org/changeset/doc/51831
Log:
Properly break some overflowing lines that textproc/igor was reporting.
No visible content changes.
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 Thu Jun 14 14:12:49 2018 (r51830)
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Thu Jun 14 17:14:31 2018 (r51831)
@@ -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.</scr
<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.</scr
<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.</scr
<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
- — 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 — 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]</scr
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>
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"