mirror/ git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-05-10 02:36:08 +02:00
Code

SubmittingPatches: discuss reviewers first 

No matter how well someone configures their email tooling, understanding
who to send the patches to is something that must always be considered.
So discuss it first instead of at the end.

In the following commit we will clean up the (now redundant) discussion
about sending security patches to the Git Security mailing list.

Signed-off-by: Linus Arver <linusa@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
Linus Arver 2024-04-18 21:52:02 +00:00 committed by Junio C Hamano
parent c8d6a54a07
commit e2663c4597
1 changed files with 34 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
Documentation/SubmittingPatches
View File

@ -397,6 +397,40 @@ letter.
[[send-patches]]
=== Sending your patches.
==== Choosing your reviewers
:security-ml-ref: footnoteref:[security-ml]
As mentioned at the beginning of the section, patches that may be
security relevant should not be submitted to the public mailing list
mentioned below, but should instead be sent privately to the Git
Security mailing list{security-ml-ref}.
:contrib-scripts: footnoteref:[contrib-scripts,Scripts under `contrib/` are +
not part of the core `git` binary and must be called directly. Clone the Git +
codebase and run `perl contrib/contacts/git-contacts`.]
Send your patch with "To:" set to the mailing list, with "cc:" listing
people who are involved in the area you are touching (the `git-contacts`
script in `contrib/contacts/`{contrib-scripts} can help to
identify them), to solicit comments and reviews. Also, when you made
trial merges of your topic to `next` and `seen`, you may have noticed
work by others conflicting with your changes. There is a good possibility
that these people may know the area you are touching well.
:current-maintainer: footnote:[The current maintainer: gitster@pobox.com]
:git-ml: footnote:[The mailing list: git@vger.kernel.org]
After the list reached a consensus that it is a good idea to apply the
patch, re-send it with "To:" set to the maintainer{current-maintainer}
and "cc:" the list{git-ml} for inclusion. This is especially relevant
when the maintainer did not heavily participate in the discussion and
instead left the review to trusted others.
Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
`Tested-by:` lines as necessary to credit people who helped your
patch, and "cc:" them when sending such a final version for inclusion.
:security-ml: footnoteref:[security-ml,The Git Security mailing list: git-security@googlegroups.com]
Before sending any patches, please note that patches that may be
@ -490,38 +524,6 @@ patch, format it as "multipart/signed", not a text/plain message
that starts with `-----BEGIN PGP SIGNED MESSAGE-----`. That is
not a text/plain, it's something else.
:security-ml-ref: footnoteref:[security-ml]
As mentioned at the beginning of the section, patches that may be
security relevant should not be submitted to the public mailing list
mentioned below, but should instead be sent privately to the Git
Security mailing list{security-ml-ref}.
:contrib-scripts: footnoteref:[contrib-scripts,Scripts under `contrib/` are +
not part of the core `git` binary and must be called directly. Clone the Git +
codebase and run `perl contrib/contacts/git-contacts`.]
Send your patch with "To:" set to the mailing list, with "cc:" listing
people who are involved in the area you are touching (the `git-contacts`
script in `contrib/contacts/`{contrib-scripts} can help to
identify them), to solicit comments and reviews. Also, when you made
trial merges of your topic to `next` and `seen`, you may have noticed
work by others conflicting with your changes. There is a good possibility
that these people may know the area you are touching well.
:current-maintainer: footnote:[The current maintainer: gitster@pobox.com]
:git-ml: footnote:[The mailing list: git@vger.kernel.org]
After the list reached a consensus that it is a good idea to apply the
patch, re-send it with "To:" set to the maintainer{current-maintainer}
and "cc:" the list{git-ml} for inclusion. This is especially relevant
when the maintainer did not heavily participate in the discussion and
instead left the review to trusted others.
Do not forget to add trailers such as `Acked-by:`, `Reviewed-by:` and
`Tested-by:` lines as necessary to credit people who helped your
patch, and "cc:" them when sending such a final version for inclusion.
== Subsystems with dedicated maintainers
Some parts of the system have dedicated maintainers with their own