[Ksummit-discuss] [3b/5] reporting-issues: reference section, main guide

[Thorsten Leemhuis <linux@leemhuis.info>]

On 26.03.21 07:13, Thorsten Leemhuis wrote:
> 
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that basically says "this is WIP".
> But I'd like to remove that warning and delete reporting-bugs.rst in the
> next merge window to make reporting-issues.rst fully official. With this
> mail I want to give everyone a chance to take a look at the text and
> speak up if you don't want me to move ahead for now.
> 
> For easier review I'll post the text of reporting-issues.rst in reply to
> this mail. I'll do that in a few chunks, as if this was a cover letter
> for a patch-set. 

Part 3 was to big for ksummit-discuss, so here it is the second half of it:


How to obtain a fresh Linux kernel

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



**Using a pre-compiled kernel**: This is often the quickest, easiest, and safest

way for testing — especially is you are unfamiliar with the Linux kernel. The

problem: most of those shipped by distributors or add-on repositories are build

from modified Linux sources. They are thus not vanilla and therefore often

unsuitable for testing and issue reporting: the changes might cause the issue

you face or influence it somehow.



But 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 Linux built as vanilla kernel. It's totally okay to

use these, just make sure from the repository's description they are vanilla or

at least close to it. Additionally ensure the packages contain the latest

versions as offered on kernel.org. The packages are likely unsuitable if they

are older than a week, as new mainline and stable kernels typically get released

at least once a week.



Please note that you might need to build your own kernel manually later: that's

sometimes needed for debugging or testing fixes, as described later in this

document. Also be aware that pre-compiled kernels might lack debug symbols that

are needed to decode messages the kernel prints when a panic, Oops, warning, or

BUG occurs; if you plan to decode those, you might be better off compiling a

