[RFC PATCH v1 0/3] docs: stable-kernel-rules: add delayed backporting option and a few tweaks
This is a RFC and a bit rough for now. I only set down to create the first of the three patches. But while doing so I noticed a few things that seemed odd for me with my background on writing and editing texts. So I just quickly performed a few additional changes to fix those to see if the stable team would appreciate them, as this document is clearly their domain.
If those changes or even the initial patch are not welcomed, I'll simply drop them. I'd totally understand this, as texts like these are delicate and it's easy to accidentlly change the intent or the meaning while adjusting things in good faith.
At the same time I might be willing to do a few more changes, if people like the direction this takes and want a bit more fine tuning.
CC: Greg KH gregkh@linuxfoundation.org CC: Sasha Levin sashal@kernel.org CC: Jonathan Corbet corbet@lwn.net
Thorsten Leemhuis (3): docs: stable-kernel-rules: mention other usages for stable tag comments docs: stable-kernel-rules: make rule section more straight forward docs: stable-kernel-rules: improve structure to optimize reading flow
Documentation/process/stable-kernel-rules.rst | 189 ++++++++++-------- 1 file changed, 105 insertions(+), 84 deletions(-)
base-commit: 016571b6d52deb473676fb4d24baf8ed3667ae21
Document how to delay backporting or send a note to the stable team using shell-style inline comments attached to stable tags.
CC: Greg KH gregkh@linuxfoundation.org CC: Sasha Levin sashal@kernel.org CC: Jonathan Corbet corbet@lwn.net Signed-off-by: Thorsten Leemhuis linux@leemhuis.info --- Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 51df1197d5ab..6e4026dd6882 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag
Cc: stable@vger.kernel.org
-in the sign-off area. Once the patch is merged it will be applied to -the stable tree without anything else needing to be done by the author -or subsystem maintainer. +in the sign-off area; to accompany a note to the stable team, use a shell-style +inline comment (see below for details). Once the patch is merged it will be +applied to the stable tree without anything else needing to be done by the +author or subsystem maintainer.
.. _option_2:
@@ -139,6 +140,21 @@ The tag has the meaning of:
For each "-stable" tree starting with the specified version.
+To delay pick up of patches submitted via :ref:`option_1`, use the following +format: + +.. code-block:: none + + Cc: stable@vger.kernel.org # after 4 weeks in mainline + +For any other requests related to patches submitted via :ref:`option_1`, just +add a note to the stable tag. This for example can be used to point out known +problems: + +.. code-block:: none + + Cc: stable@vger.kernel.org # see patch description, needs adjustments for >= 6.3 + Following the submission:
- The sender will receive an ACK when the patch has been accepted into the
On Mon, Jul 10, 2023 at 07:10:11PM +0200, Thorsten Leemhuis wrote:
Document how to delay backporting or send a note to the stable team using shell-style inline comments attached to stable tags.
CC: Greg KH gregkh@linuxfoundation.org CC: Sasha Levin sashal@kernel.org CC: Jonathan Corbet corbet@lwn.net Signed-off-by: Thorsten Leemhuis linux@leemhuis.info
Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 51df1197d5ab..6e4026dd6882 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag Cc: stable@vger.kernel.org -in the sign-off area. Once the patch is merged it will be applied to -the stable tree without anything else needing to be done by the author -or subsystem maintainer. +in the sign-off area; to accompany a note to the stable team, use a shell-style
Is that how a ';' is really used? I never can remember, so it's an honest question here :)
+inline comment (see below for details). Once the patch is merged it will be +applied to the stable tree without anything else needing to be done by the +author or subsystem maintainer. .. _option_2: @@ -139,6 +140,21 @@ The tag has the meaning of: For each "-stable" tree starting with the specified version. +To delay pick up of patches submitted via :ref:`option_1`, use the following +format:
+.. code-block:: none
Cc: <stable@vger.kernel.org> # after 4 weeks in mainline+For any other requests related to patches submitted via :ref:`option_1`, just +add a note to the stable tag. This for example can be used to point out known +problems:
+.. code-block:: none
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for >= 6.3
This looks great to me, so I'll be glad to take it.
thanks,
greg k-h
On 10.07.23 21:43, Greg KH wrote:
On Mon, Jul 10, 2023 at 07:10:11PM +0200, Thorsten Leemhuis wrote:
Document how to delay backporting or send a note to the stable team using shell-style inline comments attached to stable tags.
CC: Greg KH gregkh@linuxfoundation.org CC: Sasha Levin sashal@kernel.org CC: Jonathan Corbet corbet@lwn.net Signed-off-by: Thorsten Leemhuis linux@leemhuis.info
Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 51df1197d5ab..6e4026dd6882 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag Cc: stable@vger.kernel.org -in the sign-off area. Once the patch is merged it will be applied to -the stable tree without anything else needing to be done by the author -or subsystem maintainer. +in the sign-off area; to accompany a note to the stable team, use a shell-style
Is that how a ';' is really used? I never can remember, so it's an honest question here :)
Ha, better ask a native speaker or your favorite internet search engine for advice and not someone from Germany that in school was always bad at both German and English. ;)
But to answer the question: I think it is used this way in English "to connect related, but independent clauses". But the relation is not that strong or important here; I also tend use semicolons a bit too much, so I'll just drop it for v2.
[...] This looks great to me, so I'll be glad to take it.
thx!
Ciao, Thorsten
On Mon, 10 Jul 2023, Thorsten Leemhuis linux@leemhuis.info wrote:
Document how to delay backporting or send a note to the stable team using shell-style inline comments attached to stable tags.
CC: Greg KH gregkh@linuxfoundation.org CC: Sasha Levin sashal@kernel.org CC: Jonathan Corbet corbet@lwn.net Signed-off-by: Thorsten Leemhuis linux@leemhuis.info
Documentation/process/stable-kernel-rules.rst | 22 ++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 51df1197d5ab..6e4026dd6882 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -55,9 +55,10 @@ To have the patch automatically included in the stable tree, add the tag Cc: stable@vger.kernel.org -in the sign-off area. Once the patch is merged it will be applied to -the stable tree without anything else needing to be done by the author -or subsystem maintainer. +in the sign-off area; to accompany a note to the stable team, use a shell-style +inline comment (see below for details). Once the patch is merged it will be +applied to the stable tree without anything else needing to be done by the +author or subsystem maintainer. .. _option_2: @@ -139,6 +140,21 @@ The tag has the meaning of: For each "-stable" tree starting with the specified version. +To delay pick up of patches submitted via :ref:`option_1`, use the following +format:
+.. code-block:: none
Cc: <stable@vger.kernel.org> # after 4 weeks in mainline+For any other requests related to patches submitted via :ref:`option_1`, just +add a note to the stable tag. This for example can be used to point out known +problems:
+.. code-block:: none
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for >= 6.3
To me, this seems like promoting *any* free text after the #, making it harder to parse in scripts.
Of course, I'm only ever producing this, and never consuming, so if the manual reading is fine for the stable developers, who am I to argue.
BR, Jani.
Following the submission:
- The sender will receive an ACK when the patch has been accepted into the
On 11.07.23 12:15, Jani Nikula wrote:
On Mon, 10 Jul 2023, Thorsten Leemhuis linux@leemhuis.info wrote: [...]
+To delay pick up of patches submitted via :ref:`option_1`, use the following +format:
+.. code-block:: none
Cc: <stable@vger.kernel.org> # after 4 weeks in mainline+For any other requests related to patches submitted via :ref:`option_1`, just +add a note to the stable tag. This for example can be used to point out known +problems:
+.. code-block:: none
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for >= 6.3To me, this seems like promoting *any* free text after the #, making it harder to parse in scripts.
Of course, I'm only ever producing this, and never consuming, so if the manual reading is fine for the stable developers, who am I to argue.
I had similar concerns, to which Greg replied: ```my "script" is me reviewing each patch :)```
FWIW, that was here: https://lore.kernel.org/all/2023061936-eatable-grumbling-f3c1@gregkh/
Ciao, Thorsten
Tweak some of the rule text to make things more straight forward, with the goal to stick closely to the intend of the old text:
* put the "it or equivalent fix must be ustream" rule at the top, as it's one of the most important ones that at the same time often seems to be missed by developers. * "It must fix only one thing" was dropped, as that is almost always a thing that needs to be handled earlier when the change is mainlined. Furthermore, this is already indirectly covered by the "Separate your changes" section in Documentation/process/submitting-patches.rst which the rules already point to. * six other rules are in the end one rule with clarifications; structure the text accordingly to make it a lot easier to follow and understand the intend.
CC: Greg KH gregkh@linuxfoundation.org CC: Sasha Levin sashal@kernel.org CC: Jonathan Corbet corbet@lwn.net Signed-off-by: Thorsten Leemhuis linux@leemhuis.info --- Documentation/process/stable-kernel-rules.rst | 39 +++++++++---------- 1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 6e4026dd6882..85d5d2368034 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -6,31 +6,30 @@ Everything you ever wanted to know about Linux -stable releases Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree:
+ - It or an equivalent fix must already exist in Linus' tree (upstream). - It must be obviously correct and tested. - It cannot be bigger than 100 lines, with context. - - It must fix only one thing. - - It must fix a real bug that bothers people (not a, "This could be a - problem..." type thing). - - It must fix a problem that causes a build error (but not for things - marked CONFIG_BROKEN), an oops, a hang, data corruption, a real - security issue, or some "oh, that's not good" issue. In short, something - critical. - - Serious issues as reported by a user of a distribution kernel may also - be considered if they fix a notable performance or interactivity issue. - As these fixes are not as obvious and have a higher risk of a subtle - regression they should only be submitted by a distribution kernel - maintainer and include an addendum linking to a bugzilla entry if it - exists and additional information on the user-visible impact. - - New device IDs and quirks are also accepted. - - No "theoretical race condition" issues, unless an explanation of how the - race can be exploited is also provided. - - It cannot contain any "trivial" fixes in it (spelling changes, - whitespace cleanups, etc). - It must follow the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` rules. - - It or an equivalent fix must already exist in Linus' tree (upstream). - + - It must either fix a real bug that bothers people or just add a device ID. + To elaborate on the former: + + - It fixes a problem like an oops, a hang, data corruption, a real security + issue, a hardware quirk, a build error (but not for things marked + CONFIG_BROKEN), or some "oh, that's not good" issue. In short, something + critical. + - Serious issues as reported by a user of a distribution kernel may also + be considered if they fix a notable performance or interactivity issue. + As these fixes are not as obvious and have a higher risk of a subtle + regression they should only be submitted by a distribution kernel + maintainer and include an addendum linking to a bugzilla entry if it + exists and additional information on the user-visible impact. + - No "This could be a problem..." type of things like a "theoretical race + condition", unless an explanation of how the bug can be exploited is also + provided. + - No "trivial" fixes without benefit for users (spelling changes, whitespace + cleanups, etc).
Procedure for submitting patches to the -stable tree ----------------------------------------------------
On Mon, Jul 10, 2023 at 07:10:12PM +0200, Thorsten Leemhuis wrote:
Tweak some of the rule text to make things more straight forward, with the goal to stick closely to the intend of the old text:
- put the "it or equivalent fix must be ustream" rule at the top, as it's one of the most important ones that at the same time often seems to be missed by developers.
- "It must fix only one thing" was dropped, as that is almost always a thing that needs to be handled earlier when the change is mainlined. Furthermore, this is already indirectly covered by the "Separate your changes" section in Documentation/process/submitting-patches.rst which the rules already point to.
- six other rules are in the end one rule with clarifications; structure the text accordingly to make it a lot easier to follow and understand the intend.
CC: Greg KH gregkh@linuxfoundation.org CC: Sasha Levin sashal@kernel.org CC: Jonathan Corbet corbet@lwn.net Signed-off-by: Thorsten Leemhuis linux@leemhuis.info
Documentation/process/stable-kernel-rules.rst | 39 +++++++++---------- 1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 6e4026dd6882..85d5d2368034 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -6,31 +6,30 @@ Everything you ever wanted to know about Linux -stable releases Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree:
- It or an equivalent fix must already exist in Linus' tree (upstream).
- It must be obviously correct and tested.
- It cannot be bigger than 100 lines, with context.
- It must fix only one thing.
- It must fix a real bug that bothers people (not a, "This could be a
- problem..." type thing).
- It must fix a problem that causes a build error (but not for things
- marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
- security issue, or some "oh, that's not good" issue. In short, something
- critical.
- Serious issues as reported by a user of a distribution kernel may also
- be considered if they fix a notable performance or interactivity issue.
- As these fixes are not as obvious and have a higher risk of a subtle
- regression they should only be submitted by a distribution kernel
- maintainer and include an addendum linking to a bugzilla entry if it
- exists and additional information on the user-visible impact.
- New device IDs and quirks are also accepted.
- No "theoretical race condition" issues, unless an explanation of how the
- race can be exploited is also provided.
- It cannot contain any "trivial" fixes in it (spelling changes,
- whitespace cleanups, etc).
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` rules.
- It must follow the
- It or an equivalent fix must already exist in Linus' tree (upstream).
- It must either fix a real bug that bothers people or just add a device ID.
- To elaborate on the former:
- It fixes a problem like an oops, a hang, data corruption, a real security
issue, a hardware quirk, a build error (but not for things markedCONFIG_BROKEN), or some "oh, that's not good" issue. In short, somethingcritical.
- Serious issues as reported by a user of a distribution kernel may also
be considered if they fix a notable performance or interactivity issue.As these fixes are not as obvious and have a higher risk of a subtleregression they should only be submitted by a distribution kernelmaintainer and include an addendum linking to a bugzilla entry if itexists and additional information on the user-visible impact.
- No "This could be a problem..." type of things like a "theoretical race
condition", unless an explanation of how the bug can be exploited is alsoprovided.
- No "trivial" fixes without benefit for users (spelling changes, whitespace
cleanups, etc).Procedure for submitting patches to the -stable tree
Ah, it's nice to see that mainline also enforces the "must do one thing", I think when I originally wrote this, it didn't :)
Again, all looks great to me, I'll be glad to take it.
thanks,
greg k-h
Optimize the text flow to make things more straight forward to follow:
* remove a subheading without real purpose * after outlining the three options add a section that explains them in more detail; move the "Following the submission" text that set in the middle of this to a later place in the document * a few small clarifications along the way
CC: Greg KH gregkh@linuxfoundation.org CC: Sasha Levin sashal@kernel.org CC: Jonathan Corbet corbet@lwn.net Signed-off-by: Thorsten Leemhuis linux@leemhuis.info --- Documentation/process/stable-kernel-rules.rst | 156 +++++++++--------- 1 file changed, 81 insertions(+), 75 deletions(-)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 85d5d2368034..a9f36912b9dc 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -40,74 +40,45 @@ Procedure for submitting patches to the -stable tree process but should follow the procedures in :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
-For all other submissions, choose one of the following procedures ------------------------------------------------------------------ +There are three options to submit a change to -stable trees:
-.. _option_1: + 1. Add a 'stable tag' to the description of a patch you want to mainline. + 2. Ask the stable team to pick up a patch already mainlined. + 3. Submit a patch to the stable team that is equivalent to a mainlined patch.
-Option 1 -******** - -To have the patch automatically included in the stable tree, add the tag - -.. code-block:: none +The sections below describe each of the options in more detail.
- Cc: stable@vger.kernel.org - -in the sign-off area; to accompany a note to the stable team, use a shell-style -inline comment (see below for details). Once the patch is merged it will be -applied to the stable tree without anything else needing to be done by the -author or subsystem maintainer. - -.. _option_2: - -Option 2 -******** +:ref:`option_1` is **strongly** preferred, it is the easiest and most common. +:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed +worthy at the time it is submitted for mainline inclusion (for instance, because +it deserves more regression testing first). :ref:`option_3` is especially +useful if the original upstream patch needs to be adjusted to be included in +older series (for example the backport needs some special handling due to e.g. +API changes).
-After the patch has been merged to Linus' tree, send an email to -stable@vger.kernel.org containing the subject of the patch, the commit ID, -why you think it should be applied, and what kernel version you wish it to -be applied to. + .. _option_1:
-.. _option_3: - -Option 3 +Option 1 ********
-Send the patch, after verifying that it follows the above rules, to -stable@vger.kernel.org. You must note the upstream commit ID in the -changelog of your submission, as well as the kernel version you wish -it to be applied to. - -:ref:`option_1` is **strongly** preferred, is the easiest and most common. -:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed -worthy at the time it is applied to a public git tree (for instance, because -it deserves more regression testing first). :ref:`option_3` is especially -useful if the original upstream patch needs to be backported (for example -the backport needs some special handling due to e.g. API changes). - -Note that for :ref:`option_3`, if the patch deviates from the original -upstream patch (for example because it had to be backported) this must be very -clearly documented and justified in the patch description. - -The upstream commit ID must be specified with a separate line above the commit -text, like this: +To have a patch you submit for mainline inclusion automatically picked up for +the stable tree later, add the tag
.. code-block:: none
- commit <sha1> upstream. - -or alternatively: + Cc: stable@vger.kernel.org
-.. code-block:: none +in the sign-off area. Once the patch is mainlined it will be applied to the +stable tree without anything else needing to be done by the author or +subsystem maintainer.
- [ Upstream commit <sha1> ] +You can add a note with additional instructions using a shell-style inline +comment:
-Additionally, some patches submitted via :ref:`option_1` may have additional -patch prerequisites which can be cherry-picked. This can be specified in the -following format in the sign-off area: + * To specify any additional patch prerequisites for cherry picking use the + following format in the sign-off area:
-.. code-block:: none + .. code-block:: none
Cc: stable@vger.kernel.org # 3.3.x: a1f84a3: sched: Check for idle Cc: stable@vger.kernel.org # 3.3.x: 1b9508f: sched: Rate-limit newidle @@ -115,53 +86,88 @@ following format in the sign-off area: Cc: stable@vger.kernel.org # 3.3.x Signed-off-by: Ingo Molnar mingo@elte.hu
-The tag sequence has the meaning of: + The tag sequence has the meaning of:
-.. code-block:: none + .. code-block:: none
git cherry-pick a1f84a3 git cherry-pick 1b9508f git cherry-pick fd21073 git cherry-pick <this commit>
-Also, some patches may have kernel version prerequisites. This can be -specified in the following format in the sign-off area: + * For patches that may have kernel version prerequisites specify them using + the following format in the sign-off area:
-.. code-block:: none + .. code-block:: none
Cc: stable@vger.kernel.org # 3.3.x
-The tag has the meaning of: + The tag has the meaning of:
-.. code-block:: none + .. code-block:: none
git cherry-pick <this commit>
-For each "-stable" tree starting with the specified version. + For each "-stable" tree starting with the specified version.
-To delay pick up of patches submitted via :ref:`option_1`, use the following -format: + * To delay pick up of patches, use the following format:
-.. code-block:: none + .. code-block:: none
Cc: stable@vger.kernel.org # after 4 weeks in mainline
-For any other requests related to patches submitted via :ref:`option_1`, just -add a note to the stable tag. This for example can be used to point out known -problems: + * For any other requests, just add a note to the stable tag. This for example + can be used to point out known problems:
-.. code-block:: none + .. code-block:: none
Cc: stable@vger.kernel.org # see patch description, needs adjustments for >= 6.3
-Following the submission: +.. _option_2: + +Option 2 +******** + +If the patch already has been merged to Linus' tree, send an email to +stable@vger.kernel.org containing the subject of the patch, the commit ID, +why you think it should be applied, and what kernel version you wish it to +be applied to. + +.. _option_3: + +Option 3 +******** + +Send the patch, after verifying that it follows the above rules, to +stable@vger.kernel.org and mention the kernel version you wish it to be applied +to. + +When doing so, you must note the upstream commit ID in the changelog of your +submission with a separate line above the commit text, like this: + +.. code-block:: none + + commit <sha1> upstream. + +or alternatively: + +.. code-block:: none + + [ Upstream commit <sha1> ] + +If the patch submitted using this option 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. + +Following the submission +------------------------
- - The sender will receive an ACK when the patch has been accepted into the - queue, or a NAK if the patch is rejected. This response might take a few - days, according to the developer's schedules. - - If accepted, the patch will be added to the -stable queue, for review by - other developers and by the relevant subsystem maintainer. +The sender will receive an ACK when the patch has been accepted into the queue, +or a NAK if the patch is rejected. This response might take a few days, +according to the developer's schedules.
+If accepted, the patch will be added to the -stable queue, for review by other +developers and by the relevant subsystem maintainer.
Review cycle ------------
On Mon, Jul 10, 2023 at 07:10:13PM +0200, Thorsten Leemhuis wrote:
Optimize the text flow to make things more straight forward to follow:
- remove a subheading without real purpose
- after outlining the three options add a section that explains them in more detail; move the "Following the submission" text that set in the middle of this to a later place in the document
- a few small clarifications along the way
All of this churn makes it really hard to determine what the end result is. Do you have a before/after result anywhere?
Or maybe split this out into 3 different patches?
thanks,
greg k-h
On 10.07.23 19:10, Thorsten Leemhuis wrote:
This is a RFC and a bit rough for now. I only set down to create the first of the three patches. But while doing so I noticed a few things that seemed odd for me with my background on writing and editing texts. So I just quickly performed a few additional changes to fix those to see if the stable team would appreciate them, as this document is clearly their domain.
If those changes or even the initial patch are not welcomed, I'll simply drop them. I'd totally understand this, as texts like these are delicate and it's easy to accidentlly change the intent or the meaning while adjusting things in good faith.
At the same time I might be willing to do a few more changes, if people like the direction this takes and want a bit more fine tuning.
FWIW, in case anyone wonders what other changes I'd do, let me quote the text as it looks after these changes and give a few examples inline:
.. _stable_kernel_rules: Everything you ever wanted to know about Linux -stable releases =============================================================== Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree: - It or an equivalent fix must already exist in Linus' tree (upstream).
s/Linus' tree/mainline/g (just a detail, but I think that is the term more commonly used and known)
It must be obviously correct and tested.
It cannot be bigger than 100 lines, with context.
It must follow the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` rules.
It must either fix a real bug that bothers people or just add a device ID. To elaborate on the former:
- It fixes a problem like an oops, a hang, data corruption, a real security issue, a hardware quirk, a build error (but not for things marked CONFIG_BROKEN), or some "oh, that's not good" issue. In short, something critical.
s/ In short, something critical.//
Contradicts the "real bug that bothers people" somewhat and IMHO does not add anything. But maybe that's just me.
- Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.
/me wonders if that is really providing additional insight and if this s setting the bar a bit higher than it's really in practice
- No "This could be a problem..." type of things like a "theoretical race condition", unless an explanation of how the bug can be exploited is also provided.
- No "trivial" fixes without benefit for users (spelling changes, whitespace cleanups, etc).
Procedure for submitting patches to the -stable tree
.. note::
Security patches should not be handled (solely) by the -stable review process but should follow the procedures in :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
There are three options to submit a change to -stable trees:
- Add a 'stable tag' to the description of a patch you want to mainline.
- Ask the stable team to pick up a patch already mainlined.
- Submit a patch to the stable team that is equivalent to a mainlined patch.
The sections below describe each of the options in more detail.
:ref:`option_1` is **strongly** preferred, it is the easiest and most common. :ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed worthy at the time it is submitted for mainline inclusion (for instance, because it deserves more regression testing first). :ref:`option_3` is especially useful if the original upstream patch needs to be adjusted to be included in older series (for example the backport needs some special handling due to e.g. API changes).
Tweaked para:
:ref:`option_1` is **strongly** preferred, it is the easiest and most common. :ref:`option_2` is meant for changes that were not deemed wort including in stable at the time it was submitted for mainline inclusion (for instance, because the full scale of the problem was not yet known). :ref:`option_3` is an alternative to the two earlier options for cases where a mainlined patch needs adjustments to apply in older series (for example due to API changes).
.. _option_1:
Option 1
To have a patch you submit for mainline inclusion automatically picked up for the stable tree later, add the tag
.. code-block:: none
Cc: stable@vger.kernel.orgin the sign-off area. Once the patch is mainlined it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer.
You can add a note with additional instructions using a shell-style inline comment:
To specify any additional patch prerequisites for cherry picking use the following format in the sign-off area:
.. code-block:: none
Cc: stable@vger.kernel.org # 3.3.x: a1f84a3: sched: Check for idle Cc: stable@vger.kernel.org # 3.3.x: 1b9508f: sched: Rate-limit newidle Cc: stable@vger.kernel.org # 3.3.x: fd21073: sched: Fix affinity logic Cc: stable@vger.kernel.org # 3.3.x Signed-off-by: Ingo Molnar mingo@elte.hu
The tag sequence has the meaning of:
.. code-block:: none
git cherry-pick a1f84a3 git cherry-pick 1b9508f git cherry-pick fd21073 git cherry-pick <this commit>
For patches that may have kernel version prerequisites specify them using the following format in the sign-off area:
.. code-block:: none
Cc: stable@vger.kernel.org # 3.3.x
The tag has the meaning of:
.. code-block:: none
git cherry-pick <this commit>
For each "-stable" tree starting with the specified version.
/me wonders if something like a "note, such tagging is unnecessary if the appropriate version can be derived from a Fixes: tag" would be appropriate and worth it here
To delay pick up of patches, use the following format:
.. code-block:: none
Cc: stable@vger.kernel.org # after 4 weeks in mainline
For any other requests, just add a note to the stable tag. This for example can be used to point out known problems:
.. code-block:: none
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for >= 6.3.. _option_2:
Option 2
If the patch already has been merged to Linus' tree, send an email to stable@vger.kernel.org containing the subject of the patch, the commit ID, why you think it should be applied, and what kernel version you wish it to be applied to.
.. _option_3:
Option 3
Send the patch, after verifying that it follows the above rules, to stable@vger.kernel.org and mention the kernel version you wish it to be applied to.
When doing so, you must note the upstream commit ID in the changelog of your submission with a separate line above the commit text, like this:
.. code-block:: none
commit <sha1> upstream.or alternatively:
.. code-block:: none
[ Upstream commit <sha1> ]If the patch submitted using this option 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.
Following the submission
The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer's schedules.
s/developer's schedules/schedules of the stable team members/
If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer. [...]
That's it. Ciao, Thorsten
On Mon, Jul 10, 2023 at 07:18:43PM +0200, Thorsten Leemhuis wrote:
On 10.07.23 19:10, Thorsten Leemhuis wrote:
This is a RFC and a bit rough for now. I only set down to create the first of the three patches. But while doing so I noticed a few things that seemed odd for me with my background on writing and editing texts. So I just quickly performed a few additional changes to fix those to see if the stable team would appreciate them, as this document is clearly their domain.
If those changes or even the initial patch are not welcomed, I'll simply drop them. I'd totally understand this, as texts like these are delicate and it's easy to accidentlly change the intent or the meaning while adjusting things in good faith.
At the same time I might be willing to do a few more changes, if people like the direction this takes and want a bit more fine tuning.
FWIW, in case anyone wonders what other changes I'd do, let me quote the text as it looks after these changes and give a few examples inline:
.. _stable_kernel_rules: Everything you ever wanted to know about Linux -stable releases =============================================================== Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree: - It or an equivalent fix must already exist in Linus' tree (upstream).s/Linus' tree/mainline/g (just a detail, but I think that is the term more commonly used and known)
Fair enough.
It must be obviously correct and tested.
It cannot be bigger than 100 lines, with context.
It must follow the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` rules.
It must either fix a real bug that bothers people or just add a device ID. To elaborate on the former:
- It fixes a problem like an oops, a hang, data corruption, a real security issue, a hardware quirk, a build error (but not for things marked CONFIG_BROKEN), or some "oh, that's not good" issue. In short, something critical.
s/ In short, something critical.//
Contradicts the "real bug that bothers people" somewhat and IMHO does not add anything. But maybe that's just me.
Agreed, it can be dropped.
- Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.
/me wonders if that is really providing additional insight and if this s setting the bar a bit higher than it's really in practice
Let's leave this as-is for now. I much prefer to take patches that have lived in a distro because they obviously fix issues and have been tested in the backported kernel tree already.
So let's keep this please.
- No "This could be a problem..." type of things like a "theoretical race condition", unless an explanation of how the bug can be exploited is also provided.
- No "trivial" fixes without benefit for users (spelling changes, whitespace cleanups, etc).
Procedure for submitting patches to the -stable tree
.. note::
Security patches should not be handled (solely) by the -stable review process but should follow the procedures in :ref:`Documentation/process/security-bugs.rst <securitybugs>`.
There are three options to submit a change to -stable trees:
- Add a 'stable tag' to the description of a patch you want to mainline.
- Ask the stable team to pick up a patch already mainlined.
- Submit a patch to the stable team that is equivalent to a mainlined patch.
The sections below describe each of the options in more detail.
:ref:`option_1` is **strongly** preferred, it is the easiest and most common. :ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed worthy at the time it is submitted for mainline inclusion (for instance, because it deserves more regression testing first). :ref:`option_3` is especially useful if the original upstream patch needs to be adjusted to be included in older series (for example the backport needs some special handling due to e.g. API changes).
Tweaked para:
:ref:`option_1` is **strongly** preferred, it is the easiest and most common.
You're just changing line lengths now :)
:ref:`option_2` is meant for changes that were not deemed wort
"worthy"?
including in stable at the time it was submitted for mainline inclusion (for instance, because the full scale of the problem was not yet known).
Usually this happens because people forgot, or didn't think about it, "deemed worthy" is not normal from what I can tell.
:ref:`option_3` is an alternative to the two earlier options for cases where a mainlined patch needs adjustments to apply in older series (for example due to API changes).
I like this change.
.. _option_1:
Option 1
To have a patch you submit for mainline inclusion automatically picked up for the stable tree later, add the tag
.. code-block:: none
Cc: stable@vger.kernel.orgin the sign-off area. Once the patch is mainlined it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer.
You can add a note with additional instructions using a shell-style inline comment:
To specify any additional patch prerequisites for cherry picking use the following format in the sign-off area:
.. code-block:: none
Cc: stable@vger.kernel.org # 3.3.x: a1f84a3: sched: Check for idle Cc: stable@vger.kernel.org # 3.3.x: 1b9508f: sched: Rate-limit newidle Cc: stable@vger.kernel.org # 3.3.x: fd21073: sched: Fix affinity logic Cc: stable@vger.kernel.org # 3.3.x Signed-off-by: Ingo Molnar mingo@elte.hu
The tag sequence has the meaning of:
.. code-block:: none
git cherry-pick a1f84a3 git cherry-pick 1b9508f git cherry-pick fd21073 git cherry-pick <this commit>
For patches that may have kernel version prerequisites specify them using the following format in the sign-off area:
.. code-block:: none
Cc: stable@vger.kernel.org # 3.3.x
The tag has the meaning of:
.. code-block:: none
git cherry-pick <this commit>
For each "-stable" tree starting with the specified version.
/me wonders if something like a "note, such tagging is unnecessary if the appropriate version can be derived from a Fixes: tag" would be appropriate and worth it here
Yes, possibly.
To delay pick up of patches, use the following format:
.. code-block:: none
Cc: stable@vger.kernel.org # after 4 weeks in mainline
For any other requests, just add a note to the stable tag. This for example can be used to point out known problems:
.. code-block:: none
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for >= 6.3.. _option_2:
Option 2
If the patch already has been merged to Linus' tree, send an email to stable@vger.kernel.org containing the subject of the patch, the commit ID, why you think it should be applied, and what kernel version you wish it to be applied to.
.. _option_3:
Option 3
Send the patch, after verifying that it follows the above rules, to stable@vger.kernel.org and mention the kernel version you wish it to be applied to.
When doing so, you must note the upstream commit ID in the changelog of your submission with a separate line above the commit text, like this:
.. code-block:: none
commit <sha1> upstream.or alternatively:
.. code-block:: none
[ Upstream commit <sha1> ]If the patch submitted using this option 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.
Following the submission
The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer's schedules.
s/developer's schedules/schedules of the stable team members/
Yes, good catch!
Thanks for looking at this document, much appreciated.
greg k-h
On 10.07.23 21:50, Greg KH wrote:
On Mon, Jul 10, 2023 at 07:18:43PM +0200, Thorsten Leemhuis wrote:
On 10.07.23 19:10, Thorsten Leemhuis wrote:
It must either fix a real bug that bothers people or just add a device ID. To elaborate on the former:
- It fixes a problem like an oops, a hang, data corruption, a real security issue, a hardware quirk, a build error (but not for things marked CONFIG_BROKEN), or some "oh, that's not good" issue. In short, something critical.
s/ In short, something critical.//
Contradicts the "real bug that bothers people" somewhat and IMHO does not add anything. But maybe that's just me.
Agreed, it can be dropped.
Thx for your feedback. I'll merge this bit into the second patch and will send a v2 with just patch 1 or 2; and then will try to find a way to handle all the other bits with a series that make it easier to see what's changing.
Ciao, Thorsten
On Mon, Jul 10, 2023 at 07:18:43PM +0200, Thorsten Leemhuis wrote:
On 10.07.23 19:10, Thorsten Leemhuis wrote:
For patches that may have kernel version prerequisites specify them using the following format in the sign-off area:
.. code-block:: none
Cc: stable@vger.kernel.org # 3.3.x
The tag has the meaning of:
.. code-block:: none
git cherry-pick <this commit>
For each "-stable" tree starting with the specified version.
/me wonders if something like a "note, such tagging is unnecessary if the appropriate version can be derived from a Fixes: tag" would be appropriate and worth it here
Having these comments in the patch itself makes it easier to determine whether a fix addresses a recent regression or an issue that's been around since forever without having to copy-paste and look up each commit in the Fixes tag(s).
Johan
On 11.07.23 10:42, Johan Hovold wrote:
On Mon, Jul 10, 2023 at 07:18:43PM +0200, Thorsten Leemhuis wrote:
On 10.07.23 19:10, Thorsten Leemhuis wrote:
For patches that may have kernel version prerequisites specify them using the following format in the sign-off area:
.. code-block:: none
Cc: stable@vger.kernel.org # 3.3.x
The tag has the meaning of:
.. code-block:: none
git cherry-pick <this commit>
For each "-stable" tree starting with the specified version.
/me wonders if something like a "note, such tagging is unnecessary if the appropriate version can be derived from a Fixes: tag" would be appropriate and worth it here
Having these comments in the patch itself makes it easier to determine whether a fix addresses a recent regression or an issue that's been around since forever without having to copy-paste and look up each commit in the Fixes tag(s).
Hmmm. But that can be misleading, as something like "Cc: stable@vger.kernel.org # 3.3.x" might only have been used because the submitter only tested if the change applies and works there while not bothering with earlier kernels; similar things can happen if 3.2 and earlier required changes to the patch due to API changes or file movements the submitter was not willing to handle.
But I don't care. I already integrated a change like outlined earlier in my local WIP document, but I can quickly remove it again.
Ciao, Thorsten
On Mon, Jul 10, 2023 at 07:10:10PM +0200, Thorsten Leemhuis wrote:
This is a RFC and a bit rough for now. I only set down to create the first of the three patches. But while doing so I noticed a few things that seemed odd for me with my background on writing and editing texts. So I just quickly performed a few additional changes to fix those to see if the stable team would appreciate them, as this document is clearly their domain.
If those changes or even the initial patch are not welcomed, I'll simply drop them. I'd totally understand this, as texts like these are delicate and it's easy to accidentlly change the intent or the meaning while adjusting things in good faith.
At the same time I might be willing to do a few more changes, if people like the direction this takes and want a bit more fine tuning.
I do like it, many thanks for taking the time to do this work, it's much appreciated.
If you resend the first 2 as a non-RFC patch, I'll be glad to queue up, the last one needs some more work as mentioned.
thanks,
greg k-h
On 10.07.23 21:51, Greg KH wrote:
On Mon, Jul 10, 2023 at 07:10:10PM +0200, Thorsten Leemhuis wrote:
This is a RFC and a bit rough for now. I only set down to create the first of the three patches. But while doing so I noticed a few things that seemed odd for me with my background on writing and editing texts. So I just quickly performed a few additional changes to fix those to see if the stable team would appreciate them, as this document is clearly their domain.
If those changes or even the initial patch are not welcomed, I'll simply drop them. I'd totally understand this, as texts like these are delicate and it's easy to accidentlly change the intent or the meaning while adjusting things in good faith.
At the same time I might be willing to do a few more changes, if people like the direction this takes and want a bit more fine tuning.
I do like it, many thanks for taking the time to do this work, it's much appreciated.
If you resend the first 2 as a non-RFC patch,
BTW: thx again for your uplifting feedback! And in case anyone missed it, I send those two patches out yesterday here: https://lore.kernel.org/all/cover.1689056247.git.linux@leemhuis.info/
the last one needs some more work as mentioned.
I have that one in a separate branch now and spitted into four patches; the first three basically move text around, which results in a much cleaner diff for the last patch that contains actual content changes. While working on the latter I noticed one more thing:
``` .. warning:: The -stable-rc tree is a snapshot in time of the stable-queue tree and will change frequently, hence will be rebased often. It should only be used for testing purposes (e.g. to be consumed by CI systems). ```
That sounded a bit odd to me, as it will scare people away that want to test stable -rc's using git; and I think it doesn't match current practices. I'll thus likely change the text to something like this, unless I'm missing something or someone has a better idea: ``` .. warning:: The branches in the -stable-rc tree are rebased each time a new -rc is released, as they are created by taking the latest release and applying the patches from the stable-queue on top. ```
Ciao, Thorsten
On Wed, Jul 12, 2023 at 11:30:30AM +0200, Thorsten Leemhuis wrote:
On 10.07.23 21:51, Greg KH wrote:
On Mon, Jul 10, 2023 at 07:10:10PM +0200, Thorsten Leemhuis wrote:
This is a RFC and a bit rough for now. I only set down to create the first of the three patches. But while doing so I noticed a few things that seemed odd for me with my background on writing and editing texts. So I just quickly performed a few additional changes to fix those to see if the stable team would appreciate them, as this document is clearly their domain.
If those changes or even the initial patch are not welcomed, I'll simply drop them. I'd totally understand this, as texts like these are delicate and it's easy to accidentlly change the intent or the meaning while adjusting things in good faith.
At the same time I might be willing to do a few more changes, if people like the direction this takes and want a bit more fine tuning.
I do like it, many thanks for taking the time to do this work, it's much appreciated.
If you resend the first 2 as a non-RFC patch,
BTW: thx again for your uplifting feedback! And in case anyone missed it, I send those two patches out yesterday here: https://lore.kernel.org/all/cover.1689056247.git.linux@leemhuis.info/
the last one needs some more work as mentioned.
I have that one in a separate branch now and spitted into four patches; the first three basically move text around, which results in a much cleaner diff for the last patch that contains actual content changes. While working on the latter I noticed one more thing:
.. warning:: The -stable-rc tree is a snapshot in time of the stable-queue tree and will change frequently, hence will be rebased often. It should only be used for testing purposes (e.g. to be consumed by CI systems).That sounded a bit odd to me, as it will scare people away that want to test stable -rc's using git;
They are only there for people who _DO_ want to test stable -rc's using git.
and I think it doesn't match current practices.
No, it's pretty correct, what does not match? It gets rebased all the time.
I'll thus likely change the text to something like this, unless I'm missing something or someone has a better idea:
.. warning:: The branches in the -stable-rc tree are rebased each time a new -rc is released, as they are created by taking the latest release and applying the patches from the stable-queue on top.
Yes, that is true, but they are also rebased sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier.
These are ONLY for CI systems to use, nothing else should be touching them. So I think the current text is correct, what am I missing?
thanks,
greg k-h
On 12.07.23 17:16, Greg KH wrote:
On Wed, Jul 12, 2023 at 11:30:30AM +0200, Thorsten Leemhuis wrote:
While working on the latter I noticed one more thing:
.. warning:: The -stable-rc tree is a snapshot in time of the stable-queue tree and will change frequently, hence will be rebased often. It should only be used for testing purposes (e.g. to be consumed by CI systems).[...]
I'll thus likely change the text to something like this, unless I'm missing something or someone has a better idea:
.. warning:: The branches in the -stable-rc tree are rebased each time a new -rc is released, as they are created by taking the latest release and applying the patches from the stable-queue on top.Yes, that is true, but they are also rebased sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier.
These are ONLY for CI systems to use, nothing else should be touching them. So I think the current text is correct, what am I missing?
That I misunderstood things and forgot about the "rebased sometimes in intermediate places" aspect I once knew about. Sorry. I'll leave the text as it is then.
Nevertheless makes me wonder: is that strategy wise in times when some ordinary users and some distributions are building kernels straight from git repos instead of tarballs? I'm one of those, as I distribute stable-rc packages for Fedora here: https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
And the "rebased sometimes in intermediate places" aspect complicated things for me (my scripts handle that and apparently I forgot about that since I wrote them; uhhps :-/ ).
But whatever, not that important, feel free to ignore this remark. And I can see why you are doing it the way you do, too.
Thx for you helpful feedback!
Ciao, Thorsten
On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
On 12.07.23 17:16, Greg KH wrote:
On Wed, Jul 12, 2023 at 11:30:30AM +0200, Thorsten Leemhuis wrote:
While working on the latter I noticed one more thing:
.. warning:: The -stable-rc tree is a snapshot in time of the stable-queue tree and will change frequently, hence will be rebased often. It should only be used for testing purposes (e.g. to be consumed by CI systems).[...]
I'll thus likely change the text to something like this, unless I'm missing something or someone has a better idea:
.. warning:: The branches in the -stable-rc tree are rebased each time a new -rc is released, as they are created by taking the latest release and applying the patches from the stable-queue on top.Yes, that is true, but they are also rebased sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier.
These are ONLY for CI systems to use, nothing else should be touching them. So I think the current text is correct, what am I missing?
That I misunderstood things and forgot about the "rebased sometimes in intermediate places" aspect I once knew about. Sorry. I'll leave the text as it is then.
Nevertheless makes me wonder: is that strategy wise in times when some ordinary users and some distributions are building kernels straight from git repos instead of tarballs? I'm one of those, as I distribute stable-rc packages for Fedora here: https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
As we keep the patches in quilt, not git, it's the best we can do. The -rc releases are never a straight-line if we have to do multiple ones, we remove patches in the middle, add them at the end or beginning, and sometimes even change existing ones.
All of this is stuff that a linear history tool like git can't really model well, so we keep a quilt series of the patches in git for anyone that want to generate the tree themselves, and we provide the -rc git tree for those that don't want to generate it and can live with the constant rebasing.
thanks,
greg k-h
On 12.07.23 21:00, Greg KH wrote:
On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
On 12.07.23 17:16, Greg KH wrote:
[...]
.. warning:: The branches in the -stable-rc tree are rebased each time a new -rc is released, as they are created by taking the latest release and applying the patches from the stable-queue on top.
Yes, that is true, but they are also rebased sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier.
[...]
Nevertheless makes me wonder: is that strategy wise in times when some ordinary users and some distributions are building kernels straight from git repos instead of tarballs? I'm one of those, as I distribute stable-rc packages for Fedora here: https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
As we keep the patches in quilt, not git, it's the best we can do. The -rc releases are never a straight-line if we have to do multiple ones, we remove patches in the middle, add them at the end or beginning, and sometimes even change existing ones.
All of this is stuff that a linear history tool like git can't really model well, so we keep a quilt series of the patches in git for anyone that want to generate the tree themselves, and we provide the -rc git tree for those that don't want to generate it and can live with the constant rebasing.
/me first didn't want to reply, as this is not really important, but then reconsidered; again, feel free to just ignore this
FWIW, I do not consider that rebasing to be problem at all; it are those rebases "sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier" make things this slightly annoying bit harder when you want to distribute stable-rc releases to users.
But as I said, I can fully understand why you do those as well. I just with there was a way to reliably get a -rc release from git as well. Simply tagging them when you do a -rc release would solve all that. Is that maybe something that could be easily added to your -rc release scripts?
/me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable but failed to find the -rc release script :-/
Whatever, as I said, not really important. :-D Have a nice day everyone!
Ciao, Thorsten
On Thu, Jul 13, 2023 at 10:48:14AM +0200, Thorsten Leemhuis wrote:
On 12.07.23 21:00, Greg KH wrote:
On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
On 12.07.23 17:16, Greg KH wrote:
[...]
.. warning:: The branches in the -stable-rc tree are rebased each time a new -rc is released, as they are created by taking the latest release and applying the patches from the stable-queue on top.
Yes, that is true, but they are also rebased sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier.
[...]
Nevertheless makes me wonder: is that strategy wise in times when some ordinary users and some distributions are building kernels straight from git repos instead of tarballs? I'm one of those, as I distribute stable-rc packages for Fedora here: https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
As we keep the patches in quilt, not git, it's the best we can do. The -rc releases are never a straight-line if we have to do multiple ones, we remove patches in the middle, add them at the end or beginning, and sometimes even change existing ones.
All of this is stuff that a linear history tool like git can't really model well, so we keep a quilt series of the patches in git for anyone that want to generate the tree themselves, and we provide the -rc git tree for those that don't want to generate it and can live with the constant rebasing.
/me first didn't want to reply, as this is not really important, but then reconsidered; again, feel free to just ignore this
FWIW, I do not consider that rebasing to be problem at all; it are those rebases "sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier" make things this slightly annoying bit harder when you want to distribute stable-rc releases to users.
But as I said, I can fully understand why you do those as well. I just with there was a way to reliably get a -rc release from git as well. Simply tagging them when you do a -rc release would solve all that. Is that maybe something that could be easily added to your -rc release scripts?
I can add a tag, but it would have to be a tag that can be rebased, and git doesn't like that very well :)
/me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable but failed to find the -rc release script :-/
Hah, no github, it's at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree...
But I don't think tags will help much. I'll let anyone who actually runs a CI that uses this to speak up to see if it would before adding them.
Also, as proof this works, I just got a report of someone testing the queues and finding a problem at the moment, before we sent anything out for review. So this is working well today.
thanks,
greg k-h
On Thu, Jul 13, 2023 at 05:06:22PM +0200, Greg KH wrote:
On Thu, Jul 13, 2023 at 10:48:14AM +0200, Thorsten Leemhuis wrote:
On 12.07.23 21:00, Greg KH wrote:
On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
On 12.07.23 17:16, Greg KH wrote:
[...]
.. warning:: The branches in the -stable-rc tree are rebased each time a new -rc is released, as they are created by taking the latest release and applying the patches from the stable-queue on top.
Yes, that is true, but they are also rebased sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier.
[...]
Nevertheless makes me wonder: is that strategy wise in times when some ordinary users and some distributions are building kernels straight from git repos instead of tarballs? I'm one of those, as I distribute stable-rc packages for Fedora here: https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
As we keep the patches in quilt, not git, it's the best we can do. The -rc releases are never a straight-line if we have to do multiple ones, we remove patches in the middle, add them at the end or beginning, and sometimes even change existing ones.
All of this is stuff that a linear history tool like git can't really model well, so we keep a quilt series of the patches in git for anyone that want to generate the tree themselves, and we provide the -rc git tree for those that don't want to generate it and can live with the constant rebasing.
/me first didn't want to reply, as this is not really important, but then reconsidered; again, feel free to just ignore this
FWIW, I do not consider that rebasing to be problem at all; it are those rebases "sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier" make things this slightly annoying bit harder when you want to distribute stable-rc releases to users.
But as I said, I can fully understand why you do those as well. I just with there was a way to reliably get a -rc release from git as well. Simply tagging them when you do a -rc release would solve all that. Is that maybe something that could be easily added to your -rc release scripts?
I can add a tag, but it would have to be a tag that can be rebased, and git doesn't like that very well :)
I figure the desired tagging behaviour is that you do it when the email is sent out for a corresponding version & so the tag "should" not need to be rebased?
/me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable but failed to find the -rc release script :-/
Hah, no github, it's at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree...
But I don't think tags will help much. I'll let anyone who actually runs a CI that uses this to speak up to see if it would before adding them.
I'm not sure that it is particularly valuable to the usual flow of testing what is about to come down the tracks, at least in my simple case where I trigger it based on the -rc emails or whenever something else interesting happens, like a patch being dropped that breaks the build.
I suppose it may be useful if an issue presents itself but disappears when a backport is dropped from the queue & some developers are interested in figuring out why the backport went awry?
Other than that, I'm not sure what the value is in "I just with [sic] there was a way to reliably get a -rc release from git as well", in _my_ CI use case I don't care about the superseded stable -rc versions, just whatever is about to be released.
Others with more complex CI infrastructure, like Linaro etc, might feel differently :)
Also, as proof this works, I just got a report of someone testing the queues and finding a problem at the moment, before we sent anything out for review. So this is working well today.
thanks,
greg k-h
On 13.07.23 17:39, Conor Dooley wrote:
On Thu, Jul 13, 2023 at 05:06:22PM +0200, Greg KH wrote:
On Thu, Jul 13, 2023 at 10:48:14AM +0200, Thorsten Leemhuis wrote:
On 12.07.23 21:00, Greg KH wrote:
On Wed, Jul 12, 2023 at 07:02:34PM +0200, Thorsten Leemhuis wrote:
On 12.07.23 17:16, Greg KH wrote:
[...]
> .. warning:: > The branches in the -stable-rc tree are rebased each time a new -rc > is released, as they are created by taking the latest release and > applying the patches from the stable-queue on top.
Yes, that is true, but they are also rebased sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier.
[...]
Nevertheless makes me wonder: is that strategy wise in times when some ordinary users and some distributions are building kernels straight from git repos instead of tarballs? I'm one of those, as I distribute stable-rc packages for Fedora here: https://copr.fedorainfracloud.org/groups/g/kernel-vanilla/coprs/
As we keep the patches in quilt, not git, it's the best we can do. The -rc releases are never a straight-line if we have to do multiple ones, we remove patches in the middle, add them at the end or beginning, and sometimes even change existing ones.
All of this is stuff that a linear history tool like git can't really model well, so we keep a quilt series of the patches in git for anyone that want to generate the tree themselves, and we provide the -rc git tree for those that don't want to generate it and can live with the constant rebasing.
/me first didn't want to reply, as this is not really important, but then reconsidered; again, feel free to just ignore this
FWIW, I do not consider that rebasing to be problem at all; it are those rebases "sometimes in intermediate places, before a -rc is released, just to give CI systems a chance to test easier" make things this slightly annoying bit harder when you want to distribute stable-rc releases to users.
But as I said, I can fully understand why you do those as well. I just with there was a way to reliably get a -rc release from git as well. Simply tagging them when you do a -rc release would solve all that. Is that maybe something that could be easily added to your -rc release scripts?
I can add a tag, but it would have to be a tag that can be rebased, and git doesn't like that very well :)
I figure the desired tagging behaviour is that you do it when the email is sent out for a corresponding version & so the tag "should" not need to be rebased?
Yup, exactly, that's what I meant, as that makes it possible to get the same state as the tarball by simply doing a "git checkout v6.4.4-rc1", even if the linux-6.4.y branch in the stable-rc repo changed.
And CI systems should not care.
/me looks at https://github.com/gregkh/gregkh-linux/tree/master/stable but failed to find the -rc release script :-/
Hah, no github, it's at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree...
But I don't think tags will help much. I'll let anyone who actually runs a CI that uses this to speak up to see if it would before adding them.
I'm not sure that it is particularly valuable to the usual flow of testing what is about to come down the tracks, at least in my simple case where I trigger it based on the -rc emails
My scripts instead wait for the tarballs to show up on kernel.org. :-D
or whenever something else interesting happens, like a patch being dropped that breaks the build.
I suppose it may be useful if an issue presents itself but disappears when a backport is dropped from the queue & some developers are interested in figuring out why the backport went awry?
Other than that, I'm not sure what the value is in "I just with [sic] there was a way to reliably get a -rc release from git as well", in _my_ CI use case I don't care about the superseded stable -rc versions, just whatever is about to be released.
Others with more complex CI infrastructure, like Linaro etc, might feel differently :)
Yeah, CI systems likely don't care much, but I distribute the proper stable-rc releases to ordinary users for simple testing in the wild; and it afaics would be good if they'd match the tarball in case a users runs into problems and reports them, as I fear people otherwise might quickly talk past each other...
Ciao, Thorsten
linux-stable-mirror@lists.linaro.org
-
Conor Dooley -
Greg KH -
Jani Nikula -
Johan Hovold -
Thorsten Leemhuis