On 11/11/20 7:24 AM, Thorsten Leemhuis wrote:
> Am 03.10.20 um 09:27 schrieb Thorsten Leemhuis:
>> Randy, many thanks for looking through this, you feedback is much
>> appreciated! 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 04:32 schrieb Randy Dunlap:
>>> On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
>>> […]
>>>> +<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/MAINTAINERS>`_
>>>> +how developers of that particular area expect to be told about issues;
>>>> note,
>>> for how
>>> ?
>> Not sure myself, but I guess you're right and thus followed your advice :-D
>
> 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.
>
> ```
> The short guide (aka TL;DR)
> ===========================
>
> If you're facing multiple issues with the Linux kernel at once, report each
> separately to its developers. Try your best guess which kernel part might be
> causing the issue. Check the :ref:`MAINTAINERS <maintainers>` file for how
> its developers expect to be told about issues. Note, it's rarely
> `bugzilla.kernel.org <https://bugzilla.kernel.org/>`_, as in almost all cases
> the report needs to be sent by email!
>
> Check the destination thoroughly for existing reports; also search the LKML
> archives and the web. Join existing discussion if you find matches. If you
> don't find any, install `the latest Linux mainline kernel
> <https://kernel.org/>`_. Make sure it's vanilla, thus is not patched or using
> add-on kernel modules. Also ensure the kernel is running in a healthy
> environment and is not already tainted before the issue occurs.
>
> If you can reproduce your issue with the mainline kernel, send a report to
> the destination you determined earlier. Make sure it includes all relevant
> information, which in case of a regression should mention the change that's
> causing it which can often can be found with a bisection. Also ensure the
> report reaches all people that need to know about it, for example the
> security team, the stable maintainers or the developers of the patch that
> causes a regression. Once the report it out, answer any questions that might
> be raised and help where you can. That includes keeping the ball rolling:
> every time a new rc1 mainline kernel is released, check if the issue is still
> happening there and attach a status update to your initial report.
>
> If you can not reproduce the issue with the mainline kernel, consider
> sticking with it; if you'd like to use an older version line and want to see
> it fixed there, first make sure it's still supported. Install its latest
> release as vanilla kernel. If you cannot reproduce the issue there, try to
> find the commit that fixed it in mainline or any discussion preceding it:
> those will often mention if backporting is planed or considered impassable.
> If backporting was not discussed, ask if it's in the cards. In case you don't
> find
impossible. ??
any commits or a preceding discussion, see the Linux-stable mailing list
archives for existing reports, as it might be a regression specific to the
version line. If it is, it round about needs to be reported like a problem in
mainline (including the bisection).
maybe: it still needs to be reported like
>
> If you reached this point without a solution, ask for advice one the
> subsystem's mailing list.
> ```
Otherwise it looks good to me.
thanks.
--
~Randy
