From owner-svn-doc-all@freebsd.org Thu Jun 14 17:14:32 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 8987D1015525; Thu, 14 Jun 2018 17:14:32 +0000 (UTC) (envelope-from bcr@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 3D17375A22; Thu, 14 Jun 2018 17:14:32 +0000 (UTC) (envelope-from bcr@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 1E33A3929; Thu, 14 Jun 2018 17:14:32 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w5EHEV9X093404; Thu, 14 Jun 2018 17:14:32 GMT (envelope-from bcr@FreeBSD.org) Received: (from bcr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w5EHEVPu093403; Thu, 14 Jun 2018 17:14:31 GMT (envelope-from bcr@FreeBSD.org) Message-Id: <201806141714.w5EHEVPu093403@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bcr set sender to bcr@FreeBSD.org using -f From: Benedict Reuschling Date: Thu, 14 Jun 2018 17:14:31 +0000 (UTC) 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 X-SVN-Group: doc-head X-SVN-Commit-Author: bcr X-SVN-Commit-Paths: head/en_US.ISO8859-1/articles/committers-guide X-SVN-Commit-Revision: 51831 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: Thu, 14 Jun 2018 17:14:32 -0000 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 @@ Noteworthy src/ SVN Branches - stable/n (n-STABLE), + stable/n + (n-STABLE), head (-CURRENT) @@ -477,8 +478,8 @@ You need a Passphrase to protect your secret key. Subversion Primer - New committers are assumed to already be familiar with the basic - operation of Subversion. If not, start by reading the + New committers are assumed to already be familiar with the + basic operation of Subversion. If not, start by reading the Subversion Book. @@ -958,15 +959,15 @@ You need a Passphrase to protect your secret key.This command creates a copy of foo.c named bar.c, - with the new file also under version control and with the full - history of foo.c: + with the new file also under version control and with the + full history of foo.c: &prompt.user; svn copy foo.c bar.c This is usually preferred to copying the file with cp and adding it to the repository with - svn add because this way the new file does not - inherit the original one's history. + svn add because this way the new file + does not inherit the original one's history. To move and rename a file: @@ -1301,8 +1302,8 @@ You need a Passphrase to protect your secret key.&prompt.user; svn merge -c r123456 ^/head/ checkout &prompt.user; svn commit checkout - Note that checkout - must be a complete checkout of the branch to which the merge + Note that checkout must be + a complete checkout of the branch to which the merge occurs. Merges to releng/ branches must @@ -1679,8 +1680,8 @@ U stable/9/share/man/man4/netmap.4 on any file in the tree. Committing is now possible. However, it is good - practice to make sure that everything is okay by using the - svn stat and + practice to make sure that everything is okay by using + the svn stat and svn diff commands. @@ -1907,12 +1908,12 @@ U stable/9/share/man/man4/netmap.4 Avoid setting up a svnsync 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. + 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. 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). + 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). As per https://people.FreeBSD.org/~peter/svn_notes.txt, @@ -2227,10 +2228,10 @@ freebsd-mfc-after = 2 weeks Wiki Information - After gaining access to the wiki, some people add entries to the How We - Got Here, - - IRC Nicks, and How + We Got Here, IRC + Nicks, and Dogs of FreeBSD pages. @@ -2480,7 +2481,8 @@ freebsd-mfc-after = 2 weeks Differential Revision: The full URL of the Phabricator review. This line - must be the last line. For example: + must be the last line. For + example: https://reviews.freebsd.org/D1708. @@ -2718,26 +2720,27 @@ Relnotes: yes Developer Relations - 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 + 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 repository-committers - 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 MAINTAINER 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 + MAINTAINER in the Makefile. 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 freefall 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 + freefall at ~eadler/bin/whodid. If queries go unanswered or the committer otherwise indicates a lack of interest in the area affected, go ahead and commit it. @@ -2748,22 +2751,22 @@ Relnotes: yes output. - If there is any doubt about a commit for any reason at all, have - it reviewed by -hackers 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. + If there is any doubt about a commit for any reason at all, + have it reviewed by -hackers 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. - 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. + 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. 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 - Open new bug. Choose - Services as the Product, and - Bug Tracker as the Component. - In bug description list acounts you wish to be merged. + Open new bug. Choose Services as the + Product, and Bug Tracker as the + Component. In bug description list acounts you wish to be + merged. - Log in using - &os;.org account and - post comment to newly opened bug to confirm ownership. See - for more details on how to - generate or set a password for your - &os;.org account. + Log in using &os;.org account and post + comment to newly opened bug to confirm ownership. See for more details on how to + generate or set a password for your &os;.org account. @@ -3346,21 +3349,21 @@ Relnotes: yes Discuss any significant change before committing. - 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 surprised 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 + 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 + surprised 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. When in doubt, ask for review! @@ -3828,10 +3831,10 @@ Relnotes: yes (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. + 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. 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 rare cases it may be necessary to change the PORTNAME instead of adding PKGNAMEPREFIX or - PKGNAMESUFFIX, 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 + PKGNAMESUFFIX, 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 textproc/libxml to textproc/libxml2. In most cases, adding or changing @@ -4424,14 +4427,15 @@ Relnotes: yes MFH: 2014Q1 - 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. + 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. 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. + 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. @@ -4442,7 +4446,8 @@ Relnotes: yes - The following blanket approvals are in effect: + The following blanket approvals are in + effect: These fixes must be @@ -4459,7 +4464,7 @@ Relnotes: yes pkg-descr: WWW: URL updates (existing - 404, moved or incorrect) + 404, moved or incorrect) @@ -4490,12 +4495,13 @@ Relnotes: yes - Adding/fixing CONFLICTS. + Adding/fixing + CONFLICTS. - Web Browsers, browser plugins, and their required - dependencies. + Web Browsers, browser plugins, and their + required dependencies. @@ -4599,12 +4605,11 @@ Do you want to commit? (no = start a shell) [y/n]in the order they were committed on the - mfh command line. - The new commit log message will contain the combined - log messages from all the original commits. These - messages must be edited to show - what is actually being done with the new - commit. + mfh command line. The new commit + log message will contain the combined log messages + from all the original commits. These messages + must be edited to show what is + actually being done with the new commit. &prompt.user; /usr/ports/Tools/scripts/mfh r407208 r407713 r407722 r408567 r408943 r410728