From owner-svn-doc-all@freebsd.org Mon May 28 20:27:24 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3EC9F94997; Mon, 28 May 2018 20:27:23 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 892C98331A; Mon, 28 May 2018 20:27:23 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 65BA412326; Mon, 28 May 2018 20:27:23 +0000 (UTC) (envelope-from eadler@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w4SKRNUD016768; Mon, 28 May 2018 20:27:23 GMT (envelope-from eadler@FreeBSD.org) Received: (from eadler@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w4SKRNTY016767; Mon, 28 May 2018 20:27:23 GMT (envelope-from eadler@FreeBSD.org) Message-Id: <201805282027.w4SKRNTY016767@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: eadler set sender to eadler@FreeBSD.org using -f From: Eitan Adler Date: Mon, 28 May 2018 20:27:23 +0000 (UTC) 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 X-SVN-Group: doc-head X-SVN-Commit-Author: eadler X-SVN-Commit-Paths: head/en_US.ISO8859-1/articles/committers-guide X-SVN-Commit-Revision: 51736 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 20:27:24 -0000 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.&prompt.user; svn merge -c r123456 ^/stable/10 releng/10.0 - - - Selecting the Source and Target for - <literal>stable/9</literal> and Older - - For stable/9 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 - only for merges prior to - stable/10. - - Because of mergeinfo propagation, it is important to - choose the source and target for the merge carefully to - minimise property changes on unrelated directories. - - The rules for selecting the merge target (the - directory where the changes are being merged to) can be - summarized: - - - - Never merge directly to a file. - - - - Never, ever merge directly to a file. - - - - Never, ever, ever merge - directly to a file. - - - - Changes to kernel code are merged to - sys/. For instance, a change to - the &man.ichwd.4; driver is merged to - sys/, not - sys/dev/ichwd/. Likewise, a - change to the TCP/IP stack is merged to - sys/, not - sys/netinet/. - - - - Changes to code under etc/ - is merged at etc/, not - below it. - - - - Changes to vendor code (code in - contrib/, - crypto/ and so on) are - merged to the directory where vendor imports happen. - For instance, a change to - crypto/openssl/util/ is - merged to crypto/openssl/. This - is rarely an issue, however, since changes to vendor - code are usually merged wholesale. - - - - 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/ - is merged to - usr.bin/xlint/. - - - - 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 - lib/libc/gen/ should be merged to - lib/libc/. - - - - There may be cases where it makes sense to deviate - from the rules for userland programs and libraries. - For instance, everything under - lib/libpam/ is merged to - lib/libpam/, even though the - library itself and all of the modules each have their - own Makefile. - - - - Changes to manual pages are merged to - share/man/manN/, - for the appropriate value of - N. - - - - Other changes to share/ - 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 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. - - - - When in doubt, ask. - - - - 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 - API and updated all the userland bits - that used that API, merge the - kernel change to sys, and the userland bits to the - appropriate userland directories, then commit all of these - in one go. - - The source will almost invariably be the same as the - target. For instance, always merge - stable/7/lib/libc/ from - head/lib/libc/. 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 - bin/pkill/ in head to - usr.bin/pkill/ in stable/7. - - Preparing the Merge Target