On 10/1/20 1:39 AM, Thorsten Leemhuis wrote:
> Tell users to write some rough notes how to reproduce the issue. They
> will need those notes soon once they have to reproduce the issue with
> the latest mainline kernel. At the same time they can serve as basis for
> the report later.
>
> While at it point out that each report should focus on one issue, as
> that is a good time for it: it will make the notes more straight forward
> if the reader deal with multiple issues at once.
>
> Signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx>
> ---
> Documentation/admin-guide/reporting-bugs.rst | 35 +++++++++++++++-----
> 1 file changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/admin-guide/reporting-bugs.rst b/Documentation/admin-guide/reporting-bugs.rst
> index 2292b79cf462..f99d92a05bca 100644
> --- a/Documentation/admin-guide/reporting-bugs.rst
> +++ b/Documentation/admin-guide/reporting-bugs.rst
> @@ -617,6 +617,32 @@ should minimize it:
> look like a regression.
>
>
> +Document how to reproduce issue
> +-------------------------------
> +
> + *Write down coarsely how to reproduce the issue. If you deal with multiple
> + issue at once, create separate notes for each of them and make sure they
issues
> + work independently on a freshly booted system. That's needed, as each issue
> + needs to get reported to the kernel developers separately, unless they are
> + strongly entangled.*
> +
> +If you deal with multiple issue at once, you'll have to report each of them
issues
> +separately, as they might be handled by different developers. Describing various
> +issues in one report also makes it quite difficult for others to tear it apart.
> +Hence, only combine issues in one report if they are strongly entangled.
> +
> +Additionally, during the reporting process you will have to test if the issue
> +happens with other kernel versions. Therefore, it will make your work easier if
> +you know exactly how to reproduce it quickly on a freshly booted system.
> +
> +Note: it's often fruitless to debug issues that only happened once, as they
> +might be caused by a bit flip due to cosmic radiation. That's why you should try
> +to rule that out by reproducing the issue before going further. Feed free to
Feel
> +ignore this if you are experienced enough to tell a one-time error due to faulty
> +hardware apart from a kernel issue that rarely happens and thus is hard to
> +reproduce.
> +
> +
> .. ############################################################################
> .. 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.
> @@ -639,15 +665,6 @@ How to report Linux kernel bugs
> ===============================
>
>
> -Tips for reporting bugs
> ------------------------
> -
> -It's REALLY important to report bugs that seem unrelated as separate email
> -threads or separate bugzilla entries. If you report several unrelated
> -bugs at once, it's difficult for maintainers to tease apart the relevant
> -data.
> -
> -
> Gather information
> ------------------
>
>
--
~Randy
