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 ------------------------------------------------------

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