Update REPORTING-BUGS
RFC PATCH 1/1 Update REPORTING-BUGS
Hi,
The recent "kernel bugzilla is FPOS" thread made me think that it might be a good idea to update REPORTING-BUGS, so that it's more "friendly" to people who want to report a kernel bug for the first time.
The patch below does that, but it's more a means to spark a discussion than anything else.
Comments are obviously welcome. :-)
Greetings,
Rafael
---
From: Rafael J. Wysocki <[email protected]>
Update REPORTING-BUGS to reflect the current common practice and to provide inexperienced bug reporters with some more information.
--- REPORTING-BUGS | 160 +++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 99 insertions(+), 61 deletions(-)
REPORTING-BUGS +99 -61
@@ -1,64 +1,102 @@ -[Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ] - - What follows is a suggested procedure for reporting Linux bugs. You -aren't obliged to use the bug reporting format, it is provided as a guide -to the kind of information that can be useful to developers - no more. - - If the failure includes an "OOPS:" type message in your log or on -screen please read "Documentation/oops-tracing.txt" before posting your -bug report. This explains what you should do with the "Oops" information -to make it useful to the recipient. - - Send the output to the maintainer of the kernel area that seems to -be involved with the problem. Don't worry too much about getting the -wrong person. If you are unsure send it to the person responsible for the -code relevant to what you were doing. If it occurs repeatably try and -describe how to recreate it. That is worth even more than the oops itself. -The list of maintainers is in the MAINTAINERS file in this directory. - - If it is a security bug, please copy the Security Contact listed -in the MAINTAINERS file. They can help coordinate bugfix and disclosure. -See Documentation/SecurityBugs for more information. - - If you are totally stumped as to whom to send the report, send it to [email protected]. (For more information on the linux-kernel -mailing list see http://www.tux.org/lkml/). - -This is a suggested format for a bug report sent to the Linux kernel mailing -list. Having a standardized bug report form makes it easier for you not to -overlook things, and easier for the developers to find the pieces of -information they're really interested in. Don't feel you have to follow it. - - First run the ver_linux script included as scripts/ver_linux, which -reports the version of some important subsystems. Run this script with -the command "sh scripts/ver_linux". - -Use that information to fill in all fields of the bug report form, and -post it to the mailing list with a subject of "PROBLEM: <one line -summary from [1.]>" for easy identification by the developers. - -[1.] One line summary of the problem: -[2.] Full description of the problem/report: -[3.] Keywords (i.e., modules, networking, kernel): -[4.] Kernel information -[4.1.] Kernel version (from /proc/version): -[4.2.] Kernel .config file: -[5.] Most recent kernel version which did not have the bug: -[6.] Output of Oops.. message (if applicable) with symbolic information - resolved (see Documentation/oops-tracing.txt) -[7.] A small shell script or example program which triggers the - problem (if possible) -[8.] Environment -[8.1.] Software (add the output of the ver_linux script here) -[8.2.] Processor information (from /proc/cpuinfo): -[8.3.] Module information (from /proc/modules): -[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) -[8.5.] PCI information ('lspci -vvv' as root) -[8.6.] SCSI information (from /proc/scsi/scsi) -[8.7.] Other information that might be relevant to the problem - (please look in /proc and include all information that you - think to be relevant): -[X.] Other notes, patches, fixes, workarounds: +Reporting Linux kernel bugs +What follows is a recommended procedure for reporting bug in the Linux kernel. +Still, you are not obliged to use the suggested bug reporting format, it is +provided as a guide to the kind of information that can be useful to developers. + +In general, the kernel developers' preferred way of reporting bugs is email, +because it allows them to react quickly to the problems that are easy to fix. +Still, later on, if the reported problem turns out to be difficult, you may be +asked to open an entry in the kernel Bugzilla at http://bugzilla.kernel.org . +Usually, this requires you to do some more work than just sending an email +message with a bug report, but it often is necessary to collect all information +related to the reported bug in one place, so that it is easily accessible at +any time later. + +Email messages containing bug reports should generally be sent to the +Linux Kernel Mailing List (LKML) <[email protected]> and to the +mailing list dedicated to the affected subsystem. You may send a bug report to +three mailing lists simultaneously, if you think that it is necessry. +[However, if you send them to more than three lists at a time, people will +likely get angry with you.] + +It also is a good idea to notify the maintainer of the affected subsystem and +the maintainer of the tree in which the bug is present by adding their email +addresses to the Cc list of the bug report message. The email addresses of +maintainers of the majority of kernel subsystems can be found in the MAINTAINERS +file, but you should not worry too much about getting a wrong person. + +If you know which patch has caused the problem to appear, you should also add +the email address of its author to the Cc list of your bug report (this address +is usually present in the 'From:' field of the patch header). Additionally, +it is recommended to notify all of the people involved in the process of +merging the patch (you can find their addresses in the 'Signed-off-by:' and +'Acked-by:' or 'Reviewed-by:' fields of the patch header). This way you can +increase the probability that someone "in the know" will notice the report and +respond to it quickly. Apart from this, you should make it clear that your +message contains a bug report, for example by adding the word "BUG" in front +of the message's subject line. If the bug is a regression (ie. one of the +previous kernel versions worked correctly), please put the word "REGRESSION" in +there instead. + +Unfortunately, sometimes bug reports are not responded to even if they contain +all of the right email addresses etc. If that happens to your bug report, you +should first check if it has not been intercepted by a spam filter. This is +easy if you have sent the report to a mailing list, since in that case it only +is necessary to look into the list's archives to see if the message is there. +If it turns out that the report has reached the list and no one is responding to +it, the developers might have overlooked it or they may be too busy to take care +of it right now. In that case you should wait for some time (usually, a couple +of days) and send it once again (if you resend the report, you may add the word +"resend" to the message's subject to indicate that this is not the first time). +If that does not help and there still is no response, it is best to open a new +entry in the Bugzilla at http://bugzilla.kernel.org . If you have already done +that, send messages to the appropriate lists and people periodically to remind +of the issue. + +As far as the contents of bug reports are concerned, you should generally avoid +putting irrelevant information into them. Of course, that may be difficult, +because you may not know which information is relevant in given particular case. +Still, you can always safely assume that if more information is needed, you will +be asked to provide it. + +First of all, you need to say what the bug is, which kernel version it is +present in and how to reproduce it. You also need to describe the symptoms and +include all of the corresponding kernel messages, if you can collect them. In +particular, if the failure includes an "Oops:" type message in your log or on +screen please read "Documentation/oops-tracing.txt" before posting your bug +report. This explains what you should do with the "Oops" information to make it +useful to the recipient. + +Generally, the following things are appreciated in a bug report: + +* One line summary of the reported problem +* Description of the problem +* Version of the kernel in which the problem appears +* The last known version of the kernel in which the problem does not appear (if + applicable) +* Architecture of the system on which the problem is observed (that may + include some more detailed hardware information if the problem seems to be + hardware-related) +* Steps to reproduce the problem +* Kernel messages related to the problem (if available) +* Concise description of software environment in which the problem appears (as + per the output of scripts/ver_linux) + +Additionally, if you know which patch has introduced the problem, the name of it +or the corresponding git commit name should be included in the report. [Please +read Documentation/BUG-HUNTING to learn how you can find the "guilty" patch.] + +The version of the kernel can be read from the output of scripts/ver_linux or +directly from /proc/version . Still, if you use git to download the kernel +sources, you can obtain more precise version information by running +'git describe' from within the root of the kernel source directory. + +After reporting a bug you may be provided with a patch to test. In that case +you ought to test it and report back to the developer who have sent it to you +whether or not it fixes the bug. If it does not fix the bug, you will likely +receive more patches to test. In any case, please be patient and work with the +developers until the issue is resolved. Thank you +
REPORTING-BUGS line 14
Quoted 7 lines · Rafael J. Wysocki
...
REPORTING-BUGS +5
-0+Reporting Linux kernel bugs +Usually, this requires you to do some more work than just sending an email +message with a bug report, but it often is necessary to collect all information +related to the reported bug in one place, so that it is easily accessible at +any time later.
I wouldn't say creating an account (if you don't already have one) plus 5 additional mouse clicks per bug report are substancially more work.
REPORTING-BUGS
Quoted 3 lines
REPORTING-BUGS +3
-0+Email messages containing bug reports should generally be sent to the +Linux Kernel Mailing List (LKML) <[email protected]> and to the +mailing list dedicated to the affected subsystem.
How should a newbie find the correct mailing list?
Benchmark:
Easier than the "some more work" when using Bugzilla.
REPORTING-BUGS line 27
Quoted 6 lines
...
REPORTING-BUGS +5
-0+It also is a good idea to notify the maintainer of the affected subsystem and +the maintainer of the tree in which the bug is present by adding their email +addresses to the Cc list of the bug report message. The email addresses of +maintainers of the majority of kernel subsystems can be found in the MAINTAINERS +file, but you should not worry too much about getting a wrong person.
If you don't already know MAINTAINERS well then finding the right component in Bugzilla is much easier.
Quoted 17 lines
REPORTING-BUGS +17
-0+If you know which patch has caused the problem to appear, you should also add +the email address of its author to the Cc list of your bug report (this address +is usually present in the 'From:' field of the patch header). Additionally, +it is recommended to notify all of the people involved in the process of +merging the patch (you can find their addresses in the 'Signed-off-by:' and +'Acked-by:' or 'Reviewed-by:' fields of the patch header). This way you can +increase the probability that someone "in the know" will notice the report and +respond to it quickly. Apart from this, you should make it clear that your +message contains a bug report, for example by adding the word "BUG" in front +of the message's subject line. If the bug is a regression (ie. one of the +previous kernel versions worked correctly), please put the word "REGRESSION" in +there instead. + +Unfortunately, sometimes bug reports are not responded to even if they contain +all of the right email addresses etc. If that happens to your bug report, you +should first check if it has not been intercepted by a spam filter. This is +easy if you have sent the report to a mailing list, since in that case it only
REPORTING-BUGS line 55
Quoted 10 lines
REPORTING-BUGS +10
-0+is necessary to look into the list's archives to see if the message is there. +If it turns out that the report has reached the list and no one is responding to +it, the developers might have overlooked it or they may be too busy to take care +of it right now. In that case you should wait for some time (usually, a couple +of days) and send it once again (if you resend the report, you may add the word +"resend" to the message's subject to indicate that this is not the first time). +If that does not help and there still is no response, it is best to open a new +entry in the Bugzilla at http://bugzilla.kernel.org . If you have already done +that, send messages to the appropriate lists and people periodically to remind +of the issue.
What about recommending a cronjob that resends the bug report every
three days? ;-)
Really, we must define _one_ way for people to report a bug, and how developers are reminded is _our_ job.
Quoted 3 lines
...
+Generally, the following things are appreciated in a bug report:
...
If you expect people to read and follow this, wouldn't it be easier to simply point them to open the bug in Bugzilla where we already have a template asking these questions?
You could replace the whole contents of this file with:
Go to http://bugzilla.kernel.org/ and click on "Enter a new bug report".
It's a pity that we manage to add/change an average of 100.000 bugs^Wlines of code each month, but do not have one generally accepted and working process for bug reports.
Quoted 2 lines
Thank you
+
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 12 lines · Adrian Bunk
REPORTING-BUGS line 14
Quoted 7 lines · Rafael J. Wysocki
...
REPORTING-BUGS +5
-0+Reporting Linux kernel bugs +Usually, this requires you to do some more work than just sending an email +message with a bug report, but it often is necessary to collect all information +related to the reported bug in one place, so that it is easily accessible at +any time later.I wouldn't say creating an account (if you don't already have one) plus 5 additional mouse clicks per bug report are substancially more work.
Plus generating some information that it asks you for and that may or may not be relevant to your report.
Quoted 5 lines
REPORTING-BUGS
Quoted 3 lines
REPORTING-BUGS +3
-0+Email messages containing bug reports should generally be sent to the +Linux Kernel Mailing List (LKML) <[email protected]> and to the +mailing list dedicated to the affected subsystem.How should a newbie find the correct mailing list?
Read MAINTAINERS? Ok, I should have said about that.
Quoted 2 lines
Benchmark:
Easier than the "some more work" when using Bugzilla.
Nope. Please try to file a report against libata/PATA using the Bugzilla. Good luck. ;-)
Quoted 9 lines
REPORTING-BUGS line 27
Quoted 6 lines
...
REPORTING-BUGS +5
-0+It also is a good idea to notify the maintainer of the affected subsystem and +the maintainer of the tree in which the bug is present by adding their email +addresses to the Cc list of the bug report message. The email addresses of +maintainers of the majority of kernel subsystems can be found in the MAINTAINERS +file, but you should not worry too much about getting a wrong person.If you don't already know
MAINTAINERSwell then finding the right component in Bugzilla is much easier.
I disagree. How a newbie is supposed to know what AIO and DIO mean and WTH is the difference between LVM2/DM and MD?
I took only the IO/Storage submenu as an example, but there are other things like that. For instance, what is the difference between "Flash/Memory Technology Devices" and MMC/SD? Why "Hotplug" is under "Drivers" and WTH does it *mean*? What "W1" means for that matter?? Etc.
Quoted 31 lines
Quoted 17 lines
REPORTING-BUGS +17
-0+If you know which patch has caused the problem to appear, you should also add +the email address of its author to the Cc list of your bug report (this address +is usually present in the 'From:' field of the patch header). Additionally, +it is recommended to notify all of the people involved in the process of +merging the patch (you can find their addresses in the 'Signed-off-by:' and +'Acked-by:' or 'Reviewed-by:' fields of the patch header). This way you can +increase the probability that someone "in the know" will notice the report and +respond to it quickly. Apart from this, you should make it clear that your +message contains a bug report, for example by adding the word "BUG" in front +of the message's subject line. If the bug is a regression (ie. one of the +previous kernel versions worked correctly), please put the word "REGRESSION" in +there instead. + +Unfortunately, sometimes bug reports are not responded to even if they contain +all of the right email addresses etc. If that happens to your bug report, you +should first check if it has not been intercepted by a spam filter. This is +easy if you have sent the report to a mailing list, since in that case it onlyREPORTING-BUGS line 55
Quoted 10 lines
REPORTING-BUGS +10
-0+is necessary to look into the list's archives to see if the message is there. +If it turns out that the report has reached the list and no one is responding to +it, the developers might have overlooked it or they may be too busy to take care +of it right now. In that case you should wait for some time (usually, a couple +of days) and send it once again (if you resend the report, you may add the word +"resend" to the message's subject to indicate that this is not the first time). +If that does not help and there still is no response, it is best to open a new +entry in the Bugzilla at http://bugzilla.kernel.org . If you have already done +that, send messages to the appropriate lists and people periodically to remind +of the issue.What about recommending a cronjob that resends the bug report every
three days? ;-)
Quoted 2 lines
Really, we must define _one_ way for people to report a bug, and how developers are reminded is _our_ job.
Well, who's "we" in that context? IOW, who's job exactly it's supposed to be?
Quoted 7 lines
Quoted 3 lines
...
+Generally, the following things are appreciated in a bug report:
...If you expect people to read and follow this, wouldn't it be easier to simply point them to open the bug in Bugzilla where we already have a template asking these questions?
I don't think so and please refer to the examples above.
Quoted 6 lines
You could replace the whole contents of this file with:
Go to http://bugzilla.kernel.org/ and click on "Enter a new bug report".It's a pity that we manage to add/change an average of 100.000 bugs^Wlines of code each month, but do not have one generally accepted and working process for bug reports.
It's a pity that we do not have one, indeed, and so perhaps it's a good idea to try to create one? Not necessarily focusing on the Bugzilla for a little while. ;-)
Greetings,
Rafael
Quoted 14 lines · Rafael J. Wysocki
Quoted 12 lines · Adrian Bunk
REPORTING-BUGS line 14
Quoted 7 lines · Rafael J. Wysocki
...
REPORTING-BUGS +5
-0+Reporting Linux kernel bugs +Usually, this requires you to do some more work than just sending an email +message with a bug report, but it often is necessary to collect all information +related to the reported bug in one place, so that it is easily accessible at +any time later.I wouldn't say creating an account (if you don't already have one) plus 5 additional mouse clicks per bug report are substancially more work.
Quoted 2 lines
Plus generating some information that it asks you for and that may or may not be relevant to your report.
What are you talking about?
The default text in the "Description:" field?
Quoted 6 lines
Quoted 5 lines
REPORTING-BUGS
Quoted 3 lines
REPORTING-BUGS +3
-0+Email messages containing bug reports should generally be sent to the +Linux Kernel Mailing List (LKML) <[email protected]> and to the +mailing list dedicated to the affected subsystem.How should a newbie find the correct mailing list?
Quoted 7 lines
Read
MAINTAINERS? Ok, I should have said about that.Quoted 2 lines
Benchmark:
Easier than the "some more work" when using Bugzilla.Nope. Please try to file a report against libata/PATA using the Bugzilla. Good luck. ;-)
$ grep PATA MAINTAINERS $
Quoted 10 lines
Quoted 9 lines
REPORTING-BUGS line 27
Quoted 6 lines
...
REPORTING-BUGS +5
-0+It also is a good idea to notify the maintainer of the affected subsystem and +the maintainer of the tree in which the bug is present by adding their email +addresses to the Cc list of the bug report message. The email addresses of +maintainers of the majority of kernel subsystems can be found in the MAINTAINERS +file, but you should not worry too much about getting a wrong person.If you don't already know
MAINTAINERSwell then finding the right component in Bugzilla is much easier.
Quoted 7 lines
I disagree. How a newbie is supposed to know what AIO and DIO mean and WTH is the difference between LVM2/DM and MD?
I took only the IO/Storage submenu as an example, but there are other things like that. For instance, what is the difference between "Flash/Memory Technology Devices" and MMC/SD? Why "Hotplug" is under "Drivers" and WTH does it *mean*? What "W1" means for that matter?? Etc.
Then let's get that improved.
Quoted 31 lines
Quoted 31 lines
Quoted 17 lines
REPORTING-BUGS +17
-0+If you know which patch has caused the problem to appear, you should also add +the email address of its author to the Cc list of your bug report (this address +is usually present in the 'From:' field of the patch header). Additionally, +it is recommended to notify all of the people involved in the process of +merging the patch (you can find their addresses in the 'Signed-off-by:' and +'Acked-by:' or 'Reviewed-by:' fields of the patch header). This way you can +increase the probability that someone "in the know" will notice the report and +respond to it quickly. Apart from this, you should make it clear that your +message contains a bug report, for example by adding the word "BUG" in front +of the message's subject line. If the bug is a regression (ie. one of the +previous kernel versions worked correctly), please put the word "REGRESSION" in +there instead. + +Unfortunately, sometimes bug reports are not responded to even if they contain +all of the right email addresses etc. If that happens to your bug report, you +should first check if it has not been intercepted by a spam filter. This is +easy if you have sent the report to a mailing list, since in that case it onlyREPORTING-BUGS line 55
Quoted 10 lines
REPORTING-BUGS +10
-0+is necessary to look into the list's archives to see if the message is there. +If it turns out that the report has reached the list and no one is responding to +it, the developers might have overlooked it or they may be too busy to take care +of it right now. In that case you should wait for some time (usually, a couple +of days) and send it once again (if you resend the report, you may add the word +"resend" to the message's subject to indicate that this is not the first time). +If that does not help and there still is no response, it is best to open a new +entry in the Bugzilla at http://bugzilla.kernel.org . If you have already done +that, send messages to the appropriate lists and people periodically to remind +of the issue.What about recommending a cronjob that resends the bug report every
three days? ;-)
Quoted 4 lines
Quoted 2 lines
Really, we must define _one_ way for people to report a bug, and how developers are reminded is _our_ job.
Well, who's "we" in that context? IOW, who's job exactly it's supposed to be?
"we" = "we kernel developers"
And Natalie seems to be the person being paid for doing such stuff...
Quoted 13 lines
Quoted 7 lines
Quoted 3 lines
...
+Generally, the following things are appreciated in a bug report:
...If you expect people to read and follow this, wouldn't it be easier to simply point them to open the bug in Bugzilla where we already have a template asking these questions?
I don't think so and please refer to the examples above.
Quoted 3 lines
You could replace the whole contents of this file with:
Go to http://bugzilla.kernel.org/ and click on "Enter a new bug report".
Quoted 7 lines
Quoted 3 lines
It's a pity that we manage to add/change an average of 100.000 bugs^Wlines of code each month, but do not have one generally accepted and working process for bug reports.
It's a pity that we do not have one, indeed, and so perhaps it's a good idea to try to create one? Not necessarily focusing on the Bugzilla for a little while. ;-)
I'm not focussed on Bugzilla.
But a submitter should send a bug report _once_ through one well-defined medium, this should result in the bug report not being lost, and every other communication of the submitter should be triggered by developers requesting additional information.
I don't care whether that's done with Bugzilla, some email based bug tracker like the Debian bug tracker, someone putting emails manually into some bug tracker like you are doing, or whatever else.
Quoted 2 lines
Greetings,
Rafael
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 3 lines · Adrian Bunk
Quoted 2 lines · Rafael J. Wysocki
Quoted 1 line · Adrian Bunk
On Sun, Nov 25, 2007 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
[--snip--]
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
How should a newbie find the correct mailing list?
Read
MAINTAINERS? Ok, I should have said about that.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Benchmark:
Easier than the "some more work" when using Bugzilla.Nope. Please try to file a report against libata/PATA using the Bugzilla. Good luck. ;-)
$ grep PATA MAINTAINERS $
Too bad (and this is a bug BTW).
Quoted 13 lines
Quoted 13 lines
Quoted 9 lines
REPORTING-BUGS line 27
Quoted 6 lines
...
REPORTING-BUGS +5
-0+It also is a good idea to notify the maintainer of the affected subsystem and +the maintainer of the tree in which the bug is present by adding their email +addresses to the Cc list of the bug report message. The email addresses of +maintainers of the majority of kernel subsystems can be found in the MAINTAINERS +file, but you should not worry too much about getting a wrong person.If you don't already know
MAINTAINERSwell then finding the right component in Bugzilla is much easier.I disagree. How a newbie is supposed to know what AIO and DIO mean and WTH is the difference between LVM2/DM and MD?
Quoted 6 lines
Quoted 4 lines
I took only the IO/Storage submenu as an example, but there are other things like that. For instance, what is the difference between "Flash/Memory Technology Devices" and MMC/SD? Why "Hotplug" is under "Drivers" and WTH does it *mean*? What "W1" means for that matter?? Etc.
Then let's get that improved.
OK
Who's supposed to be responsible for that?
[--snip--]
Quoted 31 lines
Quoted 5 lines
Quoted 3 lines
Really, we must define _one_ way for people to report a bug, and how developers are reminded is _our_ job.
Well, who's "we" in that context? IOW, who's job exactly it's supposed to be?
"we" = "we kernel developers"
And Natalie seems to be the person being paid for doing such stuff...
Quoted 13 lines
Quoted 7 lines
Quoted 3 lines
...
+Generally, the following things are appreciated in a bug report:
...If you expect people to read and follow this, wouldn't it be easier to simply point them to open the bug in Bugzilla where we already have a template asking these questions?
I don't think so and please refer to the examples above.
Quoted 3 lines
You could replace the whole contents of this file with:
Go to http://bugzilla.kernel.org/ and click on "Enter a new bug report".Quoted 7 lines
Quoted 3 lines
It's a pity that we manage to add/change an average of 100.000 bugs^Wlines of code each month, but do not have one generally accepted and working process for bug reports.
It's a pity that we do not have one, indeed, and so perhaps it's a good idea to try to create one? Not necessarily focusing on the Bugzilla for a little while. ;-)
Quoted 6 lines
I'm not focussed on Bugzilla.
But a submitter should send a bug report _once_ through one well-defined medium, this should result in the bug report not being lost, and every other communication of the submitter should be triggered by developers requesting additional information.
I don't think that have to be only *one* medium as long as we're able to track the bugs (see my last reply in the other thread).
Quoted 3 lines
I don't care whether that's done with Bugzilla, some email based bug tracker like the Debian bug tracker, someone putting emails manually into some bug tracker like you are doing, or whatever else.
That last solution doesn't scale very well ...
How about using the system in which it's possible to report bugs using both email and a web interface?
We can request that the address of the bug tracker be added to the Cc lists of bug reports sent by email and we can make it resend reports filed with it to the appropriate mailing lists and with the appropriate email headers. This is technically doable.
Greetings,
Rafael
Quoted 8 lines · Rafael J. Wysocki
On Sunday, 25 of November 2007, Adrian Bunk wrote:
...Quoted 3 lines
I don't care whether that's done with Bugzilla, some email based bug tracker like the Debian bug tracker, someone putting emails manually into some bug tracker like you are doing, or whatever else.
That last solution doesn't scale very well ...
Quoted 7 lines
How about using the system in which it's possible to report bugs using both email and a web interface?
We can request that the address of the bug tracker be added to the Cc lists of bug reports sent by email and we can make it resend reports filed with it to the appropriate mailing lists and with the appropriate email headers. This is technically doable.
You are trying to solve something that is not a problem.
It does not matter which medium we choose for getting bug reports.
The only thing that matters is that we get bug reports resolved within a reasonable amount of time.
Quoted 2 lines
Greetings,
Rafael
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 12 lines · Adrian Bunk
Quoted 11 lines · Rafael J. Wysocki
On Sunday, 25 of November 2007, Adrian Bunk wrote:
...Quoted 3 lines
I don't care whether that's done with Bugzilla, some email based bug tracker like the Debian bug tracker, someone putting emails manually into some bug tracker like you are doing, or whatever else.
That last solution doesn't scale very well ...
How about using the system in which it's possible to report bugs using both email and a web interface?
Quoted 6 lines
Quoted 4 lines
We can request that the address of the bug tracker be added to the Cc lists of bug reports sent by email and we can make it resend reports filed with it to the appropriate mailing lists and with the appropriate email headers. This is technically doable.
You are trying to solve something that is not a problem.
It _is_ a problem, because many bug are reported using email and not really tracked. The ones that I manually put into the Bugzilla are the tip of the iceberg (and BTW I'd prefer not to have to do that manually).
Every bug reported by email and not responded to by the right people, that is not a recent regression, is currently lost. I'd like to avoid that, if possible.
Quoted 1 line
It does not matter which medium we choose for getting bug reports.
[Well, you said that we should use a web interface for that. ;-)]
No, it doesn't, as long as the bug reports reach the right place. Now, the question is what's that.
IMO, ideally, for each subsystem there should be a mailing list to send bug reports to. The Bugzilla should forward the reports to these lists. On every such list there should be (at least) one person responsible for responding to the bug reports, if no one else responds first, and for forwarding the reports to the appropriate developers. This person should also be responsible for monitoring the status of each bug report sent to his/her list.
_Every_ bug report sent (including invalid ones) should be recorded in a bug tracking system (be it the Bugzilla or whatever else) along with all of it's history (at least, refernces to the bug's history should be stored), no matter how it's been handled. Moreover, a bug can only be resolved as "fixed" if there's a pointer to the exact commit fixing it in the bug's history.
Quoted 2 lines
The only thing that matters is that we get bug reports resolved within a reasonable amount of time.
I'm not sure if that's generally possible:
- What about the bugs that take 2 weeks or more to reproduce?
- What about the bugs that we _don't_ _know_ how to fix?
Rafael
Quoted 18 lines · Rafael J. Wysocki
Quoted 17 lines · Adrian Bunk
Quoted 15 lines · Rafael J. Wysocki
On Sunday, 25 of November 2007, Adrian Bunk wrote:
...Quoted 3 lines
I don't care whether that's done with Bugzilla, some email based bug tracker like the Debian bug tracker, someone putting emails manually into some bug tracker like you are doing, or whatever else.
That last solution doesn't scale very well ...
How about using the system in which it's possible to report bugs using both email and a web interface?
We can request that the address of the bug tracker be added to the Cc lists of bug reports sent by email and we can make it resend reports filed with it to the appropriate mailing lists and with the appropriate email headers. This is technically doable.
Quoted 8 lines
Quoted 1 line
You are trying to solve something that is not a problem.
It _is_ a problem, because many bug are reported using email and not really tracked. The ones that I manually put into the Bugzilla are the tip of the iceberg (and BTW I'd prefer not to have to do that manually).
Every bug reported by email and not responded to by the right people, that is not a recent regression, is currently lost. I'd like to avoid that, if possible.
This is solved by many other projects by asking the submitter to open a bug for the issue when he sends it in an email.
The submitter then simply copies the information from his email to his newly opened bug in the bug tracker.
-> no problem
Quoted 3 lines
Quoted 1 line
It does not matter which medium we choose for getting bug reports.
[Well, you said that we should use a web interface for that. ;-)]
I said a web interface is not worse than via email. And it's enough.
(And I e.g. wouldn't oppose using the Debian bug tracker where the web
interface only allows reading and everything has to be done via email if all kernel maintainers would agree to use this.)
Quoted 9 lines
No, it doesn't, as long as the bug reports reach the right place. Now, the question is what's that.
IMO, ideally, for each subsystem there should be a mailing list to send bug reports to. The Bugzilla should forward the reports to these lists. On every such list there should be (at least) one person responsible for responding to the bug reports, if no one else responds first, and for forwarding the reports to the appropriate developers. This person should also be responsible for monitoring the status of each bug report sent to his/her list.
After all discussions about crazy bug tracker features we are back at the real problem:
Where do we find the tree these people grow on?
Quoted 5 lines
_Every_ bug report sent (including invalid ones) should be recorded in a bug tracking system (be it the Bugzilla or whatever else) along with all of it's history (at least, refernces to the bug's history should be stored), no matter how it's been handled. Moreover, a bug can only be resolved as "fixed" if there's a pointer to the exact commit fixing it in the bug's history.
And back we are at crazy bug tracker features...
Quoted 6 lines
Quoted 2 lines
The only thing that matters is that we get bug reports resolved within a reasonable amount of time.
I'm not sure if that's generally possible:
- What about the bugs that take 2 weeks or more to reproduce?
- What about the bugs that we _don't_ _know_ how to fix?
We will never get 100% of all bugs fixed.
Let's get back to the fact that we have many bug reports that could be fixed within a reasonable amount of time but are not.
Quoted 1 line
Rafael
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 57 lines · Adrian Bunk
Quoted 18 lines · Rafael J. Wysocki
Quoted 17 lines · Adrian Bunk
Quoted 15 lines · Rafael J. Wysocki
On Sunday, 25 of November 2007, Adrian Bunk wrote:
...Quoted 3 lines
I don't care whether that's done with Bugzilla, some email based bug tracker like the Debian bug tracker, someone putting emails manually into some bug tracker like you are doing, or whatever else.
That last solution doesn't scale very well ...
How about using the system in which it's possible to report bugs using both email and a web interface?
We can request that the address of the bug tracker be added to the Cc lists of bug reports sent by email and we can make it resend reports filed with it to the appropriate mailing lists and with the appropriate email headers. This is technically doable.
Quoted 8 lines
Quoted 1 line
You are trying to solve something that is not a problem.
It _is_ a problem, because many bug are reported using email and not really tracked. The ones that I manually put into the Bugzilla are the tip of the iceberg (and BTW I'd prefer not to have to do that manually).
Every bug reported by email and not responded to by the right people, that is not a recent regression, is currently lost. I'd like to avoid that, if possible.
This is solved by many other projects by asking the submitter to open a bug for the issue when he sends it in an email.
The submitter then simply copies the information from his email to his newly opened bug in the bug tracker.
-> no problem
Quoted 3 lines
Quoted 1 line
It does not matter which medium we choose for getting bug reports.
[Well, you said that we should use a web interface for that. ;-)]
I said a web interface is not worse than via email. And it's enough.
(And I e.g. wouldn't oppose using the Debian bug tracker where the web
interface only allows reading and everything has to be done via email if all kernel maintainers would agree to use this.)Quoted 9 lines
No, it doesn't, as long as the bug reports reach the right place. Now, the question is what's that.
IMO, ideally, for each subsystem there should be a mailing list to send bug reports to. The Bugzilla should forward the reports to these lists. On every such list there should be (at least) one person responsible for responding to the bug reports, if no one else responds first, and for forwarding the reports to the appropriate developers. This person should also be responsible for monitoring the status of each bug report sent to his/her list.
Quoted 2 lines
After all discussions about crazy bug tracker features we are back at the real problem:
We started to discuss them, because you argued that the Bugzilla in its current shape was sufficient, which I didn't agree with and tried to give some arguments.
Quoted 1 line
Where do we find the tree these people grow on?
That's a good question, but either we find these people, or we'll start losing users at growing rates.
I'm afraid that's already happening ...
Quoted 7 lines
Quoted 5 lines
_Every_ bug report sent (including invalid ones) should be recorded in a bug tracking system (be it the Bugzilla or whatever else) along with all of it's history (at least, refernces to the bug's history should be stored), no matter how it's been handled. Moreover, a bug can only be resolved as "fixed" if there's a pointer to the exact commit fixing it in the bug's history.
And back we are at crazy bug tracker features...
No, they are not bug tracker features, but parts of a process that I think we should have in place.
Quoted 11 lines
Quoted 6 lines
Quoted 2 lines
The only thing that matters is that we get bug reports resolved within a reasonable amount of time.
I'm not sure if that's generally possible:
- What about the bugs that take 2 weeks or more to reproduce?
- What about the bugs that we _don't_ _know_ how to fix?We will never get 100% of all bugs fixed.
Let's get back to the fact that we have many bug reports that could be fixed within a reasonable amount of time but are not.
Do you have specific examples?
Rafael
Quoted 13 lines · Rafael J. Wysocki
Quoted 1 line · Adrian Bunk
On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
...
Quoted 10 lines
Quoted 9 lines
No, it doesn't, as long as the bug reports reach the right place. Now, the question is what's that.
IMO, ideally, for each subsystem there should be a mailing list to send bug reports to. The Bugzilla should forward the reports to these lists. On every such list there should be (at least) one person responsible for responding to the bug reports, if no one else responds first, and for forwarding the reports to the appropriate developers. This person should also be responsible for monitoring the status of each bug report sent to his/her list.
Quoted 6 lines
Quoted 2 lines
After all discussions about crazy bug tracker features we are back at the real problem:
We started to discuss them, because you argued that the Bugzilla in its current shape was sufficient, which I didn't agree with and tried to give some arguments.
The only real problem with the Bugzilla in it's current shape is that some developers do not use it.
Quoted 6 lines
Quoted 1 line
Where do we find the tree these people grow on?
That's a good question, but either we find these people, or we'll start losing users at growing rates.
I'm afraid that's already happening ...
Agreed. :-(
Quoted 10 lines
Quoted 7 lines
Quoted 5 lines
_Every_ bug report sent (including invalid ones) should be recorded in a bug tracking system (be it the Bugzilla or whatever else) along with all of it's history (at least, refernces to the bug's history should be stored), no matter how it's been handled. Moreover, a bug can only be resolved as "fixed" if there's a pointer to the exact commit fixing it in the bug's history.
And back we are at crazy bug tracker features...
No, they are not bug tracker features, but parts of a process that I think we should have in place.
The only real problem in our process is how to get reported bugs fixed.
Trying to define some peripheral process things when _the_ central part of the process is missing simply doesn't make much sense.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
The only thing that matters is that we get bug reports resolved within a reasonable amount of time.
I'm not sure if that's generally possible:
- What about the bugs that take 2 weeks or more to reproduce?
- What about the bugs that we _don't_ _know_ how to fix?
Quoted 6 lines
Quoted 4 lines
We will never get 100% of all bugs fixed.
Let's get back to the fact that we have many bug reports that could be fixed within a reasonable amount of time but are not.
Do you have specific examples?
Take e.g. #3938 or #4039 as examples.
Both are quite different, but both should be fixable within < 1 month. [1]
Quoted 1 line
Rafael
cu
Adrian
[1] bugs like #4039 might be easier to debug now that git has been written, but even without biseting it should be solvable
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 17 lines · Adrian Bunk
Quoted 16 lines · Rafael J. Wysocki
Quoted 1 line · Adrian Bunk
On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
...
Quoted 12 lines
Quoted 9 lines
No, it doesn't, as long as the bug reports reach the right place. Now, the question is what's that.
IMO, ideally, for each subsystem there should be a mailing list to send bug reports to. The Bugzilla should forward the reports to these lists. On every such list there should be (at least) one person responsible for responding to the bug reports, if no one else responds first, and for forwarding the reports to the appropriate developers. This person should also be responsible for monitoring the status of each bug report sent to his/her list.
After all discussions about crazy bug tracker features we are back at the real problem:
Quoted 6 lines
Quoted 3 lines
We started to discuss them, because you argued that the Bugzilla in its current shape was sufficient, which I didn't agree with and tried to give some arguments.
The only real problem with the Bugzilla in it's current shape is that some developers do not use it.
I disagree.
For example, I can't find the appropriate product/component combinations for some bugs that I put in there while registering recent regressions. Also, for some product/component combinations the notifications sent by the Bugzilla actually go to nowhere.
[Speaking of which, what should I do to make all of the bugs in the "Power management"->Hibernation/Suspend category go to [email protected] ?]
I'm not saying that the Bugzilla isn't useful (otherwise I wouldn't have used it), but IMO there are some problems with it.
Still, as you said, this isn't the real problem we have with handling bugs.
Quoted 17 lines
Quoted 6 lines
Quoted 1 line
Where do we find the tree these people grow on?
That's a good question, but either we find these people, or we'll start losing users at growing rates.
I'm afraid that's already happening ...
Agreed. :-(
Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
_Every_ bug report sent (including invalid ones) should be recorded in a bug tracking system (be it the Bugzilla or whatever else) along with all of it's history (at least, refernces to the bug's history should be stored), no matter how it's been handled. Moreover, a bug can only be resolved as "fixed" if there's a pointer to the exact commit fixing it in the bug's history.
And back we are at crazy bug tracker features...
Quoted 7 lines
Quoted 2 lines
No, they are not bug tracker features, but parts of a process that I think we should have in place.
The only real problem in our process is how to get reported bugs fixed.
Trying to define some peripheral process things when _the_ central part of the process is missing simply doesn't make much sense.
The only realistic way in which we can *try* to improve things is by increasing the pressure on developers who don't fix bugs timely, although they could.
To this end, we could, for example, periodically publish per-subsystem statistics of reported / handled / resolved bugs . That also would give us an idea of which subsystems are not sufficiently supported.
However, for this purpose we need to make sure that bug reports actually have a chance to be read by the appropriate people and we need some tools to monitor their activity without disturbing them too much (like some kind of passive tracking). I also realize that some people won't use the Bugzilla and there's no way to make them use it, so I'm trying to suggest some general albeit well defined rules for handling kernel bugs that can be followed by everyone regardless of whether or not he's using the Bugzilla.
Apart from this, I think that some kinds of bugs are fixed faster if they are reported by email and in many cases email is just a more convenient way of exchainging information between bug reporters and developers, so I don't think that ruling it out as a way of reporting bugs, just becuase we have the Bugzilla, would be the best idea.
The Bugzilla is useful to me and I think it might be useful to many people, but that doesn't necessarily mean that it'll be useful to everyone in any case.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
The only thing that matters is that we get bug reports resolved within a reasonable amount of time.
I'm not sure if that's generally possible:
- What about the bugs that take 2 weeks or more to reproduce?
- What about the bugs that we _don't_ _know_ how to fix?
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
We will never get 100% of all bugs fixed.
Let's get back to the fact that we have many bug reports that could be fixed within a reasonable amount of time but are not.
Do you have specific examples?
Take e.g. #3938
Are you sure that this one hasn't been fixed? The reporter doesn't seem to be responsive ...
Quoted 1 line
or #4039
Same here.
Quoted 1 line
as examples.
Greetings,
Rafael
Quoted 11 lines · Rafael J. Wysocki
Quoted 2 lines · Adrian Bunk
Quoted 1 line · Rafael J. Wysocki
On Monday, 26 of November 2007, Adrian Bunk wrote:
...
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
We will never get 100% of all bugs fixed.
Let's get back to the fact that we have many bug reports that could be fixed within a reasonable amount of time but are not.
Do you have specific examples?
Quoted 8 lines
Quoted 1 line
Take e.g. #3938
Are you sure that this one hasn't been fixed? The reporter doesn't seem to be responsive ...
Quoted 1 line
or #4039
Same here.
Saying "reporter doesn't seem to be responsive" is a joke if there was zero activity in solving any of these bugs for nearly three years.
They might (or might not) be fixed by chance now, but they should have been fixed in the beginning of 2005 as a result of the bug reports.
You can now claim these are too old, but you'll find for any bug age bugs that both should be solvable for a developer knowing the kernel code in question and that have not been seriously debugged.
Quoted 4 lines
Quoted 1 line
as examples.
Greetings,
Rafael
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 24 lines · Adrian Bunk
Quoted 11 lines · Rafael J. Wysocki
Quoted 2 lines · Adrian Bunk
Quoted 1 line · Rafael J. Wysocki
On Monday, 26 of November 2007, Adrian Bunk wrote:
...
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
We will never get 100% of all bugs fixed.
Let's get back to the fact that we have many bug reports that could be fixed within a reasonable amount of time but are not.
Do you have specific examples?
Quoted 8 lines
Quoted 1 line
Take e.g. #3938
Are you sure that this one hasn't been fixed? The reporter doesn't seem to be responsive ...
Quoted 1 line
or #4039
Same here.
Saying "reporter doesn't seem to be responsive" is a joke if there was zero activity in solving any of these bugs for nearly three years.
Quoted 6 lines
They might (or might not) be fixed by chance now, but they should have been fixed in the beginning of 2005 as a result of the bug reports.
You can now claim these are too old, but you'll find for any bug age bugs that both should be solvable for a developer knowing the kernel code in question and that have not been seriously debugged.
Arguably, we can't be sure that the bug wasn't worked on just because there's no confirmation of that in the Bugzilla. It _probably_ wasn't, but in fact that's uncertain.
OTOH, in both cases above you can't even assume that the appropriate developer was _aware_ of the bug report.
Which, BTW, is a problem even with the Bugzilla as it is configured today: it doesn't give you any guarantee that the bug report is heard of by the right people (unless, of course, it's forwarded to them by Andrew, that is, but this "mechanism" is not exactly a part of the Bugzilla itself ;-)).
For this reason, I'd like the maintainers/developers of every subsystem to provide us with an address of a mailing list considered as appropriate for sending bug reports related to this particular subsystem. Then, we can make the Bugzilla forward bug reports to these lists, so that Andrew or anyone else need not handle that manually.
Now, if we have such lists set up for all subsystems, we'll be able to just tell users to send bug reports there, either using the Bugzilla, or directly, with the assumption that the right people get those reports.
Then, the "we didn't know about the report" kind of excuse won't be viable any more and we'll be able to exert more directed pressure at the subsystems that aren't good enough at handling bugs.
Greetings,
Rafael
RFC PATCH 1/1 Update REPORTING-BUGS (rev. 2)
In reply to Rafael J. WysockiHi,
Quoted 10 lines · Rafael J. Wysocki
Hi,
The recent "kernel bugzilla is FPOS" thread made me think that it might be a good idea to update REPORTING-BUGS, so that it's more "friendly" to people who want to report a kernel bug for the first time.
The patch below does that, but it's more a means to spark a discussion than anything else.
Comments are obviously welcome. :-)
For completness, below is an updated version of the patch, modified to take some Adrian's comments into account.
Comments welcome.
Greetings,
Rafael
---
From: Rafael J. Wysocki <[email protected]>
Update REPORTING-BUGS to reflect the current common practice and to provide inexperienced bug reporters with some more information.
--- REPORTING-BUGS | 160 +++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 99 insertions(+), 61 deletions(-)
REPORTING-BUGS +99 -61
@@ -1,64 +1,102 @@ -[Some of this is taken from Frohwalt Egerer's original linux-kernel FAQ] - - What follows is a suggested procedure for reporting Linux bugs. You -aren't obliged to use the bug reporting format, it is provided as a guide -to the kind of information that can be useful to developers - no more. - - If the failure includes an "OOPS:" type message in your log or on -screen please read "Documentation/oops-tracing.txt" before posting your -bug report. This explains what you should do with the "Oops" information -to make it useful to the recipient. - - Send the output to the maintainer of the kernel area that seems to -be involved with the problem. Don't worry too much about getting the -wrong person. If you are unsure send it to the person responsible for the -code relevant to what you were doing. If it occurs repeatably try and -describe how to recreate it. That is worth even more than the oops itself. -The list of maintainers is in the MAINTAINERS file in this directory. - - If it is a security bug, please copy the Security Contact listed -in the MAINTAINERS file. They can help coordinate bugfix and disclosure. -See Documentation/SecurityBugs for more information. - - If you are totally stumped as to whom to send the report, send it to [email protected]. (For more information on the linux-kernel -mailing list see http://www.tux.org/lkml/). - -This is a suggested format for a bug report sent to the Linux kernel mailing -list. Having a standardized bug report form makes it easier for you not to -overlook things, and easier for the developers to find the pieces of -information they're really interested in. Don't feel you have to follow it. - - First run the ver_linux script included as scripts/ver_linux, which -reports the version of some important subsystems. Run this script with -the command "sh scripts/ver_linux". - -Use that information to fill in all fields of the bug report form, and -post it to the mailing list with a subject of "PROBLEM: <one line -summary from [1.]>" for easy identification by the developers. - -[1.] One line summary of the problem: -[2.] Full description of the problem/report: -[3.] Keywords (i.e., modules, networking, kernel): -[4.] Kernel information -[4.1.] Kernel version (from /proc/version): -[4.2.] Kernel .config file: -[5.] Most recent kernel version which did not have the bug: -[6.] Output of Oops.. message (if applicable) with symbolic information - resolved (see Documentation/oops-tracing.txt) -[7.] A small shell script or example program which triggers the - problem (if possible) -[8.] Environment -[8.1.] Software (add the output of the ver_linux script here) -[8.2.] Processor information (from /proc/cpuinfo): -[8.3.] Module information (from /proc/modules): -[8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) -[8.5.] PCI information ('lspci -vvv' as root) -[8.6.] SCSI information (from /proc/scsi/scsi) -[8.7.] Other information that might be relevant to the problem - (please look in /proc and include all information that you - think to be relevant): -[X.] Other notes, patches, fixes, workarounds: +Reporting Linux kernel bugs +What follows is a recommended procedure for reporting bug in the Linux kernel. +Still, you are not obliged to use the suggested bug reporting format, it is +provided as a guide to the kind of information that can be useful to developers. + +In general, the kernel developers' preferred way of reporting bugs is email, +because it allows them to react quickly to the problems that are easy to fix. +Still, later on, if the reported problem turns out to be difficult, you may be +asked to open an entry in the kernel Bugzilla at http://bugzilla.kernel.org . +Usually, this requires you to do some more work than just sending an email +message with a bug report, but it often is necessary to collect all information +related to the reported bug in one place, so that it is easily accessible at +any time later. + +Email messages containing bug reports should generally be sent to the +Linux Kernel Mailing List (LKML) <[email protected]> and to the +mailing list dedicated to the affected subsystem. You may send a bug report to +three mailing lists simultaneously, if you think that it is necessry. +[However, if you send them to more than three lists at a time, people will +likely get angry with you.] The addresses of these lists can be found in the +MAINTAINERS file (in the "L:" fields). + +It also is a good idea to notify the maintainer of the affected subsystem and +the maintainer of the tree in which the bug is present by adding their email +addresses to the Cc list of the bug report message. The email addresses of +maintainers of the majority of kernel subsystems can also be found in the +MAINTAINERS file (in the "M:" fields), but you should not worry too much about +getting a wrong person. + +If you know which patch has caused the problem to appear, you should also add +the email address of its author to the Cc list of your bug report (this address +is usually present in the 'From:' field of the patch header). Additionally, +it is recommended to notify all of the people involved in the process of +merging the patch (you can find their addresses in the 'Signed-off-by:' and +'Acked-by:' or 'Reviewed-by:' fields of the patch header). This way you can +increase the probability that someone "in the know" will notice the report and +respond to it quickly. Apart from this, you should make it clear that your +message contains a bug report, for example by adding the word "BUG" in front +of the message's subject line. If the bug is a regression (ie. one of the +previous kernel versions worked correctly), please put the word "REGRESSION" in +there instead. + +Unfortunately, sometimes bug reports are not responded to even if they contain +all of the right email addresses etc. If that happens to your bug report, you +should first check if it has not been intercepted by a spam filter. This is +easy if you have sent the report to a mailing list, since in that case it only +is necessary to look into the list's archives to see if the message is there. +If it turns out that the report has reached the list and no one is responding to +it, the developers might have overlooked it or they may be too busy to take care +of it right now. In that case you should wait for some time (usually, a couple +of days) and send it once again (if you resend the report, you may add the word +"resend" to the message's subject to indicate that this is not the first time). +If that does not help and there still is no response, it is best to open a new +entry in the Bugzilla at http://bugzilla.kernel.org . + +As far as the contents of bug reports are concerned, you should generally avoid +putting irrelevant information into them. Of course, that may be difficult, +because you may not know which information is relevant in given particular case. +Still, you can always safely assume that if more information is needed, you will +be asked to provide it. + +First of all, you need to say what the bug is, which kernel version it is +present in and how to reproduce it. You also need to describe the symptoms and +include all of the corresponding kernel messages, if you can collect them. In +particular, if the failure includes an "Oops:" type message in your log or on +screen please read "Documentation/oops-tracing.txt" before posting your bug +report. This explains what you should do with the "Oops" information to make it +useful to the recipient. + +Generally, the following things are appreciated in a bug report: + +* One line summary of the reported problem +* Description of the problem +* Version of the kernel in which the problem appears +* The last known version of the kernel in which the problem does not appear (if + applicable) +* Architecture of the system on which the problem is observed (that may + include some more detailed hardware information if the problem seems to be + hardware-related) +* Steps to reproduce the problem +* Kernel messages related to the problem (if available) +* Concise description of software environment in which the problem appears (as + per the output of scripts/ver_linux) + +Additionally, if you know which patch has introduced the problem, the name of it +or the corresponding git commit name should be included in the report. [Please +read Documentation/BUG-HUNTING to learn how you can find the "guilty" patch.] + +The version of the kernel can be read from the output of scripts/ver_linux or +directly from /proc/version . Still, if you use git to download the kernel +sources, you can obtain more precise version information by running +'git describe' from within the root of the kernel source directory. + +After reporting a bug you may be provided with a patch to test. In that case +you ought to test it and report back to the developer who have sent it to you +whether or not it fixes the bug. If it does not fix the bug, you will likely +receive more patches to test. In any case, please be patient and work with the +developers until the issue is resolved. Thank you +
Re: [RFC][PATCH] Update REPORTING-BUGS (rev. 2)
On 26-11-2007 22:02, Rafael J. Wysocki wrote:
...
Quoted 5 lines
For completness, below is an updated version of the patch, modified to take some Adrian's comments into account.
Comments welcome.
...You mean any comments?...
Well, I've written something similar about something similar somewhere else, which you could remember, but here I'm even more "brutal", sorry! So, I think this text is wrong - at least in this place. I probably can repeat some of Adrian's comments, but IMHO the main thing is that this shouldn't deter any user, who got this, maybe momentary idea to report something. So, it definitely shouldn't be longer than maybe 5 sentences, with any "you should" if possible.
So, maybe it could start just like Adrian proposed:
Quoted 1 line
Quoted 1 line
Go to http://bugzilla.kernel.org/ and click on "Enter a new bug report".
plus e.g.:
"Alternatively you can write an e-mail to [email protected]
with '[BUG]' at the beginning of a subject (no need to subscribe).
If you feel like doing this with more details, read this document,
please: ..."
Regards,
Jarek P.
PS: Btw., did you notice how even main developers respect current (previous?) version of this doc while reporting bugs here?
Re: [RFC][PATCH] Update REPORTING-BUGS (rev. 2)
On Tue, Nov 27, 2007 at 09:50:38AM +0100, Jarek Poplawski wrote:
...
Quoted 1 line
with any "you should" if possible.
without any "you should" if possible.
Jarek P.