Bug Filing Policy

From Openmoko

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
= A guide to filing bug reports (for users) =
+
== A guide to filing bug reports on software (for users from an engineer) ==
 +
 
 +
== Less is more in a bug report (engineers are lazy) ==
 +
* What is your issue (what do you do, how does it fail)?
 +
* How to reproduce (what are the steps)?
 +
* What are you using (opkg list_installed, feed config, image)?
 +
* In case of kernel bugs attach the output of dmesg or in case of Qtopia/GSM the output of logread.
 +
* If logs exist and the issue is confirmed do not attach your log unless when asks for it.
 +
* A "me too" without log messages is noise and makes engineers not look at the issues.
 +
* Having many bugs is not an issue, so this is no excuse to file new bug reports.
 +
 
 +
== Check for duplicates (but in doubt create a new ticket) ==
 +
Before filing a bug check if a bug describing your issue exists. If you don't find an exact match or not really sure file a new ticket. New tickets can be easily resolved as duplicate where comments to existing bugs with a different issue can not be removed. So a possible duplicate ticket is not too bad.
 +
 
 +
* If you know you have this issue and no one else confirmed, attach your logs and feel free to say me too
 +
* If you know you have this issue and it is confirmed, add yourself to CC or monitor the bug
 +
* If you are not sure if you have this issue. File a new bug and say you might have the original issue.
 +
 
 +
== If you have patches (what engineers love) ==
 +
* Attach the patch
 +
* Set HasPatch in the keywords
 +
* If no one reviews your patch within three work days you have the right to kick people on the mailinglist. You contribute, you deserve to get feedback on your patch!
 +
 
 +
== Handling GSM bugs (Qtopia) ==
 +
* If GSM registration is not working, or SMS notification, PIN dialog, or any other setup. Make sure the device does not suspend and attach the output of logread after waiting a minute or two after entering the PIN or logread is not showing any change for a while.
 +
* If calls, parsing of SMS, or such things do not work. Attach the output of logread after this has happened.
 +
 
 +
== Handling of kernel bugs ==
 +
* The installed version and the output of dmesg is most likely of interest
 +
 
 +
== Creating a ticket ==
 +
* Do not set a Category/Component unless the holy penguin told you it is the correct one.
 +
* At least have opkg list_installed attached to the bug report
 +
* Describe clearly what your issue is, if it makes sense attach a screenshot, don't be afraid to write more than five lines
 +
* See the first point on less is more.
 +
* If you did something like rm -rf / and now the PIN dialog does not come up because you have no userspace apps left then please tell us what you did and do not say "It does not ask for PIN anymore".

Revision as of 03:36, 29 August 2008

Contents

A guide to filing bug reports on software (for users from an engineer)

Less is more in a bug report (engineers are lazy)

  • What is your issue (what do you do, how does it fail)?
  • How to reproduce (what are the steps)?
  • What are you using (opkg list_installed, feed config, image)?
  • In case of kernel bugs attach the output of dmesg or in case of Qtopia/GSM the output of logread.
  • If logs exist and the issue is confirmed do not attach your log unless when asks for it.
  • A "me too" without log messages is noise and makes engineers not look at the issues.
  • Having many bugs is not an issue, so this is no excuse to file new bug reports.

Check for duplicates (but in doubt create a new ticket)

Before filing a bug check if a bug describing your issue exists. If you don't find an exact match or not really sure file a new ticket. New tickets can be easily resolved as duplicate where comments to existing bugs with a different issue can not be removed. So a possible duplicate ticket is not too bad.

  • If you know you have this issue and no one else confirmed, attach your logs and feel free to say me too
  • If you know you have this issue and it is confirmed, add yourself to CC or monitor the bug
  • If you are not sure if you have this issue. File a new bug and say you might have the original issue.

If you have patches (what engineers love)

  • Attach the patch
  • Set HasPatch in the keywords
  • If no one reviews your patch within three work days you have the right to kick people on the mailinglist. You contribute, you deserve to get feedback on your patch!

Handling GSM bugs (Qtopia)

  • If GSM registration is not working, or SMS notification, PIN dialog, or any other setup. Make sure the device does not suspend and attach the output of logread after waiting a minute or two after entering the PIN or logread is not showing any change for a while.
  • If calls, parsing of SMS, or such things do not work. Attach the output of logread after this has happened.

Handling of kernel bugs

  • The installed version and the output of dmesg is most likely of interest

Creating a ticket

  • Do not set a Category/Component unless the holy penguin told you it is the correct one.
  • At least have opkg list_installed attached to the bug report
  • Describe clearly what your issue is, if it makes sense attach a screenshot, don't be afraid to write more than five lines
  • See the first point on less is more.
  • If you did something like rm -rf / and now the PIN dialog does not come up because you have no userspace apps left then please tell us what you did and do not say "It does not ask for PIN anymore".
Personal tools

A guide to filing bug reports (for users)