Difference between revisions of "Contribute/Bugsquad/How to triage bugs"

Jump to: navigation, search
(See if the bug still exists)
(how many open bugs are against KDE as a whole?)
 
(16 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
=To join in a BugDay OR to learn on your own=
 +
(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 [https://bugs.kde.org/createaccount.cgi]
 +
 +
* 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 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.
 +
 +
* "Sign in" (so we know what version you were testing with and that you were here)
 +
 +
* "Check out"/take a month of bugs, and work through them.
 +
 +
* Always comment on both bugzilla and the wiki:
 +
** Always comment on bugzilla, since that's the main way of tracking things, and what devs will pull up first, remember to add what version you tested with!
 +
** The wiki is what we use to sort what we've done, and to make sure people are doing the right thing. It is also where we discuss what we should do with bugs.
 +
 +
'''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, blauzahl or Dario_Andres) and ask them to look over your bugs. You can ping and leave, we log. :)
 +
 +
* Policy decision? --> Escalate it to developers.
 +
 +
* Unsure of anything? Ask!
 +
 +
 +
Here's what you should look for:
 +
 
=See if the bug still exists=
 
=See if the bug still exists=
  
 
The first three mostly apply to Konqueror & rendering bugs:
 
The first three mostly apply to Konqueror & rendering bugs:
  
* If there isn't a testcase, see if you can make one. That can be time consuming. If there is one, it should be in the bugzilla subject line as [testcase] or something.  
+
* If there isn't a testcase, see if you can make one. That can be time consuming. If there is one, it should be in the bugzilla subject line as [testcase].  
  
 
If it has a testcase, toss it into the "testcase section" of the wiki. <b>If it is a fixed bug, put it under the "fixed" section, AND mention that it has a testcase.</b> This way all the testcases can be added to the test regression suite.
 
If it has a testcase, toss it into the "testcase section" of the wiki. <b>If it is a fixed bug, put it under the "fixed" section, AND mention that it has a testcase.</b> This way all the testcases can be added to the test regression suite.
  
* On "site-issue" bugs, it's entirely likely that it's a 6 year old site which has long vanished so read the comments, because there might be a useful testcase or something describing what was the problem in there. If it looks like there's enough to give a developer something to go on, put it under the "needs attention from dev" section.
+
If you can't make a testcase, note "testcase needed" in the wiki.
 +
 
 +
* On "site-issue" bugs, it could be a 6-year-old site which has vanished. So read the comments, because there might be a useful testcase, or something describing what was the problem. If it looks like there's enough to give a developer something to go on, put it under the "needs attention from developer" section.
 +
 
 +
Also, try http://archive.org and see if you can pull up the site from around that time. Paste that link in the report, or better yet, make a testcase and put that in.
  
 
* If it has little information, and the site doesn't exist ---> INVALID *g*
 
* If it has little information, and the site doesn't exist ---> INVALID *g*
  
* If you can't change bug information yet, then just write your comment on the bug. Always include your version/revision number and distro/trunk/branch, and then write it on the wiki too. Mention that you can't change it yet, and someone will go through and double check stuff and mark what should be marked for you. Don't worry, you'll have bugzilla permissions pretty quickly.  
+
* If you can't change bug information yet, then just write your comment on the bug. Always include your version/revision number and distro/trunk/branch (you already wrote it on the wiki when you "signed in", right?). Mention on the wiki that you can't change it yet ("no perms", etc.), and someone will go through with you later, and double check stuff and mark things. Don't worry, you'll have bugzilla permissions pretty quickly.  
  
* If you aren't sure about something, get a second opinion, and mention who seconded on the wiki, especially if it was a dev. (saves us work)
+
* If you aren't sure about something, get a second opinion, and mention who seconded on the wiki, especially if it was a developer. (saves us work)
  
 
* If it works for us, then we close the bug with the chipper WORKSFORME.
 
* If it works for us, then we close the bug with the chipper WORKSFORME.
  
* If you know what piece of code fixed it (usually we won't, but a dev would), then you close with FIXED.
+
* If you know what piece of code fixed it (usually we won't, but a developer  would), then you close with FIXED.
  
* The nice way of closing bugs that don't have enough information and you think are likely to be invalid at this point is REMIND. And add a note saying "if this is still a problem, please reopen with more information."  
+
* The nice way of closing bugs that don't have enough information and you think are likely to be invalid at this point is REMIND. And add a note saying "'''if this is still a problem in a current version, please reopen with more information'''."  
  
{{tip| Old konqueror bugs aren't likely to have duplicates. Always get a second opinion, traditionally dups are the highest false positives, and we do not want to close valid, real bugs. In old konq bugs, we've found about 1% to be dups. (This isn't the case with incoming bugs.) So don't worry about finding dups if you are new.}}
+
(Or you can close with INVALID or WONTFIX, depending on what it is. Different programs/developers have different styles, i.e. REMIND vs. WONTFIX/INVALID. If you find yourself triaging for one package, you might want to find out the maintainer's style and follow that.)
 +
 
 +
{{tip| Old Konqueror bugs aren't likely to have duplicates. Always get a second opinion on those, traditionally duplicates are the highest false positives in BugDays, and we do NOT want to close valid, real bugs. In old Konqueror bugs, we've found about 1% duplicates. (This isn't the case with incoming bugs.) So don't worry about finding duplicates if you are new.}}
  
 
===Flash===
 
===Flash===
All the incoming flash bugs are probably dups. :P
+
Many of the incoming flash bugs are duplicates.
They are most useful if they are reproducible and have good instructions on how to reproduce. Also the reporter should give: flash version, kde version, 32/64bit. I'm told the backtraces don't matter as much as the reproducibility.
+
They are most useful if they are reproducible and have good instructions on how to reproduce them, or a URL. Also the reporter should give: flash version, kde version, 32/64bit. The backtraces will be incomplete inside of the flash functions: there are no debug symbols for it (closed source). Backtraces are still useful if flash is causing a crash though, because it helps us figure out how to work around it or tell if they have something misconfigured.
  
 
See the flash wikipage:
 
See the flash wikipage:
Line 33: Line 69:
  
 
=If I can still replicate a bug=
 
=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.
  
=What if it doesn't work in 3.5.x but it's fixed in 4?=
+
Add the "triaged" keyword in bugzilla.
  
3.5.x is not in active development at this time. Technically speaking, it's six releases out of date, as 3.5.9, 4.0.0, 4.0.1, 4.0.2, 4.0.3 and 4.0.4 have all been released since then. True, 4 doesn't have all the functionality of 3 yet, but it is past string freeze, feature freeze, etc. Keep that in mind as you go through old reports, as you can use it to close them.
+
=Special Instructions and Version fields=
 +
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.
  
(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.)
+
There are some components which are an exception or which have other special instructions:
  
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.
+
==KMail==
 +
They have requested we update their version fields.
 +
 
 +
=What if it does not work in 3.5.x but it is fixed in 4.x?=
 +
 
 +
'''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.''
 +
 
 +
{{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.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.
 
The point of bugzilla is to keep track of what needs fixing in versions currently being worked on.
Line 47: Line 94:
 
The rule:
 
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.3 vs. SVN trunk too!
 +
{{Warning| If a bug is fixed in SVN trunk, it can be closed. Even if it still exists in 4.3.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.  
 
Here are some further guidelines:
 
Here are some further guidelines:
Line 54: Line 103:
 
===Konqueror/KHTML===  
 
===Konqueror/KHTML===  
 
They are not actively developing 3.5.x
 
They are not actively developing 3.5.x
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.
+
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.
  
 
===Konqueror/Dolphin===  
 
===Konqueror/Dolphin===  
Line 61: Line 112:
 
===KOffice bugs===  
 
===KOffice bugs===  
 
SKIP these 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!!!=
 
=Put all bugs you look at on the wiki!!!=
Line 87: 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.
 
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
 
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".
 
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".

Latest revision as of 14:50, 31 October 2009

Contents

[edit] To join in a BugDay OR to learn on your own

(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 [1]
  • Get a TechBase account [2] and set the preferences to "edit by section" [3]. This is to prevent edit conflicts.
  • 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.
  • "Sign in" (so we know what version you were testing with and that you were here)
  • "Check out"/take a month of bugs, and work through them.
  • Always comment on both bugzilla and the wiki:
    • Always comment on bugzilla, since that's the main way of tracking things, and what devs will pull up first, remember to add what version you tested with!
    • The wiki is what we use to sort what we've done, and to make sure people are doing the right thing. It is also where we discuss what we should do with bugs.

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, blauzahl or Dario_Andres) and ask them to look over your bugs. You can ping and leave, we log. :)
  • Policy decision? --> Escalate it to developers.
  • Unsure of anything? Ask!


Here's what you should look for:

[edit] See if the bug still exists

The first three mostly apply to Konqueror & rendering bugs:

  • If there isn't a testcase, see if you can make one. That can be time consuming. If there is one, it should be in the bugzilla subject line as [testcase].

If it has a testcase, toss it into the "testcase section" of the wiki. If it is a fixed bug, put it under the "fixed" section, AND mention that it has a testcase. This way all the testcases can be added to the test regression suite.

If you can't make a testcase, note "testcase needed" in the wiki.

  • On "site-issue" bugs, it could be a 6-year-old site which has vanished. So read the comments, because there might be a useful testcase, or something describing what was the problem. If it looks like there's enough to give a developer something to go on, put it under the "needs attention from developer" section.

Also, try http://archive.org and see if you can pull up the site from around that time. Paste that link in the report, or better yet, make a testcase and put that in.

  • If it has little information, and the site doesn't exist ---> INVALID *g*
  • If you can't change bug information yet, then just write your comment on the bug. Always include your version/revision number and distro/trunk/branch (you already wrote it on the wiki when you "signed in", right?). Mention on the wiki that you can't change it yet ("no perms", etc.), and someone will go through with you later, and double check stuff and mark things. Don't worry, you'll have bugzilla permissions pretty quickly.
  • If you aren't sure about something, get a second opinion, and mention who seconded on the wiki, especially if it was a developer. (saves us work)
  • If it works for us, then we close the bug with the chipper WORKSFORME.
  • If you know what piece of code fixed it (usually we won't, but a developer would), then you close with FIXED.
  • The nice way of closing bugs that don't have enough information and you think are likely to be invalid at this point is REMIND. And add a note saying "if this is still a problem in a current version, please reopen with more information."

(Or you can close with INVALID or WONTFIX, depending on what it is. Different programs/developers have different styles, i.e. REMIND vs. WONTFIX/INVALID. If you find yourself triaging for one package, you might want to find out the maintainer's style and follow that.)

Ktip.png
 
Tip
Old Konqueror bugs aren't likely to have duplicates. Always get a second opinion on those, traditionally duplicates are the highest false positives in BugDays, and we do NOT want to close valid, real bugs. In old Konqueror bugs, we've found about 1% duplicates. (This isn't the case with incoming bugs.) So don't worry about finding duplicates if you are new.


[edit] Flash

Many of the incoming flash bugs are duplicates. They are most useful if they are reproducible and have good instructions on how to reproduce them, or a URL. Also the reporter should give: flash version, kde version, 32/64bit. The backtraces will be incomplete inside of the flash functions: there are no debug symbols for it (closed source). Backtraces are still useful if flash is causing a crash though, because it helps us figure out how to work around it or tell if they have something misconfigured.

See the flash wikipage: http://techbase.kde.org/index.php?title=Contribute/Bugsquad/BugDays/flashplugin

It would be nice if you go through and comment on these test cases, you don't even need a bugzilla or techbase account.

[edit] 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: distro/source (ie svn revision number)/snapshot.

Add the "triaged" keyword in bugzilla.

[edit] Special Instructions and Version fields

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" Version:, 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:

[edit] KMail

They have requested we update their version fields.

[edit] What if it does not work in 3.5.x but it is fixed in 4.x?

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.

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

The rule:

Once a bug is fixed in SVN trunk, it can be closed.

Shall I say it again? This is true for 4.3 vs. SVN trunk too!

noframe
 
Warning
If a bug is fixed in SVN trunk, it can be closed. Even if it still exists in 4.3.x!

This won't necessarily make users happy, so be nice about closing old bugs. Here are some further guidelines:

[edit] Konqueror/KHTML

They are not actively developing 3.5.x 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.

[edit] Konqueror/Dolphin

There was major code change between 3 & 4. Any kind of backport is probably undoable.

[edit] KOffice bugs

SKIP these bugs 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.

[edit] "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.

[edit] Put all bugs you look at on the wiki!!!

It gives us an easy way to go through and double check what people have done, especially useful for those who don't have bugzilla perms.

But you also have to mark things on bugzilla, that's where developers will keep track of things. We use the wiki to coordinate our own efforts.

[edit] Where on the wiki do I edit?

Depends on what section: Perhaps you'd like to see previous examples?

http://techbase.kde.org/index.php?title=Contribute/Bugsquad/BugDays/

You'll see how it's ended up looking now that we've gone through it a few times We're not putting any new bugs on there.

Ktip.png
 
Tip
If you just got a techbase wiki account, set the preferences to let you edit by section.


We also use the wiki to some extent to coordinate comments, at least to document what we said in irc.

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.

[edit] 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".

[edit] Thanks

Thanks to nixeagle, who let me start this page from an unedited irc log. Also thanks to others who probably don't want to be mentioned.


This page was last modified on 31 October 2009, at 14:50. This page has been accessed 9,615 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal