Date: Thu, 14 Jun 2018 17:14:31 +0000 (UTC) From: Benedict Reuschling <bcr@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r51831 - head/en_US.ISO8859-1/articles/committers-guide Message-ID: <201806141714.w5EHEVPu093403@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201806141714.w5EHEVPu093403>