ubuntu-bugcontrol team mailing list archive

["Dr. David Alan Gilbert" <dave@xxxxxxxxxxx>]

* Christopher Penalver (christopher.penalver@xxxxxxx) wrote:
> Ubuntu Bug Control / Ubuntu Kernel Team,
> 
> Hello everyone. I wanted to inquire about improving
> https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Reporting_Bugs_Upstream
> . What I have noticed in my triaging linux package bugs is that the high
> majority of original reporters who are steered to this article when
> asked to upstream their bug, do not follow the directions at all. In
> turn, their bugs are promptly ignored, and by kindness/busy'ness of the
> maintainer/submaintainer/community developers, not closed or flagged
> REJECTED INSUFFICIENT_DATA.

I don't think we should be steering people to report to bugzilla.kernel.org
at all.    For a large part if you report a bug in a distro packaged kernel
to upstream kernel you'll be sent away with a flea in your ear.
Even then, there is some question whether bugzilla.kernel.org is intended
to take user bug reports these days (e.g. see https://lkml.org/lkml/2012/5/13/121 )
I certainly don't think we should ever do it unless it's been pretty heavily
triaged to not be an ubuntu bug.

I also think it's a bad idea to ask end users to think about
providing the information needed; lots of people who report their machine
has oops'd or crashed won't have the technical skills to try the things
needed.  I wouldn't want either of:

  1) End users to think Ubuntu wouldn't take a bad kernel bug
seriously unless they can jump through all of these type of hoops.

  2) Kernel guys to get annoyed with Ubuntu for pointing our
users at them.

I mean after all, the most likely positive response from the kernel guys is
to ask for you to try a patch, and unless the reporter can rebuild
there own kernel, then I'm not sure there is much of a point.

Now, having said that, if someone wants to take it further and has
tried the latest daily build etc, and has the skills then your page
probably sets the right tone to make sure they don't do it without
providing the right info.

> What seems best is something to the following:
> 
> <START>
> 
> Thank you for following this. Firstly, please do not report
> your bug upstream unless you have followed the below mentioned
> format created by kernel.org developers. Failure to follow these
> directions exactly as shown below, may likely result in your bug
> being promptly ignored by the kernel maintainer or submaintainer
> who could fix your problem, or the report being be closed as
> [[https://bugzilla.kernel.org/page.cgi?id=faq.html|REJECTED
> INSUFFICIENT_DATA]].


> ||<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 termina
> l: <<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 quest
> ions 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 probably also needs something to check whether the kernel you're running is
tainted; and that if even vaguely possible you must try without any closed
source modules loaded.

Dave
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\ gro.gilbert @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/