The first three mostly apply to Konqueror & rendering bugs:
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.
|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.|
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
It would be nice if you go through and comment on these test cases, you don't even need a bugzilla or techbase account.
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.
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.
(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 to 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.
The point of bugzilla is to keep track of what needs fixing in versions currently being worked on.
Once a bug is fixed in SVN trunk, it can be closed.
This won't necessarily make users happy, so be nice about closing old bugs. Here are some further guidelines:
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.
There was major code change between 3 & 4. Any kind of backport is probably undoable.
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.
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.
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.
Depends on what section: Perhaps you'd like to see previous examples?
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.
|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.
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".
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.