Bug Filing Policy

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(turning first heading into normal text)
Line 1: Line 1:
 
A guide to filing bug reports on software (for users from an engineer)
 
A guide to filing bug reports on software (for users from an engineer)
 +
 +
You can report a bug/defect at https://docs.openmoko.org/trac/. Just create an account. After email validation of your account, you can log in. You will see a new button labeled "New Ticket".
  
 
== Less is more in a bug report (engineers are lazy) ==
 
== Less is more in a bug report (engineers are lazy) ==

Revision as of 12:09, 1 September 2008

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

You can report a bug/defect at https://docs.openmoko.org/trac/. Just create an account. After email validation of your account, you can log in. You will see a new button labeled "New Ticket".

Contents

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 it(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 asked for it.
  • A "me too" without log messages is noise and makes engineers not look at the issue.
  • Having many bugs is not an issue, so this is no excuse to not 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 are 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 to be preferred.

  • 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, attach that

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".

Ideal workflow

  • We gather information on the issue until we understand it
  • Engineers implement a fix (if fixable) and people can test through updated packages
  • With testing packages available we can put the bug into in_testing
  • Close once fixed, reopen once regressed.
Personal tools

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

You can report a bug/defect at https://docs.openmoko.org/trac/. Just create an account. After email validation of your account, you can log in. You will see a new button labeled "New Ticket".

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 it(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 asked for it.
  • A "me too" without log messages is noise and makes engineers not look at the issue.
  • Having many bugs is not an issue, so this is no excuse to not 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 are 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 to be preferred.

  • 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, attach that

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".

Ideal workflow

  • We gather information on the issue until we understand it
  • Engineers implement a fix (if fixable) and people can test through updated packages
  • With testing packages available we can put the bug into in_testing
  • Close once fixed, reopen once regressed.