|
|
| (15 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| == Getting Started ==
| | #REDIRECT [[Guidelines and HOWTOs/Bug triaging]] |
| | |
| * Have at least KDE 4.7.3 installed
| |
| * Head on over to the [https://bugs.kde.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=plasma Big Bug Listing]. (See: "How To Add the Plasma Bugs Listing To Your Bugzilla Account" below). You may also instead visit the [[https://bugs.kde.org/component-report.cgi?product=plasma bugs by component table]] and pick a specific Plasma component to work through
| |
| * Pick 5-10 bug reports (starting somewhere in the middle of the list is recommended) and record those here http://notes.kde.org/plasma with your irc nick so we know who is working on what
| |
| * If the bug is reproduceable and you can add more information, leave a comment on the bug report
| |
| * Any bugs that need additional review, note as much on notes.kde.org
| |
| * If you run into any issues or have questions, ask in #plasma on irc.freenode.net
| |
| * When you've gone through all the bugs on your list, remove the ones that were closed, marked as dupes, etc. from the list. Note the severity of the bug on notes.kde.org, review with one of the developers in #plasma and move to another list!
| |
| | |
| == Privileges on bugs.kde.org for closing/dupe/etc ==
| |
| | |
| If you are interested in working with Plasma bugs, request an account upgrade from aseigo in #plasma. Your account can be upgraded to allow closing bugs, marking duplicates, etc.
| |
| | |
| == How To Add the Plasma Bugs Listing To Your Bugzilla Account ==
| |
| | |
| * Log into bugs.kde.org
| |
| * Select "Edit my preferences" in the left sidebar
| |
| * Click on "Saved searches" in the tab bar
| |
| * Search for "plasma" in the shared saved searches listing and select it to add it to your sidebar
| |
| | |
| == General guidelines for bug triage ==
| |
| The goal is to help the plasma developpers sort through the bug reports and figure out which need attention and which need to be closed (and closing them with some indication as to why)
| |
| *Duplicate bugs: if a bug is even moderately common, we WILL get duplicates of it. Often lots of them. However one bug report is enough.
| |
| *Already fixed bugs: a lot of times we fix things and don't catch all (or sometimes any!) of the relevant reports.
| |
| *Simply too old bugs: a lot has changed since, say, 4.4 and yet we have a lot of reports from then. Sometimes they are still reproduceable, often not and it's hard to know if they were "really" fixed. '''If it doesn't seem reproducable in 4.7/4.8 and it's 4.5 or older, just close it'''. There are also some components that have been rewritten. e.g. the notifications widget has been rewritten in QML for 4.8. any bugs against it from 4.7 and before need to be checked with the new plasmoid
| |
| *Wrong products bugs: these are bugs that are filed against plasma, but realy are about dolphin or ksmserver (which handles the log out / reboot / shutdown dialog). These need to be categorized properly. '''Network Management, Marble, Python bindings and Solid''' are the common case there.
| |
| *Upstream/Downstream: bugs in Qt, x.org or 3rd party plasmoids are not something we can much about in most cases. Those should be closed with upstream/downstream (upstream if it is qt, x.org, udev, etc.. downstream if it's a third party add-on / plasmoid).
| |
| *The rest should be valid bugs that will need to be taken care of.
| |
| | |
| One of the trickiest things is to identify duplicates. It gets easier once you get familiarized with the bug database, but in the meantime you can use bugzilla search capabilities.
| |
| | |
| For crashers, see below for how to look at a backtrace.
| |
| For non crashers, just try and repeat the steps.
| |
| For problems with individual plasmoids you can often use plasmoidviewer to run just the one plasmoid in a variety of ways (as if it were in a panel or on the desktop, with a different svg theme, etc) so that you don't have to mess too much with your plasma-desktop.
| |
| | |
| == Looking at a backtrace ==
| |
| For crasher bugs, you will need to look at the backtrace that needs to be provided with the bug. [https://bugs.kde.org/show_bug.cgi?id=271182 reasonable backtrace] is a reasonable backtrace. The section that starts with [KCrash Handler] is the one indicating where the crash happens, most often in thread 1 (as in the example).
| |
| #6 __libc_free (mem=0xffffffff) at malloc.c:3709 <-- lines like this are the trace through the application.. so this was the last thing that was executed before the crash. In a good backtrace, most lines will have a file name and line number like this: painting/qpaintengine_x11.cpp:256. When those line numbers are missing, the backtrace is a lot less useful and it means that the reporter does not have the debug package installed.
| |
| The backtrace is read from top to bottom, until we reach kde code, noticeable because things start being called k<something> and/or plasma_<something>. In that particular case, the interesting line is #20 QPMCache::flushDetachedPixmaps (this=0x1fc0270, nt=<value optimized out>) at image/qpixmapcache.cpp:250. To look for duplicates, at the top of the page there is a "Search Existing Reports".. open that in a new tab in your web browser then take "flushDetachedPixmaps" and paste that into the "A Comment:" field,
| |
| select "plasma" from the products listing (hit 'p' from the menu list to go faster) and submit the form. It should return the following bug: [https://bugs.kde.org/show_bug.cgi?id=252816 second backtrace]. In this bug you can see that even though they had different ways to reproduce .. they look very, very similar. Bugs.kde.org will also put "This bug may be a duplicate of or related to" and "Possible duplicates by query:" links at the bottom, often saving one from manually searching. If you see such similar backtraces, check with a developer and we can confirm if its a duplicate. Eventually you'll get a feel for it. If the backtraces are essentially identical you can just mark it as a duplicate.
| |
