Plasma/bugdays: Difference between revisions

From KDE Community Wiki
mNo edit summary
(→‎Current: Remove old information, send viewers to Bug triaging page)
 
(16 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.

Latest revision as of 19:38, 12 September 2018