public inbox for gcc-cvs-wwwdocs@sourceware.org help / color / mirror / Atom feed
From: Nathan Sidwell <nathan@sourceware.org> To: gcc-cvs-wwwdocs@gcc.gnu.org Subject: gcc-wwwdocs branch master updated. b5a0f250f0f05364a51c331d040d78bf15057884 Date: Tue, 30 Nov 2021 12:13:41 +0000 (GMT) [thread overview] Message-ID: <20211130121341.F19CA385BF92@sourceware.org> (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 <nathan@acm.org> 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> <ul> <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> </ul> <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 sourceware.org / gcc.gnu.org, ask <code>overseers@gcc.gnu.org</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="https://sourceware.org/cgi-bin/pdw/ps_form.cgi">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(-) hooks/post-receive -- gcc-wwwdocs
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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20211130121341.F19CA385BF92@sourceware.org \ --to=nathan@sourceware.org \ --cc=gcc-cvs-wwwdocs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe 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).