kernel yourself (see the end of this subsection and the section titled 'Decode

failure messages' for details).



**Using git**: 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.



**Conventional**: 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 is 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.



Note: If you are dealing with a panic, Oops, warning, or BUG from the kernel,

please try to enable CONFIG_KALLSYMS when configuring your kernel.

Additionally, enable CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO, too; the

latter is the relevant one of those two, but can only be reached if you enable

the former. Be aware CONFIG_DEBUG_INFO increases the storage space required to

build a kernel by quite a bit. But that's worth it, as these options will allow

you later to pinpoint the exact line of code that triggers your issue. The

section 'Decode failure messages' below explains this in more detail.



But keep in mind: Always keep a record of the issue encountered in case it is

hard to reproduce. Sending an undecoded report is better than not reporting

the issue at all.





Check 'taint' flag

------------------



    *Ensure the kernel you just installed does not 'taint' itself when

    running.*



As outlined above in more detail already: the kernel sets a 'taint' flag when

something happens that can lead to follow-up errors that look totally

unrelated. That's why you need to check if the kernel you just installed does

not set this flag. And if it does, you in almost all the cases needs to

eliminate the reason for it before you reporting issues that occur with it. See

the section above for details how to do that.





Reproduce issue with the fresh kernel

-------------------------------------



    *Reproduce the issue with the kernel you just installed. If it doesn't show

    up there, scroll down to the instructions for issues only happening with

    stable and longterm kernels.*



Check if the issue occurs with the fresh Linux kernel version you just

installed. If it was fixed there already, consider sticking with this version

line and abandoning your plan to report the issue. But keep in mind that other

users might still be plagued by it, as long as it's not fixed in either stable

and longterm version from kernel.org (and thus vendor kernels derived from

those). If you prefer to use one of those or just want to help their users,

head over to the section "Details about reporting issues only occurring in

older kernel version lines" below.





Optimize description to reproduce issue

---------------------------------------



    *Optimize your notes: try to find and write the most straightforward way to

    reproduce your issue. Make sure the end result has all the important

    details, and at the same time is easy to read and understand for others

    that hear about it for the first time. And if you learned something in this

    process, consider searching again for existing reports about the issue.*



An unnecessarily complex report will make it hard for others to understand your

report. Thus try to find a reproducer that's straight forward to describe and

thus easy to understand in written form. Include all important details, but at

the same time try to keep it as short as possible.



In this in the previous steps you likely have learned a thing or two about the

issue you face. Use this knowledge and search again for existing reports

instead you can join.





Decode failure messages

-----------------------



    *If your failure involves a 'panic', 'Oops', 'warning', or 'BUG', consider

    decoding the kernel log to find the line of code that triggered the error.*



When the kernel detects an internal problem, it will log some information about

the executed code. This makes it possible to pinpoint the exact line in the

source code that triggered the issue and shows how it was called. But that only

works if you enabled CONFIG_DEBUG_INFO and CONFIG_KALLSYMS when configuring

your kernel. If you did so, consider to decode the information from the

kernel's log. That will make it a lot easier to understand what lead to the

'panic', 'Oops', 'warning', or 'BUG', which increases the chances that someone

can provide a fix.



Decoding can be done with a script you find in the Linux source tree. If you

are running a kernel you compiled yourself earlier, call it like this::



       [user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh ./linux-5.10.5/vmlinux



If you are running a packaged vanilla kernel, you will likely have to install

the corresponding packages with debug symbols. Then call the script (which you

might need to get from the Linux sources if your distro does not package it)

like this::



       [user@something ~]$ sudo dmesg | ./linux-5.10.5/scripts/decode_stacktrace.sh \

        /usr/lib/debug/lib/modules/5.10.10-4.1.x86_64/vmlinux /usr/src/kernels/5.10.10-4.1.x86_64/



The script will work on log lines like the following, which show the address of

the code the kernel was executing when the error occurred::



       [   68.387301] RIP: 0010:test_module_init+0x5/0xffa [test_module]



Once decoded, these lines will look like this::



       [   68.387301] RIP: 0010:test_module_init (/home/username/linux-5.10.5/test-module/test-module.c:16) test_module



In this case the executed code was built from the file

'~/linux-5.10.5/test-module/test-module.c' and the error occurred by the

instructions found in line '16'.



The script will similarly decode the addresses mentioned in the section

starting with 'Call trace', which show the path to the function where the

problem occurred. Additionally, the script will show the assembler output for

the code section the kernel was executing.



Note, if you can't get this to work, simply skip this step and mention the

reason for it in the report. If you're lucky, it might not be needed. And if it

is, someone might help you to get things going. Also be aware this is just one

of several ways to decode kernel stack traces. Sometimes different steps will

be required to retrieve the relevant details. Don't worry about that, if that's

needed in your case, developers will tell you what to do.





Special care for regressions

----------------------------



    *If your problem is a regression, try to narrow down when the issue was

    introduced as much as possible.*



Linux lead developer Linus Torvalds insists that the Linux kernel never

worsens, that's why he deems regressions as unacceptable and wants to see them

fixed quickly. That's why changes that introduced a regression are often

promptly reverted if the issue they cause can't get solved quickly any other

way. Reporting a regression is thus a bit like playing a kind of trump card to

get something quickly fixed. But for that to happen the change that's causing

the regression needs to be known. Normally it's up to the reporter to track

down the culprit, as maintainers often won't have the time or setup at hand to

reproduce it themselves.



To find the change there is a process called 'bisection' which the document

'Documentation/admin-guide/bug-bisect.rst' describes in detail. That process

will often require you to build about ten to twenty kernel images, trying to

reproduce the issue with each of them before building the next. Yes, that takes

some time, but don't worry, it works a lot quicker than most people assume.

Thanks to a 'binary search' this will lead you to the one commit in the source

code management system that's causing the regression. Once you find it, search

the net for the subject of the change, its commit id and the shortened commit id

(the first 12 characters of the commit id). This will lead you to existing

reports about it, if there are any.



Note, a bisection needs a bit of know-how, which not everyone has, and quite a

bit of effort, which not everyone is willing to invest. Nevertheless, it's

highly recommended performing a bisection yourself. If you really can't or

don't want to go down that route at least find out which mainline kernel

introduced the regression. If something for example breaks when switching from

5.5.15 to 5.8.4, then try at least all the mainline releases in that area (5.6,

5.7 and 5.8) to check when it first showed up. Unless you're trying to find a

regression in a stable or longterm kernel, avoid testing versions which number

has three sections (5.6.12, 5.7.8), as that makes the outcome hard to

interpret, which might render your testing useless. Once you found the major

version which introduced the regression, feel free to move on in the reporting

process. But keep in mind: it depends on the issue at hand if the developers

will be able to help without knowing the culprit. Sometimes they might

recognize from the report want went wrong and can fix it; other times they will

be unable to help unless you perform a bisection.



When dealing with regressions make sure the issue you face is really caused by

the kernel and not by something else, as outlined above already.



In the whole process keep in mind: an issue only qualifies as regression if the

older and the newer kernel got built with a similar configuration. The best way

to archive this: copy the configuration file (``.config``) from the old working

kernel freshly to each newer kernel version you try. Afterwards run ``make

oldnoconfig`` to adjust it for the needs of the new version without enabling

any new feature, as those are allowed to cause regressions.





Write and send the report

-------------------------



    *Start to compile the report by writing a detailed description about the

    issue. Always mention a few things: the latest kernel version you installed

    for reproducing, the Linux Distribution used, and your notes on how to

    reproduce the issue. Ideally, make the kernel's build configuration

    (.config) and the output from ``dmesg`` available somewhere on the net and

    link to it. Include or upload all other information that might be relevant,

    like the output/screenshot of an Oops or the output from ``lspci``. Once

    you wrote this main part, insert a normal length paragraph on top of it

    outlining the issue and the impact quickly. On top of this add one sentence

    that briefly describes the problem and gets people to read on. Now give the

    thing a descriptive title or subject that yet again is shorter. Then you're

    ready to send or file the report like the MAINTAINERS file told you, unless

    you are dealing with one of those 'issues of high priority': they need

    special care which is explained in 'Special handling for high priority

    issues' below.*



Now that you have prepared everything it's time to write your report. How to do

that is partly explained by the three documents linked to in the preface above.

That's why this text will only mention a few of the essentials as well as

things specific to the Linux kernel.



There is one thing that fits both categories: the most crucial parts of your

report are the title/subject, the first sentence, and the first paragraph.

Developers often get quite a lot of mail. They thus often just take a few

seconds to skim a mail before deciding to move on or look closer. Thus: the

better the top section of your report, the higher are the chances that someone

will look into it and help you. And that is why you should ignore them for now

and write the detailed report first. ;-)



Things each report should mention

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Describe in detail how your issue happens with the fresh vanilla kernel you

installed. Try to include the step-by-step instructions you wrote and optimized

earlier that outline how you and ideally others can reproduce the issue; in

those rare cases where that's impossible try to describe what you did to

trigger it.



Also include all the relevant information others might need to understand the

issue and its environment. What's actually needed depends a lot on the issue,

but there are some things you should include always:



 * the output from ``cat /proc/version``, which contains the Linux kernel

   version number and the compiler it was built with.



 * the Linux distribution the machine is running (``hostnamectl | grep

   "Operating System"``)



 * the architecture of the CPU and the operating system (``uname -mi``)



 * if you are dealing with a regression and performed a bisection, mention the

   subject and the commit-id of the change that is causing it.



In a lot of cases it's also wise to make two more things available to those

that read your report:



 * the configuration used for building your Linux kernel (the '.config' file)



 * the kernel's messages that you get from ``dmesg`` written to a file. Make

   sure that it starts with a line like 'Linux version 5.8-1

   (foobar@example.com) (gcc (GCC) 10.2.1, GNU ld version 2.34) #1 SMP Mon Aug

   3 14:54:37 UTC 2020' If it's missing, then important messages from the first

   boot phase already got discarded. In this case instead consider using

   ``journalctl -b 0 -k``; alternatively you can also reboot, reproduce the

   issue and call ``dmesg`` right afterwards.



These two files are big, that's why it's a bad idea to put them directly into

your report. If you are filing the issue in a bug tracker then attach them to

the ticket. If you report the issue by mail do not attach them, as that makes

the mail too large; instead do one of these things:



 * Upload the files somewhere public (your website, a public file paste

   service, a ticket created just for this purpose on `bugzilla.kernel.org

   <https://bugzilla.kernel.org/>`_, ...) and include a link to them in your

   report. Ideally use something where the files stay available for years, as

   they could be useful to someone many years from now; this for example can

   happen if five or ten years from now a developer works on some code that was

   changed just to fix your issue.



 * Put the files aside and mention you will send them later in individual

   replies to your own mail. Just remember to actually do that once the report

   went out. ;-)



