Contribute/Bugsquad/How to triage bugs - Revision history

DarioAndres: /* how many open bugs are against KDE as a whole? */

2009-10-31T13:50:56Z

‎how many open bugs are against KDE as a whole?

DarioAndres: /* What if it doesn't work in 3.5.x but it's fixed in 4? */

2009-10-31T13:49:48Z

‎What if it doesn't work in 3.5.x but it's fixed in 4?

DarioAndres: /* Special Instructions and Version fields */

2009-10-31T13:38:18Z

‎Special Instructions and Version fields

DarioAndres: /* To join in a BugDay OR to learn on your own */

2009-10-31T13:35:44Z

‎To join in a BugDay OR to learn on your own

Blauzahl: /* If I can still replicate a bug */ add triaged keyword

2008-09-25T00:29:32Z

‎If I can still replicate a bug: add triaged keyword

Blauzahl: /* Special Instructions and Version fields */ add kmail

2008-09-25T00:24:29Z

‎Special Instructions and Version fields: add kmail

Blauzahl: add section on version fields & special instructions

2008-09-25T00:14:12Z

add section on version fields & special instructions

Blauzahl: /Contribute/Bugsquad/How to triage bugs moved to Contribute/Bugsquad/How to triage bugs: er, wrong spot

2008-08-14T07:45:34Z

/Contribute/Bugsquad/How to triage bugs moved to Contribute/Bugsquad/How to triage bugs: er, wrong spot

Blauzahl: User:Blauzahl/How to triage bugs moved to /Contribute/Bugsquad/How to triage bugs: can't believe this was still in my userspace; it is basic documentation for us at this point

2008-08-14T07:37:42Z

User:Blauzahl/How to triage bugs moved to /Contribute/Bugsquad/How to triage bugs: can't believe this was still in my userspace; it is basic documentation for us at this point

Blauzahl: /* What if it doesn't work in 3.5.x but it's fixed in 4? */ add fixed in trunk warning box: most basic rule here on when to close :P

2008-08-14T07:31:20Z

‎What if it doesn't work in 3.5.x but it's fixed in 4?: add fixed in trunk warning box: most basic rule here on when to close :P

@@ Line 138: / Line 138: @@
 We want to keep it all on one page, because on the 2nd and 3rd pass, we tend to move things around a LOT from section to section as stuff changes.
-=how many open bugs are against KDE as a whole?=
+=How many open bugs are against KDE as a whole?=
 A ton. You can check at http://bugs.kde.org/weekly-bug-summary.cgi
 You can also click through to your favorite application and see its components' bugs. They will be sorted by severity here, so this is one way to go look at a list of crashes or wishlists. If you look at the past, you will find that ever since BugSquad has started, we have been making KDE "green".

@@ Line 82: / Line 82: @@
 They have requested we update their version fields.
-=What if it doesn't work in 3.5.x but it's fixed in 4?=
+=What if it does not work in 3.5.x but it is fixed in 4.x?=
-.5.x is not in active development at this time. Technically speaking, it's seven+ releases out of date. True, 4.1.x doesn't have all the functionality of 3 yet, but 3.5.x is past string freeze, feature freeze, etc. Keep that in mind as you go through old reports. You can use this to justify closing items fixed in trunk, while being nice to reporters who say they can't upgrade.
+'''KDE 3.5.x is not in active development at this time'''. Technically speaking, it's fourteen+ releases out of date. True, 4.3.x may not have all the functionality of KDE3 yet, but 3.5.x is past string freeze, feature freeze, etc. Keep that in mind as you go through old reports. ''You can use this to justify closing items fixed in trunk, while being nice to reporters who say they can't upgrade.''
-(Bugzilla actually has states (resolved -> verified -> closed) to keep track of code shipping, etc., but it's just a waste of time for us, so we don't use it that way.)
+{{note|Bugzilla actually has states (RESOLVED -> VERIFIED -> CLOSED) to keep track of code shipping, etc., ''but it's just a waste of time for us, so we don't use it that way.''}}
-Normally bug reports are fixed in the current development version (trunk), and "safe" bugfixes are backported to the current stable version (4.0 branch). Older versions just get security fixes. If something got messed up only on the stable branch, it gets fixed there.
+Normally bug reports are fixed in the current development version (trunk), and "safe" bugfixes are backported to the current stable version (4.3 branch, or, trunk - 1). Older versions just get security fixes. If something got messed up only on the stable branch, it gets fixed there.
 The point of bugzilla is to keep track of what needs fixing in versions currently being worked on.
@@ Line 94: / Line 94: @@
 The rule:
-<b>Once a bug is fixed in SVN trunk, it can be closed.</b>
+'''''Once a bug is fixed in SVN trunk, it can be closed.'''''
-−
-Shall I say it again? This is true for 4.1 vs. SVN trunk too!
-{{Warning| If a bug is fixed in SVN trunk, it can be closed. Even if it still exists in 4.1.x!}}
 This won't necessarily make users happy, so be nice about closing old bugs.
 Here are some further guidelines:
@@ Line 106: / Line 105: @@
 Crashes: If it happens on cnn.com or some such important site, it might get backported, otherwise, they're not going to be touched. Ask channel how important they think it is, and then go bug a developer to backport.
