docs: add a text about regressions to the Linux kernel's documentation
Subsystems (2)
v2 cover docs: add a text about regressions to the Linux kernel's documentation
'We don't cause regressions' might be the first rule of Linux kernel development, but it and other aspects of regressions nevertheless are hardly described in the Linux kernel's documentation. The following two patches change this by creating a document dedicated to the topic.
The second patch could easily be folded into the first one, but was kept separate, as it might be a bit controversial. This also allows the patch description to explain some backgrounds for this part of the document. Additionally, ACKs and Reviewed-by tags can be collected separately this way.
v2/RFC:
- a lot of small fixes, most are for spelling mistakes and grammar errors/problems pointed out in the review feedback I got so far
- add ACK for the series from Greg
v1/RFC (https://lore.kernel.org/linux-doc/[email protected]/):
- initial version
---
Hi! Here is a quick update to the patches I sent a few days with a lot of fixes, in case anyone has some spare cycles and looks for something to read over the weekend.
Ciao, Thorsten
Thorsten Leemhuis (2):
docs: add a document about regression handling
docs: regressions.rst: rules of thumb for handling regressions
Documentation/admin-guide/index.rst | 1 + Documentation/admin-guide/regressions.rst | 965 ++++++++++++++++++++++ MAINTAINERS | 1 + 3 files changed, 967 insertions(+) create mode 100644 Documentation/admin-guide/regressions.rst
base-commit: 82ca67321f55a8d1da6ac3ed611da3c32818bb37
Signature · 1 line
2.31.1
RFC PATCH v2 1/2 docs: add a document about regression handling
Create a document explaining various aspects around regression handling and tracking both for users and developers. Among others describe the first rule of Linux kernel development and what it means in practice. Also explain what a regression actually is and how to report one properly. The text additionally provides a brief introduction to the bot the kernel's regression tracker uses to facilitate his work. To sum things up, provide a few quotes from Linus to show how serious he takes regressions.
--- Documentation/admin-guide/index.rst | 1 + Documentation/admin-guide/regressions.rst | 886 ++++++++++++++++++++++ MAINTAINERS | 1 + 3 files changed, 888 insertions(+) create mode 100644 Documentation/admin-guide/regressions.rst
Documentation/admin-guide/index.rst +1 -0
@@ -36,6 +36,7 @@ problems and bugs in particular. reporting-issues security-bugs + regressions bug-hunting bug-bisect tainted-kernels
Documentation/admin-guide/regressions.rst new file +886 -0
886 lines not on this page · raw message
MAINTAINERS +1 -0
@@ -10351,6 +10351,7 @@ KERNEL REGRESSIONS M: Thorsten Leemhuis <[email protected]> L: [email protected] S: Supported +F: Documentation/admin-guide/regressions.rst KERNEL SELFTEST FRAMEWORK M: Shuah Khan <[email protected]>
Signature · 1 line
2.31.1
Re: [RFC PATCH v2 1/2] docs: add a document about regression handling
Quoted 78 lines · Thorsten Leemhuis
Create a document explaining various aspects around regression handling and tracking both for users and developers. Among others describe the first rule of Linux kernel development and what it means in practice. Also explain what a regression actually is and how to report one properly. The text additionally provides a brief introduction to the bot the kernel's regression tracker uses to facilitate his work. To sum things up, provide a few quotes from Linus to show how serious he takes regressions.
Signed-off-by Thorsten Leemhuis <[email protected]>--- Documentation/admin-guide/index.rst | 1 + Documentation/admin-guide/regressions.rst | 886 ++++++++++++++++++++++ MAINTAINERS | 1 + 3 files changed, 888 insertions(+)create mode 100644
Documentation/admin-guide/regressions.rstDocumentation/admin-guide/index.rst +1
-0@@ -36,6 +36,7 @@ problems and bugs in particular. reporting-issues security-bugs + regressions bug-hunting bug-bisect tainted-kernelsDocumentation/admin-guide/regressions.rst new file +43
-0@@ -0,0 +1,886 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. + If you want to distribute this text under CC-BY-4.0 only, please use 'The + Linux kernel developers' for author attribution and link this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/regressions.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. + + +Regressions ++++++++++++ + +The first rule of Linux kernel development: '*We don't cause regressions*'. +Linux founder and lead developer Linus Torvalds strictly enforces the rule +himself. This document describes what this means in practice and how the Linux +kernel's development model ensures all reported regressions are addressed; it +covers aspects relevant for both users and developers. + +The important bits for people affected by regressions +===================================================== + +It's a regression if something running fine with one Linux kernel works worse or +not at all with a newer version. Note, the newer kernel has to be compiled using +a similar configuration -- for this and other fine print, check out below +section "What is a 'regression' and what is the 'no regressions rule'?". + +Report your regression as outlined in +`Documentation/admin-guide/reporting-issues.rst`, it already covers all aspects +important for regressions. Below section "How do I report a regression?" +highlights them for convenience. + +The most important aspect: CC or forward the report to `the regression mailing +list <https://lore.kernel.org/regressions/>`_ ([email protected]). +When doing so, consider mentioning the version range where the regression +started using a paragraph like this:: + + #regzbot introduced v5.13..v5.14-rc1 + +The Linux kernel regression tracking bot 'regzbot' will then add the report to +the list of tracked regressions. This is in your interest, as it brings the
Documentation/admin-guide/regressions.rst line 53
Quoted 10 lines
Documentation/admin-guide/regressions.rst new file +10
-0+report on the radar of people ensuring all regressions are acted upon in a +timely manner. + +The important bits for people fixing regressions +================================================ + +When receiving regression reports by mail, check if the reporter CCed `the +regression mailing list <https://lore.kernel.org/regressions/>`_ +([email protected]). If not, forward or bounce the report to the Linux +kernel's regression tracker ([email protected]), unless you plan on
I would have expected it to be the same mailing list ([email protected]), is this a typo maybe?
Regards,
Matthias
Re: [RFC PATCH v2 1/2] docs: add a document about regression handling
Quoted 12 lines · Matthias Brugger
Quoted 10 lines · Thorsten Leemhuis
Create a document explaining various aspects around regression handling and tracking both for users and developers. Among others describe the first rule of Linux kernel development and what it means in practice. Also explain what a regression actually is and how to report one properly. The text additionally provides a brief introduction to the bot the kernel's regression tracker uses to facilitate his work. To sum things up, provide a few quotes from Linus to show how serious he takes regressions.
Signed-off-by Thorsten Leemhuis <[email protected]>[...]
Quoted 13 lines
Quoted 10 lines
Documentation/admin-guide/regressions.rst new file +4
-0+The important bits for people fixing regressions +================================================ + +When receiving regression reports by mail, check if the reporter CCed`the
(quoted diff) +2
-0+regression mailing list <https://lore.kernel.org/regressions/>`_ +([email protected]). If not, forward or bounce the reportto the Linux
+kernel's regression tracker ([email protected]), unless you plan onI would have expected it to be the same mailing list ([email protected]), is this a typo maybe?
Thx for taking a look. Hmm. That's possible, but I (and the grep call I just ran) fail to spot the typo.
Maybe the wording is to confusing: [email protected] is the list, [email protected] is a dedicated email address I (the kernel's regression tracker) use for regression tracking (which reminds
me: maybe I should ask for a alias like [email protected] or [email protected]).
Ciao, Thorsten
Re: [RFC PATCH v2 1/2] docs: add a document about regression handling
Quoted 27 lines · Thorsten Leemhuis
Quoted 12 lines · Matthias Brugger
Quoted 10 lines · Thorsten Leemhuis
Create a document explaining various aspects around regression handling and tracking both for users and developers. Among others describe the first rule of Linux kernel development and what it means in practice. Also explain what a regression actually is and how to report one properly. The text additionally provides a brief introduction to the bot the kernel's regression tracker uses to facilitate his work. To sum things up, provide a few quotes from Linus to show how serious he takes regressions.
Signed-off-by Thorsten Leemhuis <[email protected]>[...]
Quoted 13 lines
Quoted 10 lines
Documentation/admin-guide/regressions.rst new file +4
-0+The important bits for people fixing regressions +================================================ + +When receiving regression reports by mail, check if the reporter CCed`the
(quoted diff) +2
-0+regression mailing list <https://lore.kernel.org/regressions/>`_ +([email protected]). If not, forward or bounce the reportto the Linux
+kernel's regression tracker ([email protected]), unless you plan onI would have expected it to be the same mailing list ([email protected]), is this a typo maybe?
Quoted 8 lines
Thx for taking a look. Hmm. That's possible, but I (and the grep call I just ran) fail to spot the typo.
Maybe the wording is to confusing: [email protected] is the list, [email protected] is a dedicated email address I (the kernel's regression tracker) use for regression tracking (which reminds
me: maybe I should ask for a alias like [email protected] or [email protected]).
Yes it's the wording then :)
Anyway I just wonder why you we should send the regression to the regressions email list, but only to the tracker email address. For me that's the confusing part. I'd expect to send it to the list as well and the tracker takes it from there. If for any reason someone does not want to send a regression to the list, then he can send it to the tracker directly. That's my understanding of how this works. If that's correct then I'd say we should just explain the difference.
Regards,
Matthias
Quoted 3 lines
Ciao, Thorsten
Re: [RFC PATCH v2 1/2] docs: add a document about regression handling
Quoted 38 lines · Matthias Brugger
Quoted 28 lines · Thorsten Leemhuis
Quoted 13 lines · Matthias Brugger
Quoted 11 lines · Thorsten Leemhuis
Create a document explaining various aspects around regression handling and tracking both for users and developers. Among others describe the first rule of Linux kernel development and what it means in practice. Also explain what a regression actually is and how to report one properly. The text additionally provides a brief introduction to the bot
the kernel's regression tracker uses to facilitate his work. To sum things up, provide a few quotes from Linus to show how serious he takes regressions.Signed-off-by Thorsten Leemhuis <[email protected]>[...]
Quoted 13 lines
Quoted 10 lines
Documentation/admin-guide/regressions.rst new file +4
-0+The important bits for people fixing regressions +================================================ + +When receiving regression reports by mail, check if the reporter CCed`the
(quoted diff) +2
-0+regression mailing list <https://lore.kernel.org/regressions/>`_ +([email protected]). If not, forward or bounce the reportto the Linux
+kernel's regression tracker ([email protected]), unless you plan onI would have expected it to be the same mailing list ([email protected]), is this a typo maybe?
Quoted 8 lines
Thx for taking a look. Hmm. That's possible, but I (and the grep call I just ran) fail to spot the typo.
Maybe the wording is to confusing: [email protected] is the list, [email protected] is a dedicated email address I (the kernel's regression tracker) use for regression tracking (which reminds
me: maybe I should ask for a alias like [email protected] or [email protected]).
Quoted 8 lines
Yes it's the wording then :)
Anyway I just wonder why you we should send the regression to the regressions email list, but only to the tracker email address. For me that's the confusing part. I'd expect to send it to the list as well and the tracker takes it from there. If for any reason someone does not want to send a regression to the list, then he can send it to the tracker directly. That's my understanding of how this works. If that's correct then I'd say we should just explain the difference.
You comments made be revisit the section and made me spot a few other issues I found less than ideal. So I rewrote it over the weekend (more than once, to be precise...). I hope this clears things up.
```
The important bits for people fixing regressions
================================================
When submitting fixes for regressions, add "Link:" tags pointing to all
places where the issue was reported, as tools like the Linux kernel
regression bot 'regzbot' heavily rely on these; these pointers are also
of great value for people looking into the issue some time in the
future, as explained in `Documentation/process/submitting-patches.rst`
and :ref:`Documentation/process/5.Posting.rst <development_posting>`::
Link:
https://lore.kernel.org/r/[email protected]/
Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
Let the Linux kernel's regression tracker and all other subscribers of
the `regression mailing list <https://lore.kernel.org/regressions/>`_
([email protected]) quickly known about newly reported
regressions:
* When receiving a mailed report that did not CC the list, immediately
send at least a brief "Reply-all" with the list CCed to get it into the
loop; also ensure its CCed on all future replies, in case it got lost.
* If you receive a report from a bug tracker, forward or bounce the
report to the list, unless the reporter followed
`Documentation/admin-guide/reporting-issues.rst` instructions and did it
already.
[Optional] Ensure the Linux kernel regression bot 'regzbot' tracks the
issue:
* For mailed reports, check if the reporter included a 'regzbot
command' like the ``#regzbot introduced v5.13..v5.14-rc1`` described
above. If not, send a reply with the regressions list in CC, which
includes a paragraph like the following:
#regzbot ^introduced v5.13..v5.14-rc1
Note, in this case there is a caret (^) before the `introduced` to
make regzbot treat the parent mail (the one you reply to) as the report
for the regression you want to see tracked.
Instead of specifying a version range you can also state a commit-id,
in case the reporter identified the culprit.
* When receiving a report from a bug tracker and forwarding it to the
regressions list (see above), include a paragraph like this:
#regzbot introduced: v5.13..v5.14-rc1
#regzbot from: Some N. Ice Human <[email protected]>
#regzbot monitor:
http://some.bugtracker.example.com/ticket?id=123456789
```Note, regzbot does not yet support "#regzbot from" and "#regzbot monitor <bugtracker>", but I wanted to work on that soon anyway -- and this text will likely take weeks before it hits mailine, so this shouldn't be a problem.
Ciao, Thorsten
Re: [RFC PATCH v2 1/2] docs: add a document about regression handling
Quoted 30 lines · Thorsten Leemhuis
Quoted 29 lines · Matthias Brugger
Quoted 28 lines · Thorsten Leemhuis
Quoted 26 lines · Matthias Brugger
Quoted 11 lines · Thorsten Leemhuis
Create a document explaining various aspects around regression handling and tracking both for users and developers. Among others describe the first rule of Linux kernel development and what it means in practice. Also explain what a regression actually is and how to report one properly. The text additionally provides a brief introduction to the bot
the kernel's regression tracker uses to facilitate his work. To sum things up, provide a few quotes from Linus to show how serious he takes regressions.Signed-off-by Thorsten Leemhuis <[email protected]>[...]
Quoted 10 lines
Documentation/admin-guide/regressions.rst new file +4
-0+The important bits for people fixing regressions +================================================ + +When receiving regression reports by mail, check if the reporter CCed`the
(quoted diff) +2
-0+regression mailing list <https://lore.kernel.org/regressions/>`_ +([email protected]). If not, forward or bounce the reportto the Linux
+kernel's regression tracker ([email protected]), unless you plan onI would have expected it to be the same mailing list ([email protected]), is this a typo maybe?
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Thx for taking a look. Hmm. That's possible, but I (and the grep call I just ran) fail to spot the typo.
I think that structure is much better, thanks!
Regards,
Matthias
Quoted 81 lines
Quoted 6 lines
Quoted 5 lines
Maybe the wording is to confusing: [email protected] is the list, [email protected] is a dedicated email address I (the kernel's regression tracker) use for regression tracking (which reminds
me: maybe I should ask for a alias like [email protected] or [email protected]).Quoted 8 lines
Yes it's the wording then :)
Anyway I just wonder why you we should send the regression to the regressions email list, but only to the tracker email address. For me that's the confusing part. I'd expect to send it to the list as well and the tracker takes it from there. If for any reason someone does not want to send a regression to the list, then he can send it to the tracker directly. That's my understanding of how this works. If that's correct then I'd say we should just explain the difference.You comments made be revisit the section and made me spot a few other issues I found less than ideal. So I rewrote it over the weekend (more than once, to be precise...). I hope this clears things up.
``` The important bits for people fixing regressions ================================================ When submitting fixes for regressions, add "Link:" tags pointing to all places where the issue was reported, as tools like the Linux kernel regression bot 'regzbot' heavily rely on these; these pointers are also of great value for people looking into the issue some time in the future, as explained in `Documentation/process/submitting-patches.rst` and :ref:`Documentation/process/5.Posting.rst <development_posting>`:: Link: https://lore.kernel.org/r/[email protected]/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890 Let the Linux kernel's regression tracker and all other subscribers of the `regression mailing list <https://lore.kernel.org/regressions/>`_ ([email protected]) quickly known about newly reported regressions: * When receiving a mailed report that did not CC the list, immediately send at least a brief "Reply-all" with the list CCed to get it into the loop; also ensure its CCed on all future replies, in case it got lost. * If you receive a report from a bug tracker, forward or bounce the report to the list, unless the reporter followed `Documentation/admin-guide/reporting-issues.rst` instructions and did it already. [Optional] Ensure the Linux kernel regression bot 'regzbot' tracks the issue: * For mailed reports, check if the reporter included a 'regzbot command' like the ``#regzbot introduced v5.13..v5.14-rc1`` described above. If not, send a reply with the regressions list in CC, which includes a paragraph like the following: #regzbot ^introduced v5.13..v5.14-rc1 Note, in this case there is a caret (^) before the `introduced` to make regzbot treat the parent mail (the one you reply to) as the report for the regression you want to see tracked. Instead of specifying a version range you can also state a commit-id, in case the reporter identified the culprit. * When receiving a report from a bug tracker and forwarding it to the regressions list (see above), include a paragraph like this: #regzbot introduced: v5.13..v5.14-rc1 #regzbot from: Some N. Ice Human <[email protected]> #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789 ```Note, regzbot does not yet support "#regzbot from" and "#regzbot monitor <bugtracker>", but I wanted to work on that soon anyway -- and this text will likely take weeks before it hits mailine, so this shouldn't be a problem.
Ciao, Thorsten
RFC PATCH v2 2/2 docs: regressions.rst: rules of thumb for handling regressions
In reply to Thorsten LeemhuisAdd a section with a few rules of thumb about how quickly regressions should be fixed. They are written after studying the quotes from Linus found in the modified document and especially influenced by statements like "Users are literally the _only_ thing that matters" and "without users, your program is not a program, it's a pointless piece of code that you might as well throw away". The author interpreted those in perspective to how the various Linux kernel series are maintained and what those practices might mean for users running into a regression when updating.
That for example lead to the paragraph starting with "Aim to get fixes for regressions mainlined within one week after identifying the culprit, if the regression was introduced in a stable/longterm release or the devel cycle for the latest mainline release". This is a pretty high bar, but on the other hand needed to not leave users out in the cold for to long. This can quickly happen, as the previous stable series is normally stamped "End of Life" about three or four weeks after a new mainline release, which makes a lot of users switch during this timeframe. Any of them risk running into regressions not promptly fixed; even worse, once the previous stable series is EOLed for real, users that face a regression might be left with only three options:
(1) continue running an outdated and thus potentially insecure kernel version from an abandoned stable series
(2) run the kernel with the regression
(3) downgrade to an earlier longterm series still supported
This is better avoided, as (1) puts users and their data in danger, (2) will only be possible if it's a minor regression that doesn't interfere with booting or serious usage, and (3) might be regression itself or impossible on the particular machine, as some users will require drivers or features only introduced after the latest longterm series took of.
In the end this lead to the "Aim to fix regression within one week" part. It also is the reason for the "Try to resolve any regressions introduced in the current development cycle before its end.".
---
Hi! A lot of developers are doing a good job in fixing regressions, but I noticed it sometimes takes many weeks to get even simple fixes for regressions merged. Most of the time this is due to one of these factors:
* it takes a long time to get the fix ready, as some developers apparently don't prioritize work on fixing regressions
* fully developed fixes linger in git trees of maintainers for weeks, sometimes even without the fix being in linux-next
This afaics is especially a problem for regressions introduced in mainline, but only found after a recent release or a stable kernel series derived from it. Sometimes fixes for these regressions are even left lying around for weeks until the next merge window, which contributes to a huge pile of fixes getting backported to stable and longterm releases during or shortly after merge windows. Asking developers to speed things up rarely helped, as people have different options on how fast regression fixes need to be developed and merged upstream.
That's why it would be a great help to my work as regression tracker if we had some rough written down guidelines for handling regressions, as proposed by the patch below. I'm well aware that the text sets a pretty high bar. That's because I approached the problem primarily from the point of a user, as can be seen by the patch description.
The text added by this patch likely will lead to some discussions, that's why I submit it separately from the rest of the new document on regressions, which is found in patch 1/2; I also CCed Linus on this patch and hope they state his opinion or ACK is. In the end I can easily tone this down or write something totally different: that's totally fine for me, I'm mainly interested in having some expectations roughly documented to get everyone on the same page.
--- Documentation/admin-guide/regressions.rst | 79 +++++++++++++++++++++++ 1 file changed, 79 insertions(+)
Documentation/admin-guide/regressions.rst +79 -0
@@ -64,6 +64,10 @@ list; add the aforementioned paragraph, just omit the caret (the ^) before the ``introduced``, which makes regzbot treat your mail (and not the one you reply to) as the report. +Try to fix regressions quickly once the culprit has been identified. Fixes for +most regressions should be mainlined within two weeks, but some should be +addressed within two or three days. + When submitting fixes for regressions, always include 'Link:' tags in the commit message that point to all places where the issue was reported, as explained in `Documentation/process/submitting-patches.rst` and
@@ -235,6 +239,81 @@ Alternatively to all the above you can just forward or bounce the report to the Linux kernel's regression tracker, but consider the downsides already outlined in the previous section. +How quickly should regressions be fixed? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Developers should fix any reported regression as quickly as possible, to provide +affected users with a solution in a timely manner and prevent more users from +running into the issue; nevertheless developers need to take enough time and +care to ensure regression fixes do not cause additional damage. + +In the end though, developers should give their best to prevent users from +running into situations where a regression leaves them only three options: 'run +a kernel with a regression that seriously impacts usage', 'continue running an +outdated and thus potentially insecure kernel version for more than two weeks +after a regression's culprit was identified', and 'downgrade to a still +supported kernel series that's missing required features'. + +How to realize this depends a lot on the situation. Here are a few rules of +thumb for developers, in order or importance: + + * Prioritize work on handling reports about regression and fixing them over all + other Linux kernel work, unless the latter concerns acute security issues or + bugs causing data loss or damage. + + * Always consider reverting the culprit commits and reapplying them later + together with necessary fixes, as this might be the least dangerous and + quickest way to fix a regression. + + * Try to resolve any regressions introduced in the current development before + its end. If you fear a fix might be too risky to apply only days before a new + mainline release, let Linus decide: submit the fix separately to him as soon + as possible with the explanation of the situation. He then can make a call + and postpone the release if necessary, for example if multiple such changes + show up in his inbox. + + * Address regressions in stable, longterm, or proper mainline releases with + more urgency than regressions in mainline pre-releases. That changes after + the release of the fifth pre-release, aka '-rc5': mainline then becomes as + important, to ensure all the improvements and fixes are ideally tested + together for at least one week before Linus releases a new mainline version. + + * Fix regressions within two or three days, if they are critical for some + reason -- for example, if the issue is likely to affect many users of the + kernel series in question on all or certain architectures. This thus includes + fixes for compile errors in mainline, as they might prevent testers and + continuous integration systems from doing their work. + + * Aim to merge regression fixes into mainline within one week after the culprit + was identified, if the regression was introduced in a stable/longterm release + or the development cycle for the latest mainline release (say v5.14). If + possible, try to address the issue even quicker, if the previous stable + series (v5.13.y) will be abandoned soon or already was stamped 'End-of-Life' + (EOL) -- this usually happens about three to four weeks after a new mainline + release. + + * Try to fix all other regressions within two weeks after the culprit was + found. Two or three additional weeks are acceptable for performance + regressions and other issues which are annoying, but don't prevent anyone + from running Linux -- unless it's an issue in the current development cycle, + which should be addressed before the release. A few weeks in total are also + acceptable if a regression can only be fixed with a risky change and at the + same time is affecting only a few users; as much time is also acceptable if + the regression is already present in the second newest longterm kernel + series. + +Note: The aforementioned time frames for resolving regressions are meant to +include getting the fix tested, reviewed, and merged into mainline, ideally with +the fix being in linux-next for two days. Developers need to keep in mind that +each of these steps takes some time. + +Subsystem maintainers are expected to assist in reaching those periods by doing +timely reviews and quick handling of accepted patches. They thus might have to +send git-pull requests earlier or more often than usual; depending on the fix, +it might even be acceptable to skip testing in linux-next. Especially fixes for +regressions in stable and longterm kernels need to be handled quickly, as fixes +need to be merged in mainline before they can be backported to older series. + Are really all regressions fixed? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signature · 1 line
2.31.1
Quoted 10 lines · Thorsten Leemhuis
'We don't cause regressions' might be the first rule of Linux kernel development, but it and other aspects of regressions nevertheless are hardly described in the Linux kernel's documentation. The following two patches change this by creating a document dedicated to the topic.
The second patch could easily be folded into the first one, but was kept separate, as it might be a bit controversial. This also allows the patch description to explain some backgrounds for this part of the document. Additionally, ACKs and Reviewed-by tags can be collected separately this way.
Quoted 4 lines
v2/RFC:
- a lot of small fixes, most are for spelling mistakes and grammar errors/problems pointed out in the review feedback I got so far
- add ACK for the series from Greg
My ack seems not to be here :(
Also, this is a "real" series, no need for a RFC anymore, right?
thanks,
greg k-h
Quoted 11 lines · Greg Kroah-Hartman
Quoted 10 lines · Thorsten Leemhuis
'We don't cause regressions' might be the first rule of Linux kernel development, but it and other aspects of regressions nevertheless are hardly described in the Linux kernel's documentation. The following two patches change this by creating a document dedicated to the topic.
The second patch could easily be folded into the first one, but was kept separate, as it might be a bit controversial. This also allows the patch description to explain some backgrounds for this part of the document. Additionally, ACKs and Reviewed-by tags can be collected separately this way.
Quoted 6 lines
Quoted 4 lines
v2/RFC:
- a lot of small fixes, most are for spelling mistakes and grammar errors/problems pointed out in the review feedback I got so far
- add ACK for the series from GregMy ack seems not to be here :(
Huh, how did that happen? Sorry, thx for pointing it out, will be in v3.
Quoted 1 line
Also, this is a "real" series, no need for a RFC anymore, right?
I was taken a bit back-and-forth and then settled on calling this one still RFC, as I was unsure if people Jon might want to wait on feedback from Linus before they take
[resending after finishing the mail for real, accidentally it the keys to send :-/]
Quoted 11 lines · Greg Kroah-Hartman
Quoted 10 lines · Thorsten Leemhuis
'We don't cause regressions' might be the first rule of Linux kernel development, but it and other aspects of regressions nevertheless are hardly described in the Linux kernel's documentation. The following two patches change this by creating a document dedicated to the topic.
The second patch could easily be folded into the first one, but was kept separate, as it might be a bit controversial. This also allows the patch description to explain some backgrounds for this part of the document. Additionally, ACKs and Reviewed-by tags can be collected separately this way.
Quoted 6 lines
Quoted 4 lines
v2/RFC:
- a lot of small fixes, most are for spelling mistakes and grammar errors/problems pointed out in the review feedback I got so far
- add ACK for the series from GregMy ack seems not to be here :(
Huh, how did that happen? Sorry, thx for pointing it out, will be in v3.
Quoted 1 line
Also, this is a "real" series, no need for a RFC anymore, right?
I was taken a bit back-and-forth and then settled on calling this one still RFC, as I was unsure if people like Jon and Randy might want to wait on feedback from Linus before they take a closer look at all that huge amount of text...
Ciao, Thorsten