Things that might be wise to provide

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Depending on the issue you might need to add more background data. Here are a

few suggestions what often is good to provide:



 * If you are dealing with a 'warning', an 'OOPS' or a 'panic' from the kernel,

   include it. If you can't copy'n'paste it, try to capture a netconsole trace

   or at least take a picture of the screen.



 * If the issue might be related to your computer hardware, mention what kind

   of system you use. If you for example have problems with your graphics card,

   mention its manufacturer, the card's model, and what chip is uses. If it's a

   laptop mention its name, but try to make sure it's meaningful. 'Dell XPS 13'

   for example is not, because it might be the one from 2012; that one looks

   not that different from the one sold today, but apart from that the two have

   nothing in common. Hence, in such cases add the exact model number, which

   for example are '9380' or '7390' for XPS 13 models introduced during 2019.

   Names like 'Lenovo Thinkpad T590' are also somewhat ambiguous: there are

   variants of this laptop with and without a dedicated graphics chip, so try

   to find the exact model name or specify the main components.



 * Mention the relevant software in use. If you have problems with loading

   modules, you want to mention the versions of kmod, systemd, and udev in use.

   If one of the DRM drivers misbehaves, you want to state the versions of

   libdrm and Mesa; also specify your Wayland compositor or the X-Server and

   its driver. If you have a filesystem issue, mention the version of

   corresponding filesystem utilities (e2fsprogs, btrfs-progs, xfsprogs, ...).



 * Gather additional information from the kernel that might be of interest. The

   output from ``lspci -nn`` will for example help others to identify what

   hardware you use. If you have a problem with hardware you even might want to

   make the output from ``sudo lspci -vvv`` available, as that provides

   insights how the components were configured. For some issues it might be

   good to include the contents of files like ``/proc/cpuinfo``,

   ``/proc/ioports``, ``/proc/iomem``, ``/proc/modules``, or

   ``/proc/scsi/scsi``. Some subsystem also offer tools to collect relevant

   information. One such tool is ``alsa-info.sh`` `which the audio/sound

   subsystem developers provide <https://www.alsa-project.org/wiki/AlsaInfo>`_.



