This topic can be used to discuss any questions about the Dolphin bug triage event which I will start soon. To help us triaging Dolphin's bugs, have a look at the wiki page that we use for coordinating this event and pick a batch of bugs to work on:

http://techbase.kde.org/Contribute/Bugs ... olphin2012

Any help is greatly appreciated

When a bug matches more than one category (e.g. a wish, reproduceable, its version is not up-to-date, is in the general component while it should be more specific, etc.), do we put it in all those it belongs to, or only in one of them?

Also, if I have the permissions to update the version, or the component, or add the reproduceable flag, should I (1) do so, (2) add the item to the pertinent list, or (3) both? And if both, should I mark the item in the list somehow so it is visible that the changes to the report have been already performed? And if both or “do so”, where is the limit? What changes should we perform in the report and which ones should we not (following the 4-eyes approach)?

Hi, and thanks for your help!

Gallaecio wrote:When a bug matches more than one category (e.g. a wish, reproduceable, its version is not up-to-date, is in the general component while it should be more specific, etc.), do we put it in all those it belongs to, or only in one of them?

Putting it in all categories is a lot of work and might make the page harder to read. I'd say that we could put it only in the first category where it fits and just add a comment on the page telling what other things need to be updated.

Gallaecio wrote:Also, if I have the permissions to update the version, or the component, or add the reproduceable flag, should I (1) do so, (2) add the item to the pertinent list, or (3) both? And if both, should I mark the item in the list somehow so it is visible that the changes to the report have been already performed? And if both or “do so”, where is the limit? What changes should we perform in the report and which ones should we not (following the 4-eyes approach)?

I think changing the version directly is OK, the component as well, provided you're very sure about it

Adding the 'reproduceable' flag is OK if you've reproduced using a source build, in other cases, I'd prefer to follow the 4-eyes approach here, to make sure that this bug isn't just reproduceable on a certain distro.

If you have made the changes directly, in principle you don't have to add it to the categories in the wiki page. You can do it if you want though to give a better overview of what has been achieved so far. But then you should strike the link through using <s>...</s> to make it clear that the changes have been made already.

Just thought I'd mention that KDE SC 4.9.3 was released today. It fixed 9 Dolphin bugs (full list of fixes here). I'm guessing you would like us to upgrade our installs?

dniMretsaM wrote:Just thought I'd mention that KDE SC 4.9.3 was released today. It fixed 9 Dolphin bugs (full list of fixes here). I'm guessing you would like us to upgrade our installs?

Thanks for your message. Upgrading to KDE 4.9.3 isn't strictly required, just do it if it's not too much trouble (distros might not even have their packages ready yet). For the time being, working with KDE 4.9.2 should be fine. Thanks for your help!

freininghaus wrote:Thanks for your message. Upgrading to KDE 4.9.3 isn't strictly required, just do it if it's not too much trouble (distros might not even have their packages ready yet). For the time being, working with KDE 4.9.2 should be fine. Thanks for your help!

I went ahead and upgraded my Kubuntu install (the packages are available from the Kubuntu Updates PPA if anyone is interested).