Bug Filing Policy - Revision history

MinhHaDuong: /* Less is more in a bug report (engineers are lazy) */ Change title to something sensible

2008-10-29T07:02:52Z

‎Less is more in a bug report (engineers are lazy): Change title to something sensible

Kempelen: Category: +Community

2008-09-15T21:38:45Z

Category: +Community

Coolcat at 11:06, 12 September 2008

2008-09-12T11:06:56Z

MinhHaDuong: /* Ideal workflow */ Link to mlai

2008-09-10T13:26:37Z

‎Ideal workflow: Link to mlai

Dolfje at 11:09, 1 September 2008

2008-09-01T11:09:23Z

Marko Knöbl: turning first heading into normal text

2008-08-29T11:10:17Z

turning first heading into normal text

Zecke at 01:47, 29 August 2008

2008-08-29T01:47:02Z

Zecke at 01:41, 29 August 2008

2008-08-29T01:41:06Z

Zecke at 01:36, 29 August 2008

2008-08-29T01:36:52Z

Zecke at 00:25, 29 August 2008

2008-08-29T00:25:11Z

@@ Line 3: / Line 3: @@
 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 engineers look for in a bug report ==
 * What is your issue (what do you do, how does it fail)?
 * How to reproduce it(what are the steps)?

← Older revision		Revision as of 21:38, 15 September 2008
Line 47:		Line 47:

	http://www.mail-archive.com/devel@lists.openmoko.org/msg01462.html		http://www.mail-archive.com/devel@lists.openmoko.org/msg01462.html
		+
	[[category:Software Test]]		[[category:Software Test]]
		+	[[Category:Community]]

← Older revision		Revision as of 11:06, 12 September 2008
Line 47:		Line 47:

	http://www.mail-archive.com/devel@lists.openmoko.org/msg01462.html		http://www.mail-archive.com/devel@lists.openmoko.org/msg01462.html
		+	[[category:Software Test]]

← Older revision		Revision as of 13:26, 10 September 2008
Line 43:		Line 43:
	* With testing packages available we can put the bug into in_testing		* With testing packages available we can put the bug into in_testing
	* Close once fixed, reopen once regressed.		* Close once fixed, reopen once regressed.
		+
		+	== See also ==
		+
		+	http://www.mail-archive.com/devel@lists.openmoko.org/msg01462.html

← Older revision		Revision as of 11:09, 1 September 2008
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) ==

← Older revision		Revision as of 11:10, 29 August 2008
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)

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

← Older revision		Revision as of 01:47, 29 August 2008
Line 35:		Line 35:
	* See the first point on less is more.		* 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".		* 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.

@@ Line 3: / Line 3: @@
 == 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)?
+* 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 asks for it.
+* 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 issues.
+* 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 file new bug reports.
+* 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 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.
+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
@@ Line 27: / Line 27: @@
 == Handling of kernel bugs ==
-* The installed version and the output of dmesg is most likely of interest
+* The installed version and the output of dmesg is most likely of interest, attach that
 == Creating a ticket ==

← Older revision		Revision as of 01:36, 29 August 2008
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".

← Older revision		Revision as of 00:25, 29 August 2008
Line 1:		Line 1:
−	= A guide to filing bug reports =	+	= A guide to filing bug reports (for users) =