ubuntu-bugcontrol team mailing list archive

["Christopher Penalver" <christopher.penalver@xxxxxxx>]

Ubuntu Kernel Team/Ubuntu Bug Control:

Hello everyone. After carefully considering Dr. David Alan Gilbert's advice:
https://lists.launchpad.net/ubuntu-bugcontrol/msg03762.html

my intended improvment has been further improved. In summary:
* The intensity of the wording is softened slightly.
* A preamble is included to educate Original Reporters on reporting USB bugs.
* Non-USB bugs steer Original Reporters to the mailinglists first before filing a report on bugzilla.kernel.org.
* This iteration does not include the transactionalization of oops-tracing.txt yet, as this will take considerably more time.

Here's the reiteration:

<START>

 * Please note that if you have a USB bug, the USB maintainer(s) do not want you to create a new upstream report. For more on this, please see this upstream report [[https://bugzilla.kernel.org/show_bug.cgi?id=42584#c5|comment]]. Instead, using the below mentioned format, they want you to send an E-Mail to linux-usb@xxxxxxxxxxxxxxx , and CC the launchpad bug via <BUGNUMBER>@bugs.launchpad.net , where <BUGNUMBER> is the number of your Launchpad bug report.  If you do open an upstream report, it will likely be closed as [[https://bugzilla.kernel.org/page.cgi?id=faq.html|RESOLVED INVALID]] with impunity. As well, this could potentially create friction between you and the upstream developers who fix USB bugs, which is not very [[www.ubuntu.com/project/about-ubuntu/conduct|Ubuntu]].

 * If your bug is not in USB, the first step in reporting your bug upstream is to find the maintainer of the driver for your bug from the [[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=MAINTAINERS|MAINTAINERS]] list. Then, using the below mentioned format, send an E-Mail to the maintainer E-Mail, and CC the launchpad bug via <BUGNUMBER>@bugs.launchpad.net , where <BUGNUMBER> is the number of your bug report. If after a while you do not receive a response from the maintainer, and it is not a USB bug, please follow the directions below.

 * If you contact upstream via E-Mail or file a new upstream report, please follow the below mentioned format created by kernel.org developers. Failure to follow these directions exactly as shown may likely result in your bug being promptly ignored by the kernel maintainer, submaintainer, or community developer(s) who could fix your problem, potentially creating friction between you and the upstream developers who fix USB bugs, which is not very [[www.ubuntu.com/project/about-ubuntu/conduct|Ubuntu]], or the report being be closed as [[https://bugzilla.kernel.org/page.cgi?id=faq.html|REJECTED INSUFFICIENT_DATA, or REJECTED INVALID]]. 

||<tablestyle="background-color: #eee"> <<BR>> [1.] One line summary of the problem: <<BR>> Paste the downstream bug title. <<BR>> <<BR>> [2.] Full description of the problem/report: <<BR>> Paste the Bug Description. <<BR>> <<BR>> [3.] Keywords (i.e., modules, networking, kernel): <<BR>> [4.] Kernel version (from /proc/version): <<BR>> [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) <<BR>> If you have a kernel oops, one may consult http://www.kernel.org/doc/Documentation/oops-tracing.txt . <<BR>> [6.] A small shell script or example program which triggers the problem (if possible) <<BR>> [7.] Environment <<BR>> lsb_release -rd <<BR>> <<BR>> [7.1.] Software (add the output of the ver_linux script here) <<BR>> For Ubuntu, this is found in the directory: <<BR>> /usr/src/linux-headers-<VERSION>/scripts <<BR>> <<BR>> where <VERSION> is the version of the kernel you are using, found in the directory /usr/src. You may run the script via a terminal: <<BR>> sh ver_linux <<BR>> <<BR>> [7.2.] Processor information (from /proc/cpuinfo): <<BR>> [7.3.] Module information (from /proc/modules): <<BR>> [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) <<BR>> [7.5.] PCI information ('lspci -vvv' as root) <<BR>> [7.6.] SCSI information (from /proc/scsi/scsi) <<BR>> [7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant): <<BR>> List the output of /proc. <<BR>> <<BR>> [X.] Other notes, patches, fixes, workarounds: <<BR>> Be 100% certain you have included all relevant comment information not included in the Bug Description and a kernel developer should review. They are very busy, and do not need to dive through downstream bug reports to find something that should have been provided when the bug was first filed. If you are unsure about anything asked for, or intend on not following this format, please do not file a report. Instead, continue to ask questions in Launchpad and of the Ubuntu community until all issues are cleared up. ||

Note the above format was taken directly from [[http://kernel.org/pub/linux/docs/lkml/reporting-bugs.html]].

It is often the case that once a bug with the above format is escalated upstream there is a quick resolution through the help and support of the mainline kernel community. Bug reports in Launchpad can also be set up to monitor bugs reported in other bug tracking systems. Once you have collected the above information, the following steps will help you report your bug upstream and monitor it in Launchpad.

1. Go to http://bugzilla.kernel.org

2. ...

<END>

What do you think?

--
Christopher M. Penalver
E-Mail: christopher.penalver@xxxxxxx
MCSE:Security, MCSA, MCDST, MCP, Security+, Network+, A+, NSSP

This E-Mail was sent via a laptop using Xubuntu, Linux for human beings.
www.xubuntu.org
http://www.launchpad.net/~penalvch
Acer Aspire 5750-9668 Xubuntu 12.04