public inbox for
help / color / mirror / Atom feed
From: Nathan Sidwell <>
Subject: gcc-wwwdocs branch master updated. b5a0f250f0f05364a51c331d040d78bf15057884
Date: Tue, 30 Nov 2021 12:13:41 +0000 (GMT)	[thread overview]
Message-ID: <> (raw)

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
       via  b5a0f250f0f05364a51c331d040d78bf15057884 (commit)
      from  0cfd2fcac5f8dd0bc9b1ea23a0fe3be885a34aed (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit b5a0f250f0f05364a51c331d040d78bf15057884
Author: Nathan Sidwell <>
Date:   Tue Nov 30 07:12:44 2021 -0500

    Use gender-agnostic pronouns
    Use they/them/their in non-historical documents

diff --git a/htdocs/bugs/management.html b/htdocs/bugs/management.html
index 18fee991..97ef8299 100644
--- a/htdocs/bugs/management.html
+++ b/htdocs/bugs/management.html
@@ -203,7 +203,7 @@ fixing (the rationale is that a patch will have to go to the newest
 release branch before any other release branch).
 The priority of a regression should initially be set to P3.
 The milestone and the priority can
-be changed by the release manager and his/her delegates.</p>
+be changed by the release manager and their delegates.</p>
 <p><strong>If a patch fixing a PR has been submitted</strong>, a link
 to the message with the patch should be added to the PR, as well as the
@@ -224,8 +224,8 @@ release versions) should get "minor" severity and the additional keyword
 <p><strong>Bugs in component "bootstrap"</strong> that refer to older
 releases or snapshots/CVS versions should be put into state "WAITING",
-asking the reporter whether she can still reproduce the problem and to
-report her findings in any case (whether positive or negative).</p>
+asking the reporter whether they can still reproduce the problem and to
+report their findings in any case (whether positive or negative).</p>
 <li>If the response is "works now", close the report,</li>
diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index 423ce9de..c0223738 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -397,7 +397,7 @@ to point out lack of write access in your initial submission, too.</p>
 <h2 id="announce">Announcing Changes (to our Users)</h2>
-<p>Everything that requires a user to edit his Makefiles or his source code
+<p>Everything that requires a user to edit their Makefiles or source code
 is a good candidate for being mentioned in the release notes.</p>
 <p>Larger accomplishments, either as part of a specific project, or long
diff --git a/htdocs/develop.html b/htdocs/develop.html
index 4b1f9468..9880ad42 100644
--- a/htdocs/develop.html
+++ b/htdocs/develop.html
@@ -60,7 +60,7 @@ branch in the publicly accessible GCC development tree.)</p>
 <p>There is no firm guideline for what constitutes a "major change"
-and what does not.  If a developer is unsure, he or she should ask for
+and what does not.  If a developer is unsure, they should ask for
 guidance on the GCC mailing lists.  In general, a change that has the
 potential to be extremely destabilizing should be done on a branch.</p>
diff --git a/htdocs/fortran/index.html b/htdocs/fortran/index.html
index 1d140b3a..1984a297 100644
--- a/htdocs/fortran/index.html
+++ b/htdocs/fortran/index.html
@@ -117,11 +117,11 @@ changes.</li>
 <li>Approval should be necessary for
 patches which don't fall under the obvious rule. So, with the approver list
 put in place, everybody (except maintainers) should still seek approval for 
-his/her patches.  We have found the mutual peer review process really 
+their patches.  We have found the mutual peer review process really 
 works well.</li>
 <li>Patches should only be reviewed by
 people who know the affected parts of the compiler. (i.e. the
-reviewer has to be sure he/she knows stuff well enough to make a
+reviewer has to be sure they know stuff well enough to make a
 good judgment.)</li>
 <li>Large/complicated patches should
 still go by one of our maintainers, or team consensus.</li>
diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html
index 92740209..9de5de27 100644
--- a/htdocs/gitwrite.html
+++ b/htdocs/gitwrite.html
@@ -37,7 +37,7 @@ is not sufficient).</p>
 <p>If you already have an account on /, ask
 <code></code> to add access to the GCC repository.
-Include the name of your sponsor and CC: her.
+Include the name of your sponsor and CC: them.
 Otherwise use <a
 href="">this form</a>,
 again specifying your sponsor.</p>


Summary of changes:
 htdocs/bugs/management.html | 6 +++---
 htdocs/contribute.html      | 2 +-
 htdocs/develop.html         | 2 +-
 htdocs/fortran/index.html   | 4 ++--
 htdocs/gitwrite.html        | 2 +-
 5 files changed, 8 insertions(+), 8 deletions(-)


                 reply	other threads:[~2021-11-30 12:13 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).