On 15.03.21 21:20, Jonathan Corbet wrote:

Thorsten Leemhuis [off-list ref] writes:

quoted

Tell users that reporting bugs with vendor kernels which are only
slightly patched can be okay in some situations, but point out there's a
risk in doing so.

Adjust some related sections to make them compatible and a bit clearer.
At the same time make them less daunting: we want users to report bugs,
even if they can't test vanilla mainline kernel.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
CC: Randy Dunlap <redacted>

---
With this I try to get rid of the last remaining parts that have a
'this needs discussion' box that's in the text. I hope I've found a
middle ground that everybody can live with.

For the most part it seems OK to me.

Thx for looking at it!

I *really* worry, though, that this file is getting so big that few
people will work their way through it.

Yeah, this is a problem, definitely, but the document was written to
make sure that nobody has to work their way through it, as the "step by
step" guide tells all the important things already – and that guide
(even with this patch and the other one that you looked at yesterday)
should still be shorter (and clearer) then the old "reporting bugs" text
(I hope, I didn't verify...).

 Anything that could be done to
make it more concise going forward would be more than welcome.

Yeah, will think about it, especially WRT to the other patch you looked
at. Maybe I can come up with something. But no promises, I put a lot of
thought into the problem already.

The real solution for the problem IMHO looks totally different anyway:
provide pre-compiled kernels somewhere that users can install and even
bisect without installing a compiler at all (sure, there is a the
problem with the configuration, but whatever, just pick one and see how
things work out). Would be a fun project I'd really like to work on
sooner or later, but for now I have different priorities...

[...]

quoted

+   suspend your efforts for a few days anyway. Whatever version you choose,
+   ideally use a 'vanilla' built. Ignoring these advices will dramatically
+   increase the risk you report will be rejected or ignored.

s/built/build/

Argh, thx for pointing it out.

Also, I would stop quoting terms like "mainline", "stable" and "vanilla"
throughout.  It makes the reading experience a bit stranger without
(IMO) adding anything.

Yeah, let me provide a patch to reduce the quoting. If it's okay for you
I'd like to leave the quotes in the section that round about explains
the terms mainline, stable, and longterm. I think it's wise there to
point out that these are terms that have a special meaning in kernel
context. That's why I quoted them in a lot of places – especially those
where the reader might see them for the first time, as "stable" is kind
of ambiguous, which I wanted to avoid somehow.

Which brings me to another, but related issue. That patch could also fix
an inconsistency I recently noticed: how to spell panic, oops, bug,
warning? I sometimes quoted them  because in kernel context they have
special meaning, as a BUG() is not some random bug... And is it Oops or
oops (I recently noticed I used both spellings, but I found both when I
grepped Documentation/)? Here are some options:

1) panic, oops, bug, warning
2a) 'panic', 'oops', 'bug', 'warning',
2b) *panic*, *oops*, *bug*, *warning*,
3) panic, Oops, BUG, WARNING,
4) panic, Oops, BUG(), WARN()

The problem there is similar with the term 'stable': the words bug and
warning are ambiguous for people that are not familiar with the terms
used by the kernel community. Putting them in quotes at least give a
subtle hint like "this term might have a special meaning". It works for
my subconscious, but I guess won't for many others.

Nevertheless I'd go option 2a or 2b above: doesn't look to ugly (like 3
and 4) and avoids being ambiguous (like 1, which I for one don't like at
all).

What's your opinion on this? Or do you say "ohh, you are overthinking
it, just go with option 1!". :-D

Ciao, Thorsten