Reporting

Differences between revisions 24 and 26 (spanning 2 versions)
⇤ ← Revision 24 as of 2010-03-19 01:48:50 →
Size: 12481
Editor: pool-74-107-129-37
Comment:
← Revision 26 as of 2010-04-12 22:43:00 → ⇥
Size: 9366
Editor: pool-74-107-129-37
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
A convenient way to report bugs against Ubuntu's Xorg is: We welcome reports of defects in Ubuntu that help us make Ubuntu a better product.

The official way to report defects against Ubuntu's Xorg is:
Line 9: Line 11:
The {{{ubuntu-bug}}} script will automatically include a lot of files and information we need for troubleshooting problems. A bot will analyze your bug and move it to the video driver or other package that is appropriate for your bug report. The {{{ubuntu-bug}}} script will automatically include a lot of files and information we need for troubleshooting problems. Also be sure to include:
Line 11: Line 13:
Be sure to give a detailed description of the problem, with steps to reproduce it if possible, otherwise the bug could be closed as ambiguous/too-little-detail.  * A '''detailed description''' of the defect you found.
 * Steps or conditions to reproduce or a measurement of the frequency of how often it occurs
 * If it is a regression, make sure to indicate the '''last working version'''
 * A '''photo''' of the screen (if it involves graphical corruption or weirdness)
 * For crashes: [[http://wiki.ubuntu.com/X/Backtracing|A full backtrace]]
Line 13: Line 19:
If you do not wish to use that script and wish to file a bug manually, see below for a list of files and data to include. Note that if you do not attach the necessary files, it will add considerable delay in getting a fix for your issue. Take time to analyze the problem and write a good report, and '''especially include a detailed description of the problem''', including steps to reproduce it. Defect reports which do not define the issue needing to be fixed are likely to be closed as ambiguous.

Keep in mind that the Launchpad bug tracker is a development tool, not for technical support - Ubuntu does have [[http://www.ubuntu.com/support|volunteer and paid technical support staff]] but none of them frequent the bug tracker. In particular, if you're using a released version of Ubuntu, you probably should start with the technical support channels.

Please be aware that a LOT of people file bug reports to Ubuntu, way more than we can respond to. We try to focus on the highest quality defect reports, so spending some time making a good report can help a lot.
Line 18: Line 28:
If you'd like to do some investigation beyond just reporting the bug, please see the page: Before reporting the defect you've found, take some time to analyze and isolate it:
Line 24: Line 34:
Your title should communicate two things: The symptom you're seeing,
and whatever is unique or unusual about your system. Otherwise, your
bug may not get proper attention.		 Your title should communicate two things: The symptom being seen, and whatever is unique or unusual about the system in question.
Line 29: Line 37:
||<style="background-color: #FF8080;"> '''BAD''':|| Crashes randomly ||
||<style="background-color: #FF8080;"> '''BAD''':|| Crazy screen issues on boot ||
||<style="background-color: #FF8080;"> '''BAD''':|| Multiple problems with CD today ||
||<style="background-color: #FF8080;"> '''BAD''':|| Not able to login or start X after updating ||
Line 39: Line 43:
||<style="background-color: #FF8080;"> '''BAD''':|| Crashes randomly ||
||<style="background-color: #FF8080;"> '''BAD''':|| Crazy screen issues on boot ||
||<style="background-color: #FF8080;"> '''BAD''':|| Multiple problems with CD today ||
||<style="background-color: #FF8080;"> '''BAD''':|| Not able to login or start X after updating ||
Line 40: Line 48:
== From Complaint to Change ==
Line 42: Line 49:
What we call "bug reports" actually covers a wide range in terms of quality: == One Defect, One Person Per Report ==
Line 44: Line 51:
 * ''Change Request''
 * ''Defect Report''
 * ''Support Request''
 * ''Complaint''		 In your defect report, '''focus on one specific issue'''. It is not uncommon to have several different unrelated bugs, but it makes it hard to track the issue to closure with them all in one report.
Line 49: Line 53:
''Change Requests'' are the meat and potatoes of a packager's job. It could be a request for adding a patch, updating to a new version of a package, changing the standard defaults, or so on. It is actionable, specific, and 100% known what to do.

''Defect Reports'' are high quality bug reports. They have documented steps to reproduce the issue, typically are confirmed by another tester, and while the cause of the problem may not be known, the issue is well characterized and it is clear what the next steps are to troubleshoot it.

''Support Requests'' have a problem statement and might indicate defects, but the reporter will need assistance in doing further debugging work before that can be determined for certain. For instance, standard troubleshooting processes need to be done, or files collected and analyzed.

''Complaints'' differ from support requests in that they generally do not have a clear problem statement.

Now, complaints can be upgraded into support requests, support requests into defect reports, and defect reports to change requests but each step requires effort. If we say this takes X, Y, and Z amounts of effort each, then you can see that fixing a complaint requires X + Y + Z effort total, compared with just Z for Defect Reports. Obviously it is most efficient for the developers to focus on Defect Reports first, because since there is a limited total amount of developer resources, more defect reports can be fixed in a given amount of time.

This is why it is important for you to file a good bug report. Good reports make the best use of developer energies, and that can mean less delay for getting a fix.		 Similarly, often several people will see the same symptom, but X failures tend to have very similar symptoms even though the underlying bugs are unrelated. So we will focus on only the original reporter's issue. '''Don't report 'me too' on someone else's defect report'''.
Line 64: Line 58:
||<tablestyle="width: 80%;" style="background-color: #FF8080;"> DON'T: || Assume "they must already know about this" and skip reporting ||
||<style="background-color: lightgreen;"> DO: || Look for existing bug reports that exactly matches your problem, and if not file a new bug ||		 ||<tablestyle="width: 80%;" style="background-color: #FF8080;"> DON'T: || Use the word "randomly" to describe the problem ||
||<style="background-color: lightgreen;"> DO: || Describe the defect in a scientific manner. "randomly" indicates you've not studied the bug long enough to define it properly.||
Line 70: Line 64:
||<style="background-color: #FF8080;"> DON'T: || Use the word "randomly" to describe the problem ||
||<style="background-color: lightgreen;"> DO: || Describe the bug in a scientific manner. "randomly" is sort of a weasel word that should suggest to you that you ought to do more analysis to characterize the problem properly. ||
||||||
||<style="background-color: #FF8080;"> DON'T: || Add "me too" responses to an existing bug, with no further information. ||
||<style="background-color: lightgreen;"> DO: || Make sure any comment you make on someone else's bug adds tangible value to the discussion. Add missing data (photos, logs) to add to an existing bug's "knowledge base" and to provide ample evidence that you indeed have the exact same issue. Or if you just wish to be notified, then Subscribe yourself to the bug. If in doubt, file a new bug, and reference the one you think might be a dupe, and let the experts decide. ||		 ||<style="background-color: #FF8080;"> DON'T: || Add "me too" responses to an existing defect report, with no further information. ||
||<style="background-color: lightgreen;"> DO: || If you must comment on someone else's report that you're seeing the problem as well, at least include evidence (in the form of logs, photos, etc.) that you have the same problem. Explain in enough detail that you add value to the discussion, not just spam everyone with a contentless 'me too'. ||
Line 80: Line 71:
||<style="background-color: lightgreen;"> DO: || 90% of the time you are seeing something abnormal that others aren't. Consider what is unique about your system, any recent changes made, and so on. || ||<style="background-color: lightgreen;"> DO: || 99% of the time you are seeing something abnormal that others aren't. Consider what is unique about your system, any recent changes made, and so on. ||
Line 88: Line 79:
||<style="background-color: #FF8080;"> DON'T: || Rant about the bug "driving away new users", threaten to "go back to windows or some other distro" unless the bug is fixed, or complain the bug is not getting enough attention. None of this helps get the bug fixed; it just makes people sad. ||
||<style="background-color: lightgreen;"> DO: || Follow the [[http://www.ubuntu.com/community/conduct|Ubuntu Code of Conduct]] and keep discussions civil, even if you're frustrated. There are thousands of bugs and just a handful of people to work on them, and we can't fix everything overnight. If you're not getting fast enough response on a bug, then in addition to improving the report, you can try reporting it upstream, make mention of the bug directly to developers via mailing lists or irc, or even undertaking troubleshooting and analysis procedures yourself. Half the work of solving a bug is reproducing it, so if you have the bug, you're already halfway to a solution! ;-) Many, many of Ubuntu's bugs are solved through the work of community members, who didn't know the underlying technology but were patient and diligent at asking questions and testing things out until they found a solution. ||		 ||<style="background-color: #FF8080;"> DON'T: || Rant about the bug "driving away new users", threaten to "go back to windows" unless the bug is fixed, or complain the bug is not getting enough attention. None of this helps get the bug fixed; it just makes people sad. ||
||<style="background-color: lightgreen;"> DO: || Follow the [[http://www.ubuntu.com/community/conduct|Ubuntu Code of Conduct]] and keep discussions civil, even if you're frustrated. There are millions of Ubuntu users, and thousands of bug reports and just a handful of people to work on fixes -- it simply is not humanly possible to give a personal reply to every bug report. If you're not getting fast enough response on a bug, then in addition to checking your analysis work and improving the defect report, you can try reporting it upstream, locate patches or workarounds to test and report your findings, or even try your hand at coding a fix yourself (if you know C coding). ||
Line 91: Line 82:

== What to Include in Bug Reports ==

|| '''Problem class:''' || '''Things to Include:''' ||
||<|3(^> '''General X bug''' || Description of problem ||
|| Paste in output of {{{lspci -nn | grep VGA}}} ||
|| Attach /var/log/Xorg.0.log ||
||<|7(^> '''Wrong resolutions, refresh rates, or monitor specs''' || Resolution, rate, or other parameter expected ||
|| Resolutions, rates, or other parameters actually obtained ||
|| /etc/X11/xorg.conf ||
|| /var/log/Xorg.0.log ||
|| Paste in output of {{{lspci -nn | grep VGA}}} ||
|| output of `sudo ddcprobe` ||
|| output of `xrandr --verbose` ||
||<|5(^> '''Wrong font dpi or size''' || Are you running GNOME, KDE, XFCE, or ...? ||
|| Affected (and unaffected) applications ||
|| /var/log/Xorg.0.log ||
|| output of `sudo ddcprobe` and `xdpyinfo` ||
|| Screenshot showing font differences ||
||<|8(^> '''X crash, lockup, freeze, exit, or doesn't start/shutdown''' || Detailed description of problem ||
|| Get a full backtrace ([[X/Backtracing]]) ||
|| List any versions you tried that did not have this issue ||
|| Steps to reproduce ||
|| How complete is the X failure? <<BR>> + Does ctrl+alt+f1 take you to a console? <<BR>> + Does ctrl+alt+backspace restart X? <<BR>> + Does mouse pointer still move? <<BR>> + Does the keyboard LED come on when hitting the CAPSLOCK key? <<BR>> + Can you ssh into the system from another computer? ||
|| /var/log/Xorg.0.log ||
|| /var/log/Xorg.0.log.old ||
|| Output of `dmesg` ||
||<|4(^> '''Keyboard, touchpad, and mouse issues''' || Description of the problem ||
|| /var/log/Xorg.0.log ||
|| output of `xprop -root` ||
|| output of `gconftool-2 -R /desktop/gnome/peripherals` ||
||<|4(^> '''Screen display corruption''' || Photo of the screen ||
|| Description of the problem ||
|| Does it also occur if DRI (3D) is disabled? Specify "Option 'NoDRI'" in your Device section. ||
|| /var/log/Xorg.0.log ||
||<|3(^> '''Bad video playback''' || /etc/X11/xorg.conf ||
|| /var/log/Xorg.0.log ||
|| output of `lspci -vvnn` ||
Line 156: Line 109:
Once your X bug is reported, it will be reviewed and triaged. The triager may mark it Incomplete and ask some questions or request additional information (if you're curious, or would like to participate in triaging, see [[X/Triaging]]). Once your X bug is reported, it will be reviewed and triaged. The triager may mark it Incomplete and ask some questions or request additional information (if you're curious, or would like to participate in triaging, see [[X/Triaging]]).  Due to the volume, automated scripts do the first level triaging to help sort out the high quality bug reports from the low.
Line 160: Line 113:
Once you've submitted your replies, a second round of triaging takes place to evaluate if the bug is a Duplicate of another bug or not an issue requiring a fix. If neither of those apply, the bug will be marked Triaged, which marks it ready for the research step. Once you've submitted your replies, a second round of triaging takes place to evaluate if the bug is a Duplicate of another defect report or not an issue requiring a fix at the distro level. If neither of those apply, the bug will be marked Triaged, which marks it ready for the next step.
Line 162: Line 115:
In the research step, the bug may be assigned to a developer or forwarded to an upstream bug tracker. If it is forwarded upstream, you should also subscribe to that bug report so you can answer questions or run tests for those developers. Once a report has made it to Triaged, the defect report may be assigned to a developer or forwarded to an upstream bug tracker. If it is forwarded upstream, you should also subscribe to that bug report so you can answer questions or run tests for the upstream developers.

We welcome reports of defects in Ubuntu that help us make Ubuntu a better product.

The official way to report defects against Ubuntu's Xorg is: 

  ubuntu-bug xorg

The ubuntu-bug script will automatically include a lot of files and information we need for troubleshooting problems. Also be sure to include:

  • A detailed description of the defect you found.

  • Steps or conditions to reproduce or a measurement of the frequency of how often it occurs

  • If it is a regression, make sure to indicate the last working version

  • A photo of the screen (if it involves graphical corruption or weirdness)

  • For crashes: A full backtrace

Take time to analyze the problem and write a good report, and especially include a detailed description of the problem, including steps to reproduce it. Defect reports which do not define the issue needing to be fixed are likely to be closed as ambiguous.

Keep in mind that the Launchpad bug tracker is a development tool, not for technical support - Ubuntu does have volunteer and paid technical support staff but none of them frequent the bug tracker. In particular, if you're using a released version of Ubuntu, you probably should start with the technical support channels.

Please be aware that a LOT of people file bug reports to Ubuntu, way more than we can respond to. We try to focus on the highest quality defect reports, so spending some time making a good report can help a lot.

Troubleshooting

Before reporting the defect you've found, take some time to analyze and isolate it:

X/Troubleshooting

Choosing a Good Title

Your title should communicate two things: The symptom being seen, and whatever is unique or unusual about the system in question.

Examples:

GOOD:

Screen briefly corrupts during boot with -nv (NVidia 6100)

GOOD:

[fglrx] atieventsd crashed with SIGSEGV in XextAddDisplay()

GOOD:

[Hardy Alpha-3] Alt-CD (only) selected wrong driver (Matrox / BenQ FP91+)

GOOD:

[Gutsy] Periodic crashes w/ high CPU on Dell Latitude D505 (-intel 855GM)

GOOD:

[Dapper,Edgy] Wrong default refresh rates on 16:10 LCD panels

GOOD:

After update to -intel 2.0-0ubuntu3, X fails with 'Invalid mode' error

BAD:

Crashes randomly

BAD:

Crazy screen issues on boot

BAD:

Multiple problems with CD today

BAD:

Not able to login or start X after updating

One Defect, One Person Per Report

In your defect report, focus on one specific issue. It is not uncommon to have several different unrelated bugs, but it makes it hard to track the issue to closure with them all in one report.

Similarly, often several people will see the same symptom, but X failures tend to have very similar symptoms even though the underlying bugs are unrelated. So we will focus on only the original reporter's issue. Don't report 'me too' on someone else's defect report.

Do's and Don't's

DON'T:

Use the word "randomly" to describe the problem

DO:

Describe the defect in a scientific manner. "randomly" indicates you've not studied the bug long enough to define it properly.

DON'T:

Assume a "similar" bug is exactly what you're seeing

DO:

File a new bug, but mention the ID's of all bugs that sound similar. Someone can easily dupe them together later.

DON'T:

Add "me too" responses to an existing defect report, with no further information.

DO:

If you must comment on someone else's report that you're seeing the problem as well, at least include evidence (in the form of logs, photos, etc.) that you have the same problem. Explain in enough detail that you add value to the discussion, not just spam everyone with a contentless 'me too'.

DON'T:

Post bugs with only a brief description of the problem, or none at all

DO:

Post steps to reproduce, relevant logs, config files, and data (see table below) For Xorg issues, ALWAYS ATTACH YOUR /var/log/Xorg.0.log

DON'T:

Assume "everyone" is seeing this same bug

DO:

99% of the time you are seeing something abnormal that others aren't. Consider what is unique about your system, any recent changes made, and so on.

DON'T:

Assume others will "just know" how the bug occurs

DO:

Itemize the exact steps that result in the issue. Can you reproduce it at will?

DON'T:

Fire and forget. Abandoned bugs rarely get fixed.

DO:

Follow up on your bug from time to time, even if it seems ignored. Report if the issue goes away or remains when new Ubuntu's come out.

DON'T:

Rant about the bug "driving away new users", threaten to "go back to windows" unless the bug is fixed, or complain the bug is not getting enough attention. None of this helps get the bug fixed; it just makes people sad.

DO:

Follow the Ubuntu Code of Conduct and keep discussions civil, even if you're frustrated. There are millions of Ubuntu users, and thousands of bug reports and just a handful of people to work on fixes -- it simply is not humanly possible to give a personal reply to every bug report. If you're not getting fast enough response on a bug, then in addition to checking your analysis work and improving the defect report, you can try reporting it upstream, locate patches or workarounds to test and report your findings, or even try your hand at coding a fix yourself (if you know C coding).

Reporting Bugs from a Different Machine

Apport does a good job of collecting information on certain kinds of bugs. By default, it tries to launch your web browser to complete the bug filing. But sometimes you can't do this. Maybe X is utterly broken, or the buggy machine lacks a network connection, or some other problem.

You can make apport capture bug data manually like this: 

   apport-bug --save /tmp/foo.apport

Then copy that foo.apport file to the machine you want to file the bug from (using scp, rsync, a usb drive, or whatever), and then file it like this: 

  apport-bug ~/foo.apport

For the situation where apport automatically captured a crash dump from a crash or X lockup, but you can't file it from the sick machine, you will find the file in your /var/crash directory on the sick machine. Copy that over to another machine and file it from there, like above: 

  apport-bug /path/to/file.crash

What Next?

Once your X bug is reported, it will be reviewed and triaged. The triager may mark it Incomplete and ask some questions or request additional information (if you're curious, or would like to participate in triaging, see X/Triaging). Due to the volume, automated scripts do the first level triaging to help sort out the high quality bug reports from the low.

If there is no reply from you within a month or two, the bug report may be closed as out of date / invalid (otherwise the tracker fills up with inactive bugs and gets confusing). You should feel free to reopen it once you have the needed information.

Once you've submitted your replies, a second round of triaging takes place to evaluate if the bug is a Duplicate of another defect report or not an issue requiring a fix at the distro level. If neither of those apply, the bug will be marked Triaged, which marks it ready for the next step.

Once a report has made it to Triaged, the defect report may be assigned to a developer or forwarded to an upstream bug tracker. If it is forwarded upstream, you should also subscribe to that bug report so you can answer questions or run tests for the upstream developers.

Once a fix is found either in Ubuntu or upstream, the Ubuntu developers will take the fix and package it for Ubuntu. They may ask for people to test and verify the fix before uploading it.

X/Reporting (last edited 2016-01-10 21:36:02 by penalvch)