diff --git a/en_US.ISO8859-1/articles/committers-guide/article.xml b/en_US.ISO8859-1/articles/committers-guide/article.xml index 5548c749b6..677acde289 100644 --- a/en_US.ISO8859-1/articles/committers-guide/article.xml +++ b/en_US.ISO8859-1/articles/committers-guide/article.xml @@ -1867,10 +1867,10 @@ U stable/9/share/man/man4/netmap.4 four to ten times longer. One way to limit the time required is to grab a seed file. - It is large - (~1GB) but will consume less network traffic and take less - time to fetch than svnsync will. + xlink:href="https://download.freebsd.org/ftp/development/subversion/">seed + file. It is large (~1GB) but will consume less + network traffic and take less time to fetch than svnsync + will. Extract the file and update it: @@ -2393,14 +2393,13 @@ freebsd-mfc-after = 2 weeks portion of the work was sponsored, or different amounts of sponsorship were provided to different authors, please give appropriate credit in parentheses after each - sponsor name. For example, - Example.com (alice, code refactoring), - Wormulon (bob), Momcorp (cindy) - shows that Alice was sponsored by Example.com to do code - refactoring, while Wormulon sponsored Bob's work and - Momcorp sponsored Cindy's work. Other authors were - either not sponsored or chose not to list - sponsorship. + sponsor name. For example, Example.com (alice, + code refactoring), Wormulon (bob), Momcorp + (cindy) shows that Alice was sponsored by + Example.com to do code refactoring, while Wormulon + sponsored Bob's work and Momcorp sponsored Cindy's work. + Other authors were either not sponsored or chose not to + list sponsorship. @@ -3511,17 +3510,16 @@ Relnotes: yes Reasons for modifying upstream software range from wanting strict control over a tightly coupled dependency - to lack of portability in the canonical - repository's distribution of their code. Regardless of the - reason, effort to minimize the maintenance burden of - fork is helpful to fellow maintainers. Avoid committing - trivial or cosmetic changes to files - since it makes every merge thereafter more - difficult: such patches need to be manually re-verified - every import. + to lack of portability in the canonical repository's + distribution of their code. Regardless of the reason, + effort to minimize the maintenance burden of fork is + helpful to fellow maintainers. Avoid committing trivial + or cosmetic changes to files since it makes every merge + thereafter more difficult: such patches need to be + manually re-verified every import. If a particular piece of software lacks a maintainer, - you're encouraged to take up owership. If you're unsure + you are encouraged to take up owership. If you are unsure of the current maintainership email &a.arch; and ask. @@ -4476,9 +4474,9 @@ MFH: 2014Q1 (browser blanket) - Commits that aren't covered by these blanket - approvals always require explicit approval of - either &a.ports-secteam; or &a.portmgr;. + Commits that are not covered by these blanket + approvals always require explicit approval of either + &a.ports-secteam; or &a.portmgr;. @@ -4575,9 +4573,9 @@ Do you want to commit? (no = start a shell) [y/n] been merged because they were not security related. Add the different revisions 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 + mfh 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.