Those examples should give your some ideas of what data might be wise to

attach, but you have to think yourself what will be helpful for others to know.

Don't worry too much about forgetting something, as developers will ask for

additional details they need. But making everything important available from

the start increases the chance someone will take a closer look.





The important part: the head of your report

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Now that you have the detailed part of the report prepared let's get to the

most important section: the first few sentences. Thus go to the top, add

something like 'The detailed description:' before the part you just wrote and

insert two newlines at the top. Now write one normal length paragraph that

describes the issue roughly. Leave out all boring details and focus on the

crucial parts readers need to know to understand what this is all about; if you

think this bug affects a lot of users, mention this to get people interested.



Once you did that insert two more lines at the top and write a one sentence

summary that explains quickly what the report is about. After that you have to

get even more abstract and write an even shorter subject/title for the report.



Now that you have written this part take some time to optimize it, as it is the

most important parts of your report: a lot of people will only read this before

they decide if reading the rest is time well spent.



Now send or file the report like the :ref:`MAINTAINERS <maintainers>` file told

you, unless it's one of those 'issues of high priority' outlined earlier: in

that case please read the next subsection first before sending the report on

its way.



Special handling for high priority issues

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Reports for high priority issues need special handling.



**Severe bugs**: make sure the subject or ticket title as well as the first

paragraph makes the severeness obvious.



**Regressions**: If the issue is a regression add [REGRESSION] to the mail's

subject or the title in the bug-tracker. If you did not perform a bisection

mention at least the latest mainline version you tested that worked fine (say

5.7) and the oldest where the issue occurs (say 5.8). If you did a successful

bisection mention the commit id and subject of the change that causes the

regression. Also make sure to add the author of that change to your report; if

you need to file your bug in a bug-tracker forward the report to him in a

private mail and mention where your filed it.



**Security issues**: for these issues your will have to evaluate if a

short-term risk to other users would arise if details were publicly disclosed.

If that's not the case simply proceed with reporting the issue as described.

For issues that bear such a risk you will need to adjust the reporting process

slightly:



 * If the MAINTAINERS file instructed you to report the issue by mail, do not

   CC any public mailing lists.



 * If you were supposed to file the issue in a bug tracker make sure to mark

   the ticket as 'private' or 'security issue'. If the bug tracker does not

   offer a way to keep reports private, forget about it and send your report as

   a private mail to the maintainers instead.



