Now that the document described all preparatory steps tell users to
install the latest kernel. Try pretty hard to motivate them installing a
mainline kernel, as that is best for reporting issues. Mention the
latest stable kernel as an acceptable alternative, but discourage this
option. Point out that longterm kernels are unsuitable.
While at it, provide a few hints how to obtain a fresh kernel. Also
explain how to find out what the latest version actually is. And mention
why it might be a good idea to wait till the end of the merge window
when reporting issues.
Signed-off-by: Thorsten Leemhuis <[email protected]>
---
= RFC =
Am I asking for too much from users by telling them to test mainline? But most
will likely have an outdated and heavily patched vendor kernel anyway, so they
have to install a vanilla kernel if they want to report something upstream;
that's why I thought "well, then let's go all in and make them test mainline.
---
Documentation/admin-guide/reporting-bugs.rst | 88 ++++++++++++++++++++
1 file changed, 88 insertions(+)
diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
index f99d92a05bca..dee6d65aa95c 100644
--- a/Documentation/admin-guide/reporting-bugs.rst
+++ b/Documentation/admin-guide/reporting-bugs.rst
@@ -643,6 +643,94 @@ hardware apart from a kernel issue that rarely happens and thus is hard to
reproduce.
+Install the latest mainline kernel
+----------------------------------
+
+ *Install the latest Linux mainline kernel: that's where all issue get fixed
+ first, because it's the version line the kernel developers mainly care
+ about. Testing and reporting with the latest Linux stable kernel can be
+ acceptable alternative in some situations, but is best avoided.*
+
+Reporting an issue to the Linux kernel developers they fixed a while ago is
+annoying for them and wasting their and your time. That's why it's in
+everybody's interest to check if the issue occurs with the latest version before
+reporting it.
+
+In the scope of the Linux kernel the term 'latest' means: a kernel version
+recently created from the main line of development, as this 'mainline' tree is
+where every fix gets applied to first; only later they are allowed to get
+backported to older, still support version lines called 'stable' and 'longterm'
+kernels. That's why it's a prerequisite to check mainline even if just want to
+see the issue fixed in one of those. Another reasons: sometimes fixes for an
+issue are only applied to mainline, as they are too risky to get backported
+into older version lines where they thus remain unfixed.
+
+It's thus in your and everybody's else interest to reproduce the issue with a
+fresh mainline kernel before reporting it. Reproducing it with the latest Linux
+'stable' kernel can be acceptable alternative, if you can't test mainline for
+some reason; this is not ideal, but better than not reporting the issue at all.
+
+Avoid testing with one of the longterm kernels (sometimes called "LTS kernels"),
+they are too distant from current development; the same is also true for
+mainline or stable kernels that are not very recent, as there is a new release
+of those nearly every week.
+
+Ways to obtains a fresh vanilla kernel
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+One way to get the latest mainline or stable kernel in a vanilla fashion is to
+download the Linux sources from `kernel.org <https://kernel.org/>`_ and build a
+kernel image and modules from them yourself. How to do that is not described
+here, as many texts on the internet explain the necessary steps already. If you
+are new to it, consider following one of those how-to's that suggest to use
+``make localmodconfig``, as that tries to pick up the configuration of your
+current kernel and then tries to adjust it somewhat for your system. That does
+not make the resulting kernel any better, but makes it compile a lot faster.
+
+There might be a way around building your own kernel, if you are in a luck: for
+popular Linux distribution you'll find repositories on the net that offer
+packages with of the latest mainline or stable Linux vanilla kernels for easy
+installation. It's totally okay to use packages with these pre-compiled kernels,
+just make sure from the repository's documentation they are supposed to be
+'vanilla', for reasons outlined in the first step of this process. And be aware
+that you might need to build your own kernel later anyway when it comes to
+testing fixes, as described later in this document.
+
+Finding the latest Linux version
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To check what the latest mainline release actually is, go to `kernel.org
+<https://kernel.org/>`_. Ignore the big yellow button that says 'Latest
+release': that points to the latest stable release, which you normally don't
+want to use.
+
+Instead, look a little lower for a table for a line with the description
+'mainline', which you'll find at the top of that table. Most of the time
+'mainline' will point to a pre-release with a version number like '5.8-rc2'. In
+that case that's the version you want to test. Do not let that 'rc' scare you,
+these 'development kernels' are pretty reliable — and you have a backup, like we
+told you above, don't you?
+
+In about two out of every nine to ten weeks, 'mainline' might point you to a
+proper release with a version number like '5.7'. If that happens consider
+suspending the reporting process for a while, as the Linux development cycle is
+currently in its two-week long 'merge window'. That's where the bulk of the
+changes (and all intrusive ones) get merged for the next release, before its
+first pre-release is published (5.8-rc1). Kernel developers are often quite
+busy during this time period and might have no spare time to deal with issue
+reports. It's also quite possible that one of the many changes applied during
+the merge window fixes the issue you face; that's why you soon would have to
+retest with a newer kernel version anyway, as outlined below in the section
+'Duties after the report when out'. Therefor it's often wise to wait for the
+first pre-release before proceeding with this step, unless you're dealing with
+one of those 'issues of high priority' or one that can't wait for a good reason.
+
+Feel free to ignore the past three paragraphs if you are a developer, Linux
+kernel expert, or brave; instead simply get the latest Linux kernel sources
+using ``git`` straight from the `official development repository on kernel.org
+<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/>`_.
+
+
.. ############################################################################
.. Temporary marker added while this document is rewritten. Sections above
.. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
--
2.26.2
On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Now that the document described all preparatory steps tell users to
> install the latest kernel. Try pretty hard to motivate them installing a
> mainline kernel, as that is best for reporting issues. Mention the
> latest stable kernel as an acceptable alternative, but discourage this
> option. Point out that longterm kernels are unsuitable.
>
> While at it, provide a few hints how to obtain a fresh kernel. Also
> explain how to find out what the latest version actually is. And mention
> why it might be a good idea to wait till the end of the merge window
> when reporting issues.
>
> Signed-off-by: Thorsten Leemhuis <[email protected]>
> ---
>
> = RFC =
>
> Am I asking for too much from users by telling them to test mainline? But most
> will likely have an outdated and heavily patched vendor kernel anyway, so they
> have to install a vanilla kernel if they want to report something upstream;
> that's why I thought "well, then let's go all in and make them test mainline.
That is appropriate IMO.
> ---
> Documentation/admin-guide/reporting-bugs.rst | 88 ++++++++++++++++++++
> 1 file changed, 88 insertions(+)
>
> diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
> index f99d92a05bca..dee6d65aa95c 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -643,6 +643,94 @@ hardware apart from a kernel issue that rarely happens and thus is hard to
> reproduce.
>
>
> +Install the latest mainline kernel
> +----------------------------------
> +
> + *Install the latest Linux mainline kernel: that's where all issue get fixed
issues
> + first, because it's the version line the kernel developers mainly care
> + about. Testing and reporting with the latest Linux stable kernel can be
> + acceptable alternative in some situations, but is best avoided.*
an acceptable
> +
> +Reporting an issue to the Linux kernel developers they fixed a while ago is
> +annoying for them and wasting their and your time. That's why it's in
> +everybody's interest to check if the issue occurs with the latest version before
> +reporting it.
> +
> +In the scope of the Linux kernel the term 'latest' means: a kernel version
> +recently created from the main line of development, as this 'mainline' tree is
> +where every fix gets applied to first; only later they are allowed to get
> +backported to older, still support version lines called 'stable' and 'longterm'
supported
> +kernels. That's why it's a prerequisite to check mainline even if just want to
even if you just want to
> +see the issue fixed in one of those. Another reasons: sometimes fixes for an
in one of those other version lines. Another reason:
> +issue are only applied to mainline, as they are too risky to get backported
> +into older version lines where they thus remain unfixed.
> +
> +It's thus in your and everybody's else interest to reproduce the issue with a
everybody else's
> +fresh mainline kernel before reporting it. Reproducing it with the latest Linux
> +'stable' kernel can be acceptable alternative, if you can't test mainline for
> +some reason; this is not ideal, but better than not reporting the issue at all.
> +
> +Avoid testing with one of the longterm kernels (sometimes called "LTS kernels"),
> +they are too distant from current development; the same is also true for
as they are too distant
> +mainline or stable kernels that are not very recent, as there is a new release
> +of those nearly every week.
> +
> +Ways to obtains a fresh vanilla kernel
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +One way to get the latest mainline or stable kernel in a vanilla fashion is to
> +download the Linux sources from `kernel.org <https://kernel.org/>`_ and build a
> +kernel image and modules from them yourself. How to do that is not described
> +here, as many texts on the internet explain the necessary steps already. If you
> +are new to it, consider following one of those how-to's that suggest to use
> +``make localmodconfig``, as that tries to pick up the configuration of your
> +current kernel and then tries to adjust it somewhat for your system. That does
> +not make the resulting kernel any better, but makes it compile a lot faster.
> +
> +There might be a way around building your own kernel, if you are in a luck: for
in luck: for
> +popular Linux distribution you'll find repositories on the net that offer
> +packages with of the latest mainline or stable Linux vanilla kernels for easy
> +installation. It's totally okay to use packages with these pre-compiled kernels,
> +just make sure from the repository's documentation they are supposed to be
> +'vanilla', for reasons outlined in the first step of this process. And be aware
> +that you might need to build your own kernel later anyway when it comes to
> +testing fixes, as described later in this document.
> +
> +Finding the latest Linux version
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +To check what the latest mainline release actually is, go to `kernel.org
> +<https://kernel.org/>`_. Ignore the big yellow button that says 'Latest
> +release': that points to the latest stable release, which you normally don't
> +want to use.
> +
> +Instead, look a little lower for a table for a line with the description
with a line with the description
> +'mainline', which you'll find at the top of that table. Most of the time
> +'mainline' will point to a pre-release with a version number like '5.8-rc2'. In
> +that case that's the version you want to test. Do not let that 'rc' scare you,
> +these 'development kernels' are pretty reliable — and you have a backup, like we
> +told you above, don't you?
> +
> +In about two out of every nine to ten weeks, 'mainline' might point you to a
> +proper release with a version number like '5.7'. If that happens consider
> +suspending the reporting process for a while, as the Linux development cycle is
> +currently in its two-week long 'merge window'. That's where the bulk of the
> +changes (and all intrusive ones) get merged for the next release, before its
> +first pre-release is published (5.8-rc1). Kernel developers are often quite
> +busy during this time period and might have no spare time to deal with issue
> +reports. It's also quite possible that one of the many changes applied during
> +the merge window fixes the issue you face; that's why you soon would have to
> +retest with a newer kernel version anyway, as outlined below in the section
> +'Duties after the report when out'. Therefor it's often wise to wait for the
Therefore
> +first pre-release before proceeding with this step, unless you're dealing with
> +one of those 'issues of high priority' or one that can't wait for a good reason.
> +
> +Feel free to ignore the past three paragraphs if you are a developer, Linux
> +kernel expert, or brave; instead simply get the latest Linux kernel sources
> +using ``git`` straight from the `official development repository on kernel.org
> +<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/>`_.
> +
> +
> .. ############################################################################
> .. Temporary marker added while this document is rewritten. Sections above
> .. are new and dual-licensed under GPLv2+ and CC-BY 4.0, those below are old.
>
--
~Randy
Many thx for you comments. Consider all the obvious spelling and
grammatical mistakes you pointed out fixed, I won't mention all of them
in this reply to keep things easier to follow.
Am 02.10.20 um 19:51 schrieb Randy Dunlap:
> On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
>> = RFC =
>>
>> Am I asking for too much from users by telling them to test mainline? But most
>> will likely have an outdated and heavily patched vendor kernel anyway, so they
>> have to install a vanilla kernel if they want to report something upstream;
>> that's why I thought "well, then let's go all in and make them test mainline.
>
> That is appropriate IMO.
Yeah, but finding the the right tone in the text seem important to me,
as some people might see it as "hey, the kernel develpers are putting
the bar really really high". That's why I pointed it out explicitly.
>> +Instead, look a little lower for a table for a line with the description
>
> with a line with the description
>
>> +'mainline', which you'll find at the top of that table.
Rewrote this sentence:
Instead, look at the table below for a line starting with 'mainline',
which you'll find at the top of that table.
Ciao, Thorsten
Am 03.10.20 um 12:11 schrieb Thorsten Leemhuis:
> Am 02.10.20 um 19:51 schrieb Randy Dunlap:
>> On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
>>> = RFC =
>>>
>>> Am I asking for too much from users by telling them to test mainline? But most
>>> will likely have an outdated and heavily patched vendor kernel anyway, so they
>>> have to install a vanilla kernel if they want to report something upstream;
>>> that's why I thought "well, then let's go all in and make them test mainline.
>> That is appropriate IMO.
I'm preparing to send v2 and was a bit unhappy with this and another
section when seeing it again after weeks. In the end I reshuffled and
rewrote significant parts of it, see below.
Randy, would be great if you could take another look, but no pressure:
just ignore it, if you lack the time or energy.
```
Install a fresh kernel for testing
----------------------------------
*Install the latest Linux mainline kernel: that's where all issues
get fixed first, because it's the version line the kernel developers
mainly care about. Testing and reporting with the latest Linux stable
kernel can be an acceptable alternative in some situations, for example
during the merge window; but during that period you might want to
suspend your efforts till its end anyway.*
Reporting an issue to the Linux kernel developers they fixed weeks or
months ago is annoying for them and wasting their and your time. That's
why it's in everybody's interest to check if the issue occurs with the
latest codebase before reporting it.
In the scope of the Linux kernel the term 'latest' means: a kernel
version recently created from the main line of development, as this
'mainline' tree is where developer first apply fixes; only after that
they are allowed to get backported to older, still supported version
lines called 'stable' and 'longterm' kernels. That's why you should
check a recent mainline kernel, even if you deal with an issue you only
want to see fixed in an older version line. Another reason: some fixes
are only applied to mainline or recent version lines, as it's too hard
or risky to backport them to older versions. If that the case, reporting
the issue again is unlikely to change anything.
Longterm kernels (sometimes called "LTS kernels") are therefore
unsuitable for testing, they simply are too distant from current
development. Even the latest Linux 'stable' kernel is a significant bit
behind and thus better avoided. But sometimes it's even the right
choice, but in those cases you might want to wait a few days before
trying to reproduce an issue with the latest codebase:
Choosing between mainline, stable and waiting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Head over to `kernel.org <https://kernel.org/>`_ to decide which version
to use. Ignore the big yellow button that says 'Latest release' and look
a little lower for a table. At its top you'll see a line starting with
'mainline', which most of the time will point to a pre-release with a
version number like '5.8-rc2'. If that's the case, you'll want to use
this mainline kernel for testing. Do not let that 'rc' scare you, these
'development kernels' are pretty reliable — and you made a backup, as
you were instructed above, don't you?
In about two out of every nine to ten weeks, 'mainline' might point you
to a proper release with a version number like '5.7'. If that happens,
consider suspending the reporting process until the first pre-release of
the next version (5.8-rc1) shows up on kernel.org. That's because the
Linux development cycle then is in its two-week long 'merge window'. The
bulk of the changes and all intrusive ones get merged for the next
release during this time. It's a bit more risky to use mainline during
this period. Kernel developers are also often quite busy then and might
have no spare time to deal with issue reports. It's also quite possible
that one of the many changes applied during the merge window fixes the
issue you face; that's why you soon would have to retest with a newer
kernel version anyway, as outlined below in the section 'Duties after
the report when out'.
That's why it might make sense to wait till the merge window is over.
But don't to that if you're dealing with something that shouldn't wait.
In that case consider obtaining the latest mainline kernel via git (see
below) or use the latest stable version offered on kernel.org. Using
that is also acceptable in case mainline for some reason does currently
not work for you. An in general: using it for reproducing the issue is
also better than not reporting it issue at all.
How to obtain a fresh Linux kernel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can use pre-build or self-compiled kernel for testing; if you chose
the latter approach, you can either obtain the source-code using git or
download it as tar archive.
Using a pre-compiled kernel for testing is often the quickest, easiest,
and safest way – especially is you are unfamiliar with the Linux kernel.
But it needs to be a vanilla kernel, which can be hard to come buy. You
are in luck if you are using a popular Linux distribution: for quite a
few of them you'll find repositories on the net that contain packages
with the latest mainline or stable kernels in vanilla fashion. It's
totally okay to use these, just make sure from the repository's
documentation they are really vanilla. And ensure the packages contain
the latest versions as offered on kernel.org; they are likely unsuitable
if the package is older than a week, as new mainline and stable kernels
typically bet released at least once a week. And be aware that you might
need to build your own kernel later anyway when it comes helping to test
fixes, as described later in this document.
Developers and experienced Linux users familiar with git are often best
served by obtaining the latest Linux kernel sources straight from the
`official development repository on kernel.org
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/>`_.
Those are likely a bit ahead of the latest mainline pre-release. Don't
worry about it: they are as reliable as a proper pre-release, unless the
kernel's development cycle is currently in the middle of a merge window.
But even then they are quite reliable.
People unfamiliar with git are often best served by downloading the
sources as tarball from `kernel.org <https://kernel.org/>`_.
How to actually build a kernel not described here, as many websites
explain the necessary steps already. If you are new to it, consider
following one of those how-to's that suggest to use ``make
localmodconfig``, as that tries to pick up the configuration of your
current kernel and then tries to adjust it somewhat for your system.
That does not make the resulting kernel any better, but quicker to compile.
```
Ciao, Thorsten
On 11/11/20 7:36 AM, Thorsten Leemhuis wrote:
> Am 03.10.20 um 12:11 schrieb Thorsten Leemhuis:
>> Am 02.10.20 um 19:51 schrieb Randy Dunlap:
>>> On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
>>>> = RFC =
>>>>
>>>> Am I asking for too much from users by telling them to test mainline? But most
>>>> will likely have an outdated and heavily patched vendor kernel anyway, so they
>>>> have to install a vanilla kernel if they want to report something upstream;
>>>> that's why I thought "well, then let's go all in and make them test mainline.
>>> That is appropriate IMO.
>
> I'm preparing to send v2 and was a bit unhappy with this and another section when seeing it again after weeks. In the end I reshuffled and rewrote significant parts of it, see below.
>
> Randy, would be great if you could take another look, but no pressure: just ignore it, if you lack the time or energy.
>
> ```
> Install a fresh kernel for testing
> ----------------------------------
>
> *Install the latest Linux mainline kernel: that's where all issues get fixed first, because it's the version line the kernel developers mainly care about. Testing and reporting with the latest Linux stable kernel can be an acceptable alternative in some situations, for example during the merge window; but during that period you might want to suspend your efforts till its end anyway.*
>
> Reporting an issue to the Linux kernel developers they fixed weeks or months ago is annoying for them and wasting their and your time. That's why it's in everybody's interest to check if the issue occurs with the latest codebase before reporting it.
>
> In the scope of the Linux kernel the term 'latest' means: a kernel version recently created from the main line of development, as this 'mainline' tree is where developer first apply fixes; only after that they are allowed to get backported to older, still
developers only after that are they
supported version lines called 'stable' and 'longterm' kernels. That's why you should check a recent mainline kernel, even if you deal with an issue you only want to see fixed in an older version line. Another reason: some fixes are only applied to mainline or recent version lines, as it's too hard or risky to backport them to older versions. If that the case, reporting the issue again is unlikely to change anything.
>
> Longterm kernels (sometimes called "LTS kernels") are therefore unsuitable for testing, they simply are too distant from current
testing; they
or testing. They
development. Even the latest Linux 'stable' kernel is a significant bit behind and thus better avoided. But sometimes it's even the right choice, but in those cases you might want to wait a few days before trying to reproduce an issue with the latest codebase:
Try to remove one "But/but" in the sentence above.
>
> Choosing between mainline, stable and waiting
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Head over to `kernel.org <https://kernel.org/>`_ to decide which version to use. Ignore the big yellow button that says 'Latest release' and look a little lower for a table. At its top you'll see a line starting with 'mainline', which most of the time will point to a pre-release with a version number like '5.8-rc2'. If that's the case, you'll want to use this mainline kernel for testing. Do not let that 'rc' scare you, these 'development kernels' are pretty reliable — and you made a backup, as you were instructed above, don't
s/don't/didn't/
you?
>
> In about two out of every nine to ten weeks, 'mainline' might point you to a proper release with a version number like '5.7'. If that happens, consider suspending the reporting process until the first pre-release of the next version (5.8-rc1) shows up on
only one space ^^
kernel.org. That's because the Linux development cycle then is in its two-week long 'merge window'. The bulk of the changes and all intrusive ones get merged for the next release during this time. It's a bit more risky to use mainline during this period. Kernel developers are also often quite busy then and might have no spare time to deal with issue reports. It's also quite possible that one of the many changes applied during the merge window fixes the issue you face; that's why you soon would have to retest with a newer kernel version anyway, as outlined below in the section 'Duties after the report when out'.
Should that be after the report went out'.
?
>
> That's why it might make sense to wait till the merge window is over. But don't to that if you're dealing with something that shouldn't wait. In that case consider obtaining the latest mainline kernel via git (see below) or use the latest stable version offered on kernel.org. Using that is also acceptable in case mainline for some reason does currently not work for you. An in general: using it for reproducing the issue is also better than not reporting it issue at all.
>
> How to obtain a fresh Linux kernel
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> You can use pre-build or self-compiled kernel for testing; if you chose the latter approach, you can either obtain the source-code
pre-built choose source code
using git or download it as tar archive.
>
> Using a pre-compiled kernel for testing is often the quickest, easiest, and safest way – especially is you are unfamiliar with the Linux kernel. But it needs to be a vanilla kernel, which can be hard to come buy. You are in luck if you are using a popular Linux distribution: for quite a few of them you'll find repositories on the net that contain packages with the latest mainline or stable kernels in vanilla fashion. It's totally okay to use these, just make sure from the repository's documentation they are really vanilla. And ensure the packages contain the latest versions as offered on kernel.org; they are likely unsuitable if the package is older than a week, as new mainline and stable kernels typically bet released at least once a week. And be aware that you might need to
get
build your own kernel later anyway when it comes helping to test fixes, as described later in this document.
when it comes to helping test fixes,
>
> Developers and experienced Linux users familiar with git are often best served by obtaining the latest Linux kernel sources straight from the `official development repository on kernel.org <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/>`_. Those are likely a bit ahead of the latest mainline pre-release. Don't worry about it: they are as reliable as a proper pre-release, unless the kernel's development cycle is currently in the middle of a merge window. But even then they are quite reliable.
>
> People unfamiliar with git are often best served by downloading the sources as tarball from `kernel.org <https://kernel.org/>`_.
>
> How to actually build a kernel not described here, as many websites explain the necessary steps already. If you are new to it,
kernel is not
consider following one of those how-to's that suggest to use ``make localmodconfig``, as that tries to pick up the configuration of your current kernel and then tries to adjust it somewhat for your system. That does not make the resulting kernel any better, but quicker to compile.
> ```
LGTM. Thanks.
--
~Randy
Am 12.11.20 um 04:42 schrieb Randy Dunlap:
> On 11/11/20 7:36 AM, Thorsten Leemhuis wrote:
>> Am 03.10.20 um 12:11 schrieb Thorsten Leemhuis:
>>> Am 02.10.20 um 19:51 schrieb Randy Dunlap:
>>>> On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> […]
>> I'm preparing to send v2 and was a bit unhappy with this and
>> another section when seeing it again after weeks. In the end I
>> reshuffled and rewrote significant parts of it, see below.
>>
> […]
>> development. Even the latest Linux 'stable' kernel is a significant
>> bit behind and thus better avoided. But sometimes it's even the right
>> choice, but in those cases you might want to wait a few days before
>> trying to reproduce an issue with the latest codebase:
> Try to remove one "But/but" in the sentence above.
Ha, yeah, good idea. Went with this:
At least most of the time, as sometimes a stable kernel can the best
choice; but in those situations you might want to wait a few days anyway:
> LGTM. Thanks.
Great, thx again for you feedback (Consider all the obvious spelling and
grammatical mistakes you pointed out fixed, I just didn't mention them
here to keep the reply short)!
Ciao, Thorsten