From: Thorsten Leemhuis <linux@leemhuis.info>
To: Randy Dunlap <rdunlap@infradead.org>, Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 15/26] docs: reporting-bugs: make readers test mainline, but leave a loophole
Date: Wed, 11 Nov 2020 16:36:16 +0100 [thread overview]
Message-ID: <873abf9c-5651-8dc3-70ea-b14e498661a7@leemhuis.info> (raw)
In-Reply-To: <a08d1012-78bf-5f84-26d2-4f596bc3b59d@leemhuis.info>
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
next prev parent reply other threads:[~2020-11-11 15:36 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 8:39 [RFC PATCH v1 00/26] Make reporting-bugs easier to grasp and yet more detailed Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 01/26] docs: reporting-bugs: temporary markers for licensing and diff reasons Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 02/26] docs: reporting-bugs: Create a TLDR how to report issues Thorsten Leemhuis
2020-10-02 2:32 ` Randy Dunlap
2020-10-03 7:27 ` Thorsten Leemhuis
2020-11-11 15:24 ` Thorsten Leemhuis
2020-11-12 3:33 ` Randy Dunlap
2020-11-12 4:56 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 03/26] docs: reporting-bugs: step-by-step guide on " Thorsten Leemhuis
2020-10-02 3:02 ` Randy Dunlap
2020-10-03 8:05 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 04/26] docs: reporting-bugs: step-by-step guide for issues in stable & longterm Thorsten Leemhuis
2020-10-02 3:25 ` Randy Dunlap
2020-10-03 8:24 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 05/26] docs: reporting-bugs: begin reference section providing details Thorsten Leemhuis
2020-10-02 16:49 ` Randy Dunlap
2020-10-03 8:27 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 06/26] docs: reporting-bugs: point out we only care about fresh vanilla kernels Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 07/26] docs: reporting-bugs: let users classify their issue Thorsten Leemhuis
2020-10-02 16:59 ` Randy Dunlap
2020-10-03 9:42 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 08/26] docs: reporting-bugs: make readers check the taint flag Thorsten Leemhuis
2020-10-02 17:08 ` Randy Dunlap
2020-10-03 9:56 ` Thorsten Leemhuis
2020-10-03 17:47 ` Randy Dunlap
2020-10-01 8:39 ` [RFC PATCH v1 09/26] docs: reporting-bugs: help users find the proper place for their report Thorsten Leemhuis
2020-10-04 4:03 ` Randy Dunlap
2020-10-07 12:05 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 10/26] docs: reporting-bugs: remind people to look for existing reports Thorsten Leemhuis
2020-10-02 17:17 ` Randy Dunlap
2020-10-03 9:58 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 11/26] docs: reporting-bugs: remind people to back up their data Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 12/26] docs: reporting-bugs: tell users to disable DKMS et al Thorsten Leemhuis
2020-10-02 17:28 ` Randy Dunlap
2020-10-03 9:59 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 13/26] docs: reporting-bugs: point out the environment might be causing issue Thorsten Leemhuis
2020-10-02 17:32 ` Randy Dunlap
2020-10-03 10:00 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 14/26] docs: reporting-bugs: make users write notes, one for each issue Thorsten Leemhuis
2020-10-02 17:35 ` Randy Dunlap
2020-10-03 10:01 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 15/26] docs: reporting-bugs: make readers test mainline, but leave a loophole Thorsten Leemhuis
2020-10-02 17:51 ` Randy Dunlap
2020-10-03 10:11 ` Thorsten Leemhuis
2020-11-11 15:36 ` Thorsten Leemhuis [this message]
2020-11-12 3:42 ` Randy Dunlap
2020-11-12 5:22 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 16/26] docs: reporting-bugs: let users check taint status again Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 17/26] docs: reporting-bugs: explain options if reproducing on mainline fails Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 18/26] docs: reporting-bugs: let users optimize their notes Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 19/26] docs: reporting-bugs: decode failure messages [need help] Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 20/26] docs: reporting-bugs: instructions for handling regressions Thorsten Leemhuis
2020-10-04 4:03 ` Randy Dunlap
2020-10-04 6:31 ` Thorsten Leemhuis
2020-10-01 8:39 ` [RFC PATCH v1 21/26] docs: reporting-bugs: details on writing and sending the report Thorsten Leemhuis
2020-10-09 2:45 ` Randy Dunlap
2020-10-09 7:38 ` Thorsten Leemhuis
2020-10-01 8:50 ` [RFC PATCH v1 22/26] docs: reporting-bugs: explain what users should do once the report got out Thorsten Leemhuis
2020-10-09 17:37 ` Randy Dunlap
2020-10-11 13:29 ` Thorsten Leemhuis
2020-10-11 15:06 ` Randy Dunlap
2020-10-01 8:50 ` [RFC PATCH v1 23/26] docs: reporting-bugs: details for issues specific to stable and longterm Thorsten Leemhuis
2020-10-09 18:42 ` Randy Dunlap
2020-10-11 13:29 ` Thorsten Leemhuis
2020-10-01 8:50 ` [RFC PATCH v1 24/26] docs: reporting-bugs: explain why users might get neither reply nor fix Thorsten Leemhuis
2020-10-04 4:03 ` Randy Dunlap
2020-10-04 6:35 ` Thorsten Leemhuis
2020-10-01 8:50 ` [RFC PATCH v1 25/26] docs: reporting-bugs: explain things could be easier Thorsten Leemhuis
2020-10-04 4:03 ` Randy Dunlap
2020-10-04 6:36 ` Thorsten Leemhuis
2020-10-01 8:50 ` [RFC PATCH v1 26/26] docs: reporting-bugs: add SPDX tag and license hint, remove markers Thorsten Leemhuis
2020-11-09 11:01 ` [RFC PATCH v1 00/26] Make reporting-bugs easier to grasp and yet more detailed Thorsten Leemhuis
2020-11-09 18:21 ` Jonathan Corbet
2020-11-10 12:01 ` Thorsten Leemhuis
2020-11-10 3:23 ` Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=873abf9c-5651-8dc3-70ea-b14e498661a7@leemhuis.info \
--to=linux@leemhuis.info \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.