Several process documents use gendered pronouns when referring generically to developers and maintainers. Use singular they instead, making the language inclusive without changing its meaning.
Leave pronouns referring to named people and text in attributed quotations unchanged. Assisted-by: LLM Signed-off-by: Ruben Sutton <[email protected]> --- Documentation/process/2.Process.rst | 2 +- Documentation/process/5.Posting.rst | 2 +- Documentation/process/6.Followthrough.rst | 2 +- Documentation/process/handling-regressions.rst | 2 +- Documentation/process/howto.rst | 2 +- Documentation/process/submitting-patches.rst | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst index 77f3f80e7c..75b5c236d8 100644 --- a/Documentation/process/2.Process.rst +++ b/Documentation/process/2.Process.rst @@ -227,7 +227,7 @@ tree, usually (but certainly not always) using the git source management tool. Tools like git (and related tools like quilt or mercurial) allow maintainers to track a list of patches, including authorship information and other metadata. At any given time, the maintainer can identify which -patches in his or her repository are not found in the mainline. +patches in their repository are not found in the mainline. When the merge window opens, top-level maintainers will ask Linus to "pull" the patches they have selected for merging from their repositories. If diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index 07d7dbed13..6e61204403 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -233,7 +233,7 @@ the patch. Each of these uses this format:: The tags in common use are: - - Signed-off-by: this is a developer's certification that he or she has + - Signed-off-by: this is a developer's certification that they have the right to submit the patch for inclusion into the kernel. It is an agreement to the Developer's Certificate of Origin, the full text of which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` diff --git a/Documentation/process/6.Followthrough.rst b/Documentation/process/6.Followthrough.rst index 66fa400c6d..ebb0e4cc95 100644 --- a/Documentation/process/6.Followthrough.rst +++ b/Documentation/process/6.Followthrough.rst @@ -114,7 +114,7 @@ What happens next If a patch is considered to be a good thing to add to the kernel, and once most of the review issues have been resolved, the next step is usually entry into a subsystem maintainer's tree. How that works varies from one -subsystem to the next; each maintainer has his or her own way of doing +subsystem to the next; each maintainer has their own way of doing things. In particular, there may be more than one tree - one, perhaps, dedicated to patches planned for the next merge window, and another for longer-term work. diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst index c71b5d403f..6958a2a8b0 100644 --- a/Documentation/process/handling-regressions.rst +++ b/Documentation/process/handling-regressions.rst @@ -283,7 +283,7 @@ sure your patch description makes this aspect obvious. Once the change is merged, tell the Linux kernel's regression tracker and the regressions mailing list about the risk, so everyone has the change on the radar in case reports trickle in. Depending on the risk, you also might want to ask the subsystem -maintainer to mention the issue in his mainline pull request. +maintainer to mention the issue in their mainline pull request. What else is there to known about regressions? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index 9438e03d6f..8c60138d03 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -305,7 +305,7 @@ The maintainers of the various kernel subsystems --- and also many kernel subsystem developers --- expose their current state of development in source repositories. That way, others can see what is happening in the different areas of the kernel. In areas where -development is rapid, a developer may be asked to base his submissions +development is rapid, a developer may be asked to base their submissions onto such a subsystem kernel tree so that conflicts between the submission and other already ongoing work are avoided. diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 7ae79452e1..4c28a239e8 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -456,7 +456,7 @@ When to use Acked-by:, Cc:, and Co-developed-by: ------------------------------------------------ The Signed-off-by: tag indicates that the signer was involved in the -development of the patch, or that he/she was in the patch's delivery path. +development of the patch, or that they were in the patch's delivery path. If a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can base-commit: 893e11787f78e43b534e252249ac3fff4d1333f8 -- 2.54.0 (Apple Git-157)