-If konqueror crashes when restoring session, please zip the $KDEHOME/share/apps/konqueror/autosaved directory and attach it to the bug report. This way the developers will be able to restore the problematic konqueror session exactly as you do, and it will be easier to fix the problem.
+* If konqueror crashes when restoring session, please zip the $KDEHOME/share/apps/konqueror/autosaved directory and attach it to the bug report. This way the developers will be able to restore the problematic konqueror session exactly as you do, and it will be easier to fix the problem.
 ===Konqueror/Dolphin===
@@ Line 113: / Line 112: @@
 ===KOffice bugs===
 SKIP these bugs
-There is ongoing major code change. They won't change 1.6 bugs, but 2.0 is still alpha. The developers want to keep their bugs open to check for regressions later on.
+There is ongoing major code change. They won't change 1.6 bugs, but 2.0+ is still under heavy development. The developers want to keep their bugs open to check for regressions later on.
-==But KDE4 isn't ready!==
+=="But KDE4 isn't ready!"==
-If you see someone saying their bug shouldn't be closed until everyone (read: that person) could give up kde3, try to come up with something nice to say, but really what they think is irrelevant. This is a case where we can take the heat for developers. We don't want them to have to deal with this stuff.
+If you see someone saying their bug shouldn't be closed until everyone (read: that person) could give up KDE3, try to come up with something nice to say, but really what they think is irrelevant. This is a case where we can take the heat for developers. We don't want them to have to deal with this stuff.
 =Put all bugs you look at on the wiki!!!=

@@ Line 74: / Line 74: @@
 =Special Instructions and Version fields=
-In general, you <b>never</b> change the version field, unless it is to remove "unspecified" and replace it with the version the bug was reported against.
+In general, you '''never''' change the version field, unless it is to remove "unspecified" and replace it with the version the bug was reported against.
-Do not "update" <i>Version:</i>, use comments to write what version you are testing with. As always, when commenting, say what distro/version source build you are using.
+'''Do not "update" <i>Version:</i>''', use comments to write what version you are testing with. As always, when commenting, say what distro/version source build you are using.
 There are some components which are an exception or which have other special instructions:

@@ Line 2: / Line 2: @@
 (You can do this anytime, picking a day just helps us focus. It's how we do our basic training.)
-* Get a bugzilla (bz) account.
+* Get a Bugzilla (bz) account [https://bugs.kde.org/createaccount.cgi]
-* Get a techbase account and '''set the preferences to "edit by section"'''. This is to prevent edit conflicts.
+* Get a TechBase account [http://techbase.kde.org/index.php?title=Special:UserLogin&type=signup] and '''set the preferences to "edit by section"''' [http://techbase.kde.org/Special:Preferences]. This is to prevent edit conflicts.
-* Join #kde-bugs.
+* Join #kde-bugs on FreeNode using your preferred IRC client ([http://konversation.kde.org/ Konversation], [http://quassel-irc.org/ Quassel]) or using the [http://webchat.freenode.net/ FreeNode WebChat]
 * Go to the current BugDay page in the url of the #kde-bugs topic. Or, if you are doing this on your own, go to the "Ongoing Konqueror Triage" page.
@@ Line 15: / Line 15: @@
 * Always comment on both bugzilla and the wiki:
 '''Also, if you are new, this is where we will keep track of how you are doing.'''
-*** New People: After you have done a bugset or two, find one of the other active people on channel (or ping grundleborg or blauzahl) and ask them to look over your bugs. You can ping and leave, we log. :)
 * Policy decision? --> Escalate it to developers.
@@ Line 26: / Line 26: @@
 * Unsure of anything? Ask!
-* Here's what you should look for:
 =See if the bug still exists=

@@ Line 68: / Line 68: @@
 =If I can still replicate a bug=
-See if it has a testcase, see if you can write one, put it on the wiki. Add a note saying the bug is still present and again, don't forget to give what version you're using.
+See if it has a testcase, see if you can write one, put it on the wiki. Add a note saying the bug is still present and again, don't forget to give what version you're using: distro/source (ie svn revision number)/snapshot.
 =Special Instructions and Version fields=

← Older revision		Revision as of 00:24, 25 September 2008
Line 71:		Line 71:

	=Special Instructions and Version fields=		=Special Instructions and Version fields=
		+	In general, you <b>never</b> change the version field, unless it is to remove "unspecified" and replace it with the version the bug was reported against.
		+	Do not "update" <i>Version:</i>, use comments to write what version you are testing with. As always, when commenting, say what distro/version source build you are using.
		+
		+	There are some components which are an exception or which have other special instructions:
		+
		+	==KMail==
		+	They have requested we update their version fields.

	=What if it doesn't work in 3.5.x but it's fixed in 4?=		=What if it doesn't work in 3.5.x but it's fixed in 4?=

← Older revision		Revision as of 07:31, 14 August 2008
Line 83:		Line 83:

	<b>Once a bug is fixed in SVN trunk, it can be closed.</b>		<b>Once a bug is fixed in SVN trunk, it can be closed.</b>
		+
		+	Shall I say it again? This is true for 4.1 vs. SVN trunk too!
		+	{{Warning\| If a bug is fixed in SVN trunk, it can be closed. Even if it still exists in 4.1.x!}}

	This won't necessarily make users happy, so be nice about closing old bugs.		This won't necessarily make users happy, so be nice about closing old bugs.