In both cases make sure to also mail your report to the addresses the

MAINTAINERS file lists in the section 'security contact'. Ideally directly CC

them when sending the report by mail. If you filed it in a bug tracker, forward

the report's text to these addresses; but on top of it put a small note where

you mention that you filed it with a link to the ticket.



See 'Documentation/admin-guide/security-bugs.rst' for more information.





Duties after the report went out

--------------------------------



    *Wait for reactions and keep the thing rolling until you can accept the

    outcome in one way or the other. Thus react publicly and in a timely manner

    to any inquiries. Test proposed fixes. Do proactive testing: retest with at

    least every first release candidate (RC) of a new mainline version and

    report your results. Send friendly reminders if things stall. And try to

    help yourself, if you don't get any help or if it's unsatisfying.*



If your report was good and you are really lucky then one of the developers

might immediately spot what's causing the issue; they then might write a patch

to fix it, test it, and send it straight for integration in mainline while

tagging it for later backport to stable and longterm kernels that need it. Then

all you need to do is reply with a 'Thank you very much' and switch to a version

with the fix once it gets released.



But this ideal scenario rarely happens. That's why the job is only starting

once you got the report out. What you'll have to do depends on the situations,

but often it will be the things listed below. But before digging into the

details, here are a few important things you need to keep in mind for this part

of the process.





General advice for further interactions

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



**Always reply in public**: When you filed the issue in a bug tracker, always

reply there and do not contact any of the developers privately about it. For

mailed reports always use the 'Reply-all' function when replying to any mails

you receive. That includes mails with any additional data you might want to add

to your report: go to your mail applications 'Sent' folder and use 'reply-all'

on your mail with the report. This approach will make sure the public mailing

list(s) and everyone else that gets involved over time stays in the loop; it

also keeps the mail thread intact, which among others is really important for

mailing lists to group all related mails together.



There are just two situations where a comment in a bug tracker or a 'Reply-all'

is unsuitable:



 * Someone tells you to send something privately.



 * You were told to send something, but noticed it contains sensitive

   information that needs to be kept private. In that case it's okay to send it

   in private to the developer that asked for it. But note in the ticket or a

   mail that you did that, so everyone else knows you honored the request.



**Do research before asking for clarifications or help**: In this part of the

process someone might tell you to do something that requires a skill you might

not have mastered yet. For example, you might be asked to use some test tools

you never have heard of yet; or you might be asked to apply a patch to the

Linux kernel sources to test if it helps. In some cases it will be fine sending

a reply asking for instructions how to do that. But before going that route try

to find the answer own your own by searching the internet; alternatively

consider asking in other places for advice. For example ask a friend or post

about it to a chatroom or forum you normally hang out.



**Be patient**: If you are really lucky you might get a reply to your report

within a few hours. But most of the time it will take longer, as maintainers

are scattered around the globe and thus might be in a different time zone – one

where they already enjoy their night away from keyboard.



In general, kernel developers will take one to five business days to respond to

reports. Sometimes it will take longer, as they might be busy with the merge

windows, other work, visiting developer conferences, or simply enjoying a long

summer holiday.



The 'issues of high priority' (see above for an explanation) are an exception

here: maintainers should address them as soon as possible; that's why you

