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.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
REPORTING-BUGS | 160 +++++++++++++++++++++++++++++++++++----------------------
1 file changed, 99 insertions(+), 61 deletions(-)
Index: linux-2.6/REPORTING-BUGS
===================================================================
--- linux-2.6.orig/REPORTING-BUGS
+++ linux-2.6/REPORTING-BUGS
@@ -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
+
On Sun, Nov 25, 2007 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
>...
> +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.
> +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.
>...
> +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.
> +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.
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.
>...
> +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.
> Thank you
> +
cu
Adrian
--
"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 Seed
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
> >...
> > +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.
> > +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.
> 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. ;-)
> >...
> > +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.
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.
> > +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.
>
> 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.
Well, who's "we" in that context? IOW, who's job exactly it's supposed to be?
> >...
> > +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.
> 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
On Sun, Nov 25, 2007 at 10:51:14PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > On Sun, Nov 25, 2007 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
> > >...
> > > +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.
What are you talking about?
The default text in the "Description:" field?
> > > +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.
>
> > 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
$
> > >...
> > > +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.
>
> 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.
> > > +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.
> >
> > 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.
>
> 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...
> > >...
> > > +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.
>
> > 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. ;-)
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.
> Greetings,
> Rafael
cu
Adrian
--
"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 Seed
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 10:51:14PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > On Sun, Nov 25, 2007 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
[--snip--]
> > >
> > > How should a newbie find the correct mailing list?
> >
> > Read MAINTAINERS? Ok, I should have said about that.
> >
> > > 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).
> > > >...
> > > > +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.
> >
> > 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.
OK
Who's supposed to be responsible for that?
[--snip--]
> > >
> > > 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...
>
> > > >...
> > > > +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.
> >
> > > 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. ;-)
>
> 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).
> 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
On Mon, Nov 26, 2007 at 12:00:28AM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
>...
> > 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.
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.
> Greetings,
> Rafael
cu
Adrian
--
"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 Seed
On Monday, 26 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 12:00:28AM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> >...
> > > 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.
>
> 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.
> 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.
> 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
On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
> On Monday, 26 of November 2007, Adrian Bunk wrote:
> > On Mon, Nov 26, 2007 at 12:00:28AM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > >...
> > > > 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.
> >
> > 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
> > 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.)
> 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?
> _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...
> > 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.
> Rafael
cu
Adrian
--
"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 Seed
On Monday, 26 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
> > On Monday, 26 of November 2007, Adrian Bunk wrote:
> > > On Mon, Nov 26, 2007 at 12:00:28AM +0100, Rafael J. Wysocki wrote:
> > > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > >...
> > > > > 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.
> > >
> > > 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
>
> > > 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.)
>
> > 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:
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.
> 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 ...
> > _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 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
Hi,
On Sunday, 25 of November 2007, Rafael J. Wysocki wrote:
> 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.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
REPORTING-BUGS | 160 +++++++++++++++++++++++++++++++++++----------------------
1 file changed, 99 insertions(+), 61 deletions(-)
Index: linux-2.6/REPORTING-BUGS
===================================================================
--- linux-2.6.orig/REPORTING-BUGS
+++ linux-2.6/REPORTING-BUGS
@@ -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
+
On Mon, Nov 26, 2007 at 01:51:37AM +0100, Rafael J. Wysocki wrote:
> On Monday, 26 of November 2007, Adrian Bunk wrote:
> > On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
>...
> > > 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:
>
> 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.
> > 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. :-(
> > > _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.
> > > > 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?
Take e.g. #3938 or #4039 as examples.
Both are quite different, but both should be fixable within < 1 month. [1]
> 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
--
"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 Seed
On Monday, 26 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 01:51:37AM +0100, Rafael J. Wysocki wrote:
> > On Monday, 26 of November 2007, Adrian Bunk wrote:
> > > On Mon, Nov 26, 2007 at 01:04:25AM +0100, Rafael J. Wysocki wrote:
> >...
> > > > 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:
> >
> > 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.
> > > 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. :-(
>
> > > > _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.
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.
> > > > > 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?
>
> Take e.g. #3938
Are you sure that this one hasn't been fixed? The reporter doesn't seem to be
responsive ...
> or #4039
Same here.
> as examples.
Greetings,
Rafael
On Mon, Nov 26, 2007 at 11:44:24PM +0100, Rafael J. Wysocki wrote:
> On Monday, 26 of November 2007, Adrian Bunk wrote:
> > On Mon, Nov 26, 2007 at 01:51:37AM +0100, Rafael J. Wysocki wrote:
> > > On Monday, 26 of November 2007, Adrian Bunk wrote:
>...
> > > > 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 ...
>
> > 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.
> > as examples.
>
> Greetings,
> Rafael
cu
Adrian
--
"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 Seed
On Tuesday, 27 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 11:44:24PM +0100, Rafael J. Wysocki wrote:
> > On Monday, 26 of November 2007, Adrian Bunk wrote:
> > > On Mon, Nov 26, 2007 at 01:51:37AM +0100, Rafael J. Wysocki wrote:
> > > > On Monday, 26 of November 2007, Adrian Bunk wrote:
> >...
> > > > > 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 ...
> >
> > > 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.
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
On 26-11-2007 22:02, Rafael J. Wysocki wrote:
...
>
> 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:
>> 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?
On Tue, Nov 27, 2007 at 09:50:38AM +0100, Jarek Poplawski wrote:
...
> with any "you should" if possible.
without any "you should" if possible.
Jarek P.