[PATCH 1/2] docs: stable-kernel-rules: provide example of specifying target series

[PATCH 1/2] docs: stable-kernel-rules: provide example of specifying target series

[Shung-Hsi Yu]

Provide a concrete example of how to specify what stable series should
be targeted for change inclusion. Looking around on the stable mailing
list this seems like a common practice already, so let's mention that in
the documentation as well (but worded so it is not interpreted as the
only way to do so).

Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
---
 Documentation/process/stable-kernel-rules.rst | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index edf90bbe30f4..daa542988095 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -57,10 +57,13 @@ options for cases where a mainlined patch needs adjustments to apply in older
 series (for example due to API changes).
 
 When using option 2 or 3 you can ask for your change to be included in specific
-stable series. When doing so, ensure the fix or an equivalent is applicable,
-submitted, or already present in all newer stable trees still supported. This is
-meant to prevent regressions that users might later encounter on updating, if
-e.g. a fix merged for 5.19-rc1 would be backported to 5.10.y, but not to 5.15.y.
+stable series, one way to do so is by specifying the target series in the
+subject prefix (e.g. '[PATCH stable 5.15 5.10]' asks that the patch to be
+included in both 5.10.y and 5.15.y). When doing so, ensure the fix or an
+equivalent is applicable, submitted, or already present in all newer stable
+trees still supported. This is meant to prevent regressions that users might
+later encounter on updating, if e.g. a fix merged for 5.19-rc1 would be
+backported to 5.10.y, but not to 5.15.y.
 
 .. _option_1:
 
-- 
2.45.1

[PATCH 2/2] docs: stable-kernel-rules: remind reader about DCO

[Shung-Hsi Yu]

When sending patch authored by someone else to stable, it is quite easy for
the sender to forget adding the Developer's Certification of Origin (DCO,
i.e. Signed-off-by). Mention DCO explicilty so senders are less likely to
forget to do so and cause another round-trip.

Add a label in submitting-patches.rst so we can directly link to the DCO
section.

Link: https://lore.kernel.org/stable/2024051500-underage-unfixed-5d28@gregkh/
Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
---
 Documentation/process/stable-kernel-rules.rst | 4 ++++
 Documentation/process/submitting-patches.rst  | 1 +
 2 files changed, 5 insertions(+)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index daa542988095..a8fecc5f681c 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -168,6 +168,10 @@ If the submitted patch deviates from the original upstream patch (for example
 because it had to be adjusted for the older API), this must be very clearly
 documented and justified in the patch description.
 
+Be sure to also include a :ref:`Developer's Certificate of Origin
+<sign_your_work>` (i.e. ``Signed-off-by``) when sending patches that you did
+not author yourself.
+
 
 Following the submission
 ------------------------
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 66029999b587..98f1c8d8b429 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -394,6 +394,7 @@ e-mail discussions.
 
 ``git send-email`` will do this for you automatically.
 
+.. _sign_your_work:
 
 Sign your work - the Developer's Certificate of Origin
 ------------------------------------------------------
-- 
2.45.1

Re: [PATCH 1/2] docs: stable-kernel-rules: provide example of specifying target series

[Paul Barker]

[-- Attachment #1.1.1: Type: text/plain, Size: 2166 bytes --]

On 06/06/2024 07:43, Shung-Hsi Yu wrote:
> Provide a concrete example of how to specify what stable series should
> be targeted for change inclusion. Looking around on the stable mailing
> list this seems like a common practice already, so let's mention that in
> the documentation as well (but worded so it is not interpreted as the
> only way to do so).
> 
> Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
> ---
>  Documentation/process/stable-kernel-rules.rst | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index edf90bbe30f4..daa542988095 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -57,10 +57,13 @@ options for cases where a mainlined patch needs adjustments to apply in older
>  series (for example due to API changes).
>  
>  When using option 2 or 3 you can ask for your change to be included in specific
> -stable series. When doing so, ensure the fix or an equivalent is applicable,
> -submitted, or already present in all newer stable trees still supported. This is
> -meant to prevent regressions that users might later encounter on updating, if
> -e.g. a fix merged for 5.19-rc1 would be backported to 5.10.y, but not to 5.15.y.
> +stable series, one way to do so is by specifying the target series in the
> +subject prefix (e.g. '[PATCH stable 5.15 5.10]' asks that the patch to be

"that the patch is included in..." would be slightly better.

> +included in both 5.10.y and 5.15.y). When doing so, ensure the fix or an
> +equivalent is applicable, submitted, or already present in all newer stable
> +trees still supported. This is meant to prevent regressions that users might
> +later encounter on updating, if e.g. a fix merged for 5.19-rc1 would be
> +backported to 5.10.y, but not to 5.15.y.
>  
>  .. _option_1:
>  

This is a helpful clarification and I like seeing an example. With the
trivial change above:

Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com>

-- 
Paul Barker

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3577 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH 2/2] docs: stable-kernel-rules: remind reader about DCO

[Paul Barker]

[-- Attachment #1.1.1: Type: text/plain, Size: 738 bytes --]

On 06/06/2024 07:43, Shung-Hsi Yu wrote:
> When sending patch authored by someone else to stable, it is quite easy for
> the sender to forget adding the Developer's Certification of Origin (DCO,
> i.e. Signed-off-by). Mention DCO explicilty so senders are less likely to

s/explicilty/explicitly/

> forget to do so and cause another round-trip.
> 
> Add a label in submitting-patches.rst so we can directly link to the DCO
> section.
> 
> Link: https://lore.kernel.org/stable/2024051500-underage-unfixed-5d28@gregkh/

Is "Link:" right here? I'd prefer to see something like "For example see
..." added to the first paragraph so it's explicit that this is a link
to an example of this issue.

Thanks,

-- 
Paul Barker

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3577 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH 2/2] docs: stable-kernel-rules: remind reader about DCO

[Shung-Hsi Yu]

On Thu, Jun 06, 2024 at 09:21:39AM GMT, Paul Barker wrote:
> On 06/06/2024 07:43, Shung-Hsi Yu wrote:
> > When sending patch authored by someone else to stable, it is quite easy for
> > the sender to forget adding the Developer's Certification of Origin (DCO,
> > i.e. Signed-off-by). Mention DCO explicilty so senders are less likely to
> 
> s/explicilty/explicitly/
> 
> > forget to do so and cause another round-trip.
> > 
> > Add a label in submitting-patches.rst so we can directly link to the DCO
> > section.
> > 
> > Link: https://lore.kernel.org/stable/2024051500-underage-unfixed-5d28@gregkh/
> 
> Is "Link:" right here? I'd prefer to see something like "For example see
> ..." added to the first paragraph so it's explicit that this is a link
> to an example of this issue.

Thanks for the feedback. Yes that is better. Will clarify that, fix
typo, and slighly edit patch 1 as suggested.

Shung-Hsi