Revision as of 22:27, 13 May 2008

(from a barely edited irc log, with nixeagle's permission)

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] or something.

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.

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

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

 

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. Our first time, we ended up with only 3 duplicates, out of 355 bugs. This probably won't apply with fresh, incoming bugs. But don't worry about dups if you are new.

Flash

All the incoming flash bugs are probably dups. :P 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.

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

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 agian, and don't forget to give what version you're using.

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.

Where on the wiki do I edit?

Depends on what section If you go up a level or so from the link in the topic, you'll find the one from the last time we did this

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

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.

 

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.

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