]> git.ipfire.org Git - thirdparty/bind9.git/commitdiff
Miscellaneous formatting and wording tweaks
authorMichal Nowak <mnowak@isc.org>
Fri, 4 Sep 2020 10:09:31 +0000 (12:09 +0200)
committerMichał Kępień <michal@isc.org>
Fri, 4 Sep 2020 10:09:31 +0000 (12:09 +0200)
CODE_OF_CONDUCT.md
CONTRIBUTING.md
README.md

index 2f037100380ed1fbc8b8155835958114097d5f13..67b4c15ac97399ff5964122c6dfa12601eb958f1 100644 (file)
@@ -7,8 +7,8 @@ people.
 
 Diversity is one of our huge strengths, but it can also lead to communication
 issues and unhappiness. To that end, we have a few ground rules that we ask
-people to adhere to. This code applies equally to the core development team, open source contributors and those
-seeking help and guidance.
+people to adhere to. This code applies equally to the core development team,
+open source contributors and those seeking help and guidance.
 
 This isn't an exhaustive list of things that you can't do. Rather, take it in
 the spirit in which it's intended - a guide to make it easier to enrich all of
index 36c9b692adae1deba1129c206ca119b754f8591f..f90d5bf36a8b7a59f1870f47ee48fa0d9e68ce3f 100644 (file)
@@ -46,8 +46,9 @@ building communities that are welcoming and inclusive: environments where people
 are encouraged to share ideas, treat each other with respect, and collaborate
 towards the best solutions. To reinforce our commitment, ISC
 has adopted a slightly modified version of the Django
-[Code of Conduct](https://gitlab.isc.org/isc-projects/bind9/-/blob/master/CODE_OF_CONDUCT.md) for the BIND 9 project, as well as for the conduct of our
-developers throughout the industry.
+[Code of Conduct](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/CODE_OF_CONDUCT.md)
+for the BIND 9 project, as well as for the conduct of our developers throughout
+the industry.
 
 ### <a name="access"></a>Access to source code
 
@@ -80,7 +81,7 @@ Whenever a branch is ready for publication, a tag is placed of the
 form `v9_X_Y`.  The 9.12.0 release, for instance, is tagged as `v9_12_0`.
 
 The branch in which the next major release is being developed is called
-`master`.
+`main`.
 
 ### <a name="bugs"></a>Reporting bugs
 
@@ -100,6 +101,7 @@ use credentials from an existing account at GitHub, GitLab, Google,
 Twitter, or Facebook.
 
 ### Reporting possible security issues
+
 If you think you may be seeing a potential security vulnerability in BIND
 (for example, a crash with REQUIRE, INSIST, or ASSERT failure), please
 report it immediately by emailing to security-officer@isc.org. Plain-text
@@ -111,7 +113,8 @@ Do not discuss undisclosed security vulnerabilities on any public mailing list.
 ISC has a long history of handling reported vulnerabilities promptly and
 effectively and we respect and acknowledge responsible reporters.
 
-ISC's Security Vulnerability Disclosure Policy is documented at [https://kb.isc.org/docs/aa-00861](https://kb.isc.org/docs/aa-00861).
+ISC's Security Vulnerability Disclosure Policy is documented at
+[https://kb.isc.org/docs/aa-00861](https://kb.isc.org/docs/aa-00861).
 
 If you have a crash, you may want to consult
 ["What to do if your BIND or DHCP server has crashed."](https://kb.isc.org/docs/aa-00340)
@@ -120,7 +123,8 @@ If you have a crash, you may want to consult
 
 BIND is licensed under the
 [Mozilla Public License 2.0](https://www.mozilla.org/en-US/MPL/2.0/).
-Earlier versions (BIND 9.10 and earlier) were licensed under the [ISC License](https://www.isc.org/licenses/)
+Earlier versions (BIND 9.10 and earlier) were licensed under the
+[ISC License](https://www.isc.org/licenses/)
 
 ISC does not require an explicit copyright assignment for patch
 contributions.  However, by submitting a patch to ISC, you implicitly
@@ -136,7 +140,7 @@ Patches for BIND may be submitted directly via merge requests in
 repository for BIND.
 
 Patches can also be submitted as diffs against a specific version of
-BIND -- preferably the current top of the `master` branch.  Diffs may
+BIND -- preferably the current top of the `main` branch.  Diffs may
 be generated using either `git format-patch` or `git diff`.
 
 Those wanting to write code for BIND may be interested in the
@@ -184,7 +188,8 @@ of documentation in the BIND source tree:
   they document, in files ending in `.rst`: for example, the
   `named` man page is `bin/named/named.rst`.
 * The *BIND 9 Administrator Reference Manual* is in the .rst files in
-  `doc/arm/`; the PDF and HTML versions are automatically generated from the `.rst` files.
+  `doc/arm/`; the PDF and HTML versions are automatically generated from
+  the `.rst` files.
 * API documentation is in the header file describing the API, in
   Doxygen-formatted comments.
 
index d0db168a074d4866db458832497a25a0f8f8fefe..696697de0eed0abd014037f3ab572792e2a6831f 100644 (file)
--- a/README.md
+++ b/README.md
@@ -344,7 +344,7 @@ the change that was made; these categories are:
 | [cleanup] | Minor corrections and refactoring |
 | [doc] | Documentation |
 | [contrib] | Changes to the contributed tools and libraries in the 'contrib' subdirectory |
-| [placeholder] | Used in the master development branch to reserve change numbers for use in other branches, e.g. when fixing a bug that only exists in older releases |
+| [placeholder] | Used in the main development branch to reserve change numbers for use in other branches, e.g., when fixing a bug that only exists in older releases |
 
 In general, [func] and [experimental] tags will only appear in new-feature
 releases (i.e., those with version numbers ending in zero).  Some new