should wait a week at maximum (or just two days if it's something urgent)

before sending a friendly reminder.



Sometimes the maintainer might not be responding in a timely manner; other

times there might be disagreements, for example if an issue qualifies as

regression or not. In such cases raise your concerns on the mailing list and

ask others for public or private replies how to move on. If that fails, it

might be appropriate to get a higher authority involved. In case of a WiFi

driver that would be the wireless maintainers; if there are no higher level

maintainers or all else fails, it might be one of those rare situations where

it's okay to get Linus Torvalds involved.



**Proactive testing**: Every time the first pre-release (the 'rc1') of a new

mainline kernel version gets released, go and check if the issue is fixed there

or if anything of importance changed. Mention the outcome in the ticket or in a

mail you sent as reply to your report (make sure it has all those in the CC

that up to that point participated in the discussion). This will show your

commitment and that you are willing to help. It also tells developers if the

issue persists and makes sure they do not forget about it. A few other

occasional retests (for example with rc3, rc5 and the final) are also a good

idea, but only report your results if something relevant changed or if you are

writing something anyway.



With all these general things off the table let's get into the details of how

to help to get issues resolved once they were reported.



Inquires and testing request

~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Here are your duties in case you got replies to your report:



**Check who you deal with**: Most of the time it will be the maintainer or a

developer of the particular code area that will respond to your report. But as

issues are normally reported in public it could be anyone that's replying —

including people that want to help, but in the end might guide you totally off

track with their questions or requests. That rarely happens, but it's one of

many reasons why it's wise to quickly run an internet search to see who you're

interacting with. By doing this you also get aware if your report was heard by

the right people, as a reminder to the maintainer (see below) might be in order

later if discussion fades out without leading to a satisfying solution for the

issue.



**Inquiries for data**: Often you will be asked to test something or provide

additional details. Try to provide the requested information soon, as you have

the attention of someone that might help and risk losing it the longer you

wait; that outcome is even likely if you do not provide the information within

a few business days.



**Requests for testing**: When you are asked to test a diagnostic patch or a

possible fix, try to test it in timely manner, too. But do it properly and make

sure to not rush it: mixing things up can happen easily and can lead to a lot

of confusion for everyone involved. A common mistake for example is thinking a

proposed patch with a fix was applied, but in fact wasn't. Things like that

happen even to experienced testers occasionally, but they most of the time will

notice when the kernel with the fix behaves just as one without it.



What to do when nothing of substance happens

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Some reports will not get any reaction from the responsible Linux kernel

developers; or a discussion around the issue evolved, but faded out with

nothing of substance coming out of it.



In these cases wait two (better: three) weeks before sending a friendly

reminder: maybe the maintainer was just away from keyboard for a while when

your report arrived or had something more important to take care of. When

writing the reminder, kindly ask if anything else from your side is needed to

get the ball running somehow. If the report got out by mail, do that in the

first lines of a mail that is a reply to your initial mail (see above) which

includes a full quote of the original report below: that's on of those few

situations where such a 'TOFU' (Text Over, Fullquote Under) is the right

approach, as then all the recipients will have the details at hand immediately

in the proper order.



After the reminder wait three more weeks for replies. If you still don't get a

proper reaction, you first should reconsider your approach. Did you maybe try

to reach out to the wrong people? Was the report maybe offensive or so

confusing that people decided to completely stay away from it? The best way to

rule out such factors: show the report to one or two people familiar with FLOSS

issue reporting and ask for their opinion. Also ask them for their advice how

to move forward. That might mean: prepare a better report and make those people

review it before you send it out. Such an approach is totally fine; just

mention that this is the second and improved report on the issue and include a

link to the first report.



If the report was proper you can send a second reminder; in it ask for advice

why the report did not get any replies. A good moment for this second reminder

mail is shortly after the first pre-release (the 'rc1') of a new Linux kernel

version got published, as you should retest and provide a status update at that

point anyway (see above).



If the second reminder again results in no reaction within a week, try to

contact a higher-level maintainer asking for advice: even busy maintainers by

then should at least have sent some kind of acknowledgment.



Remember to prepare yourself for a disappointment: maintainers ideally should

react somehow to every issue report, but they are only obliged to fix those

'issues of high priority' outlined earlier. So don't be too devastating if you

get a reply along the lines of 'thanks for the report, I have more important

issues to deal with currently and won't have time to look into this for the

foreseeable future'.



It's also possible that after some discussion in the bug tracker or on a list

nothing happens anymore and reminders don't help to motivate anyone to work out

a fix. Such situations can be devastating, but is within the cards when it

comes to Linux kernel development. This and several other reasons for not

getting help are explained in 'Why some issues won't get any reaction or remain

unfixed after being reported' near the end of this document.



Don't get devastated if you don't find any help or if the issue in the end does

not get solved: the Linux kernel is FLOSS and thus you can still help yourself.

You for example could try to find others that are affected and team up with

them to get the issue resolved. Such a team could prepare a fresh report

together that mentions how many you are and why this is something that in your

option should get fixed. Maybe together you can also narrow down the root cause

or the change that introduced a regression, which often makes developing a fix

easier. And with a bit of luck there might be someone in the team that knows a

bit about programming and might be able to write a fix.

_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss