Re: [PATCH v2] doc/SubmittingPatches: correct subject guidance
- Date: Wed, 8 Nov 2017 09:10:27 -0500
- From: Eric Sunshine <sunshine@xxxxxxxxxxxxxx>
- Subject: Re: [PATCH v2] doc/SubmittingPatches: correct subject guidance
On Wed, Nov 8, 2017 at 8:47 AM, Adam Dinwoodie <adam@xxxxxxxxxxxxx> wrote:
> The examples and common practice for adding markers such as "RFC" or
> "v2" to the subject of patch emails is to have them within the same
> brackets as the "PATCH" text, not after the closing bracket. Further,
> the practice of `git format-patch` and the like, as well as what appears
> to be the more common pratice on the mailing list, is to use "[RFC
> PATCH]", not "[PATCH/RFC]".
> Update the SubmittingPatches article to match.
> Signed-off-by: Adam Dinwoodie <adam@xxxxxxxxxxxxx>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> @@ -184,12 +184,14 @@ lose tabs that way if you are not careful.
> It is a common convention to prefix your subject line with
> [PATCH]. This lets people easily distinguish patches from other
> -e-mail discussions. Use of additional markers after PATCH and
> -the closing bracket to mark the nature of the patch is also
> -encouraged. E.g. [PATCH/RFC] is often used when the patch is
> -not ready to be applied but it is for discussion, [PATCH v2],
> -[PATCH v3] etc. are often seen when you are sending an update to
> -what you have previously sent.
> +e-mail discussions. Use of markers in addition to PATCH within
> +the brackets to describe the nature of the patch is also
> +encouraged. E.g. [RFC PATCH] is often used when the patch is not
> +ready to be applied but it is for discussion, and can be added
> +with the `--rfc` argument to `git format-patch` or `git
> +send-email`, while [PATCH v2], [PATCH v3] etc. are often seen
It has become a bit of a run-on sentence, but aside from that and the
unnecessary extra whitespace between "etc." and "are", it looks good
> +when you are sending an update to what you have previously sent,
> +and can be added with the `-v <n>` arguments to the same commands.