From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
Received: by sourceware.org (Postfix, from userid 1059)
id F19CA385BF92; Tue, 30 Nov 2021 12:13:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F19CA385BF92
To: gcc-cvs-wwwdocs@gcc.gnu.org
Subject: gcc-wwwdocs branch master updated.
b5a0f250f0f05364a51c331d040d78bf15057884
X-Git-Refname: refs/heads/master
X-Git-Reftype: branch
X-Git-Oldrev: 0cfd2fcac5f8dd0bc9b1ea23a0fe3be885a34aed
X-Git-Newrev: b5a0f250f0f05364a51c331d040d78bf15057884
Message-Id: <20211130121341.F19CA385BF92@sourceware.org>
Date: Tue, 30 Nov 2021 12:13:41 +0000 (GMT)
From: Nathan Sidwell
X-BeenThere: gcc-cvs-wwwdocs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-cvs-wwwdocs mailing list
List-Unsubscribe: ,
List-Archive:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 30 Nov 2021 12:13:42 -0000
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.
+be changed by the release manager and their delegates.
If a patch fixing a PR has been submitted, 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
Bugs in component "bootstrap" 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).
+asking the reporter whether they can still reproduce the problem and to
+report their findings in any case (whether positive or negative).
- If the response is "works now", close the report,
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.
Announcing Changes (to our Users)
-Everything that requires a user to edit his Makefiles or his source code
+
Everything that requires a user to edit their Makefiles or source code
is a good candidate for being mentioned in the release notes.
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.)
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.
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.
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.
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.)
Large/complicated patches should
still go by one of our maintainers, or team consensus.
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).
If you already have an account on sourceware.org / gcc.gnu.org, ask
overseers@gcc.gnu.org
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 this form,
again specifying your sponsor.
-----------------------------------------------------------------------
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(-)
hooks/post-receive
--
gcc-wwwdocs