Date: Mon, 28 May 2018 20:27:23 +0000 (UTC) From: Eitan Adler <eadler@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r51736 - head/en_US.ISO8859-1/articles/committers-guide Message-ID: <201805282027.w4SKRNTY016767@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: eadler Date: Mon May 28 20:27:22 2018 New Revision: 51736 URL: https://svnweb.freebsd.org/changeset/doc/51736 Log: Committer guide: remove merge information for branches older than 10.x There are no such supported branches. Those that need to merge to such branches can get the information from the documentation archive. 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 Mon May 28 20:21:04 2018 (r51735) +++ head/en_US.ISO8859-1/articles/committers-guide/article.xml Mon May 28 20:27:22 2018 (r51736) @@ -1312,149 +1312,6 @@ You need a Passphrase to protect your secret key.</scr <screen>&prompt.user; svn merge -c <replaceable>r123456</replaceable> ^/stable/<replaceable>10</replaceable> releng/<replaceable>10.0</replaceable></screen> </sect4> - <!-- FIXME: This probably needs to go away --> - <sect4 xml:id="oldmerge"> - <title>Selecting the Source and Target for - <literal>stable/9</literal> and Older</title> - - <para>For <literal>stable/9</literal> and earlier, - a different strategy was used, distributing mergeinfo - around the tree so that merges could be performed without - 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 procedure below describes this - now-obsoleted process, which should be used - <emphasis>only for merges prior to - <literal>stable/10</literal></emphasis>.</para> - - <para>Because of mergeinfo propagation, it is important to - choose the source and target for the merge carefully to - minimise property changes on unrelated directories.</para> - - <para>The rules for selecting the merge target (the - directory where the changes are being merged to) can be - summarized:</para> - - <orderedlist> - <listitem> - <para>Never merge directly to a file.</para> - </listitem> - - <listitem> - <para>Never, ever merge directly to a file.</para> - </listitem> - - <listitem> - <para><emphasis>Never, ever, ever</emphasis> merge - directly to a file.</para> - </listitem> - - <listitem> - <para>Changes to kernel code are merged to - <filename>sys/</filename>. For instance, a change to - the &man.ichwd.4; driver is merged to - <filename>sys/</filename>, not - <filename>sys/dev/ichwd/</filename>. Likewise, a - change to the TCP/IP stack is merged to - <filename>sys/</filename>, not - <filename>sys/netinet/</filename>.</para> - </listitem> - - <listitem> - <para>Changes to code under <filename>etc/</filename> - is merged at <filename>etc/</filename>, not - below it.</para> - </listitem> - - <listitem> - <para>Changes to vendor code (code in - <filename>contrib/</filename>, - <filename>crypto/</filename> and so on) are - merged to the directory where vendor imports happen. - For instance, a change to - <filename>crypto/openssl/util/</filename> is - merged to <filename>crypto/openssl/</filename>. This - is rarely an issue, however, since changes to vendor - code are usually merged wholesale.</para> - </listitem> - - <listitem> - <para>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 - <filename>usr.bin/xlint/arch/i386/</filename> - is merged to - <filename>usr.bin/xlint/</filename>.</para> - </listitem> - - <listitem> - <para>Changes to userland libraries should as a general - rule be merged to the directory that contains the - Makefile for that library. For instance, a change to - <filename>lib/libc/gen/</filename> should be merged to - <filename>lib/libc/</filename>.</para> - </listitem> - - <listitem> - <para>There may be cases where it makes sense to deviate - from the rules for userland programs and libraries. - For instance, everything under - <filename>lib/libpam/</filename> is merged to - <filename>lib/libpam/</filename>, even though the - library itself and all of the modules each have their - own Makefile.</para> - </listitem> - - <listitem> - <para>Changes to manual pages are merged to - <filename>share/man/man<replaceable>N</replaceable>/</filename>, - for the appropriate value of - <literal>N</literal>.</para> - </listitem> - - <listitem> - <para>Other changes to <filename>share/</filename> - are merged to the appropriate subdirectory and - not to <filename>share/</filename> directly.</para> - </listitem> - - <listitem> - <para>Changes to a top-level file in the source tree - such as <filename>UPDATING</filename> or - <filename>Makefile.inc1</filename> 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.</para> - </listitem> - - <listitem> - <para>When in doubt, ask.</para> - </listitem> - </orderedlist> - - <para>If a merge changes several places at once - (for instance, changing a kernel interface and every - userland program that uses it), merge each target - separately, then commit them together. For instance, if - merging a revision that changed a kernel - <acronym>API</acronym> and updated all the userland bits - that used that <acronym>API</acronym>, merge the - kernel change to sys, and the userland bits to the - appropriate userland directories, then commit all of these - in one go.</para> - - <para>The source will almost invariably be the same as the - target. For instance, always merge - <filename>stable/7/lib/libc/</filename> from - <filename>head/lib/libc/</filename>. The only exception - would be when merging changes to code that has moved in - the source branch but not in the parent branch. For - instance, a change to &man.pkill.1; would be merged from - <filename>bin/pkill/</filename> in head to - <filename>usr.bin/pkill/</filename> in stable/7.</para> - </sect4> - <sect4> <title>Preparing the Merge Target</title>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201805282027.w4SKRNTY016767>