As others, bigger members in the KDE community say, “nobody will do it for you, and therefore they will”. The patch from the title comes from such a story.
Let’s give some background first: I’m really a heavy activity user, especially when working. My home PC has about five activities, my work one 3, and I managed to compartimentalize the various “topics” that each activity does pretty well.
After an update a couple of weeks ago from the latest code from KDE git, I started noticing weird behavior. Activities would not start when stopped, and there was no way of getting an application on a single activity. As I had set up KWin rules, that made things even worse.
Like many KDE users before me, I found myself in front of a bug.
We got a problem… what to do?
What to do, indeed? First of all, I opened a bug report. There’s no way a KDE developer can find a bug if it occurs only to me if I don’t tell him/her. And since emails and IRC communication tend to get lost, it’s always better to use the bug tracker. However, my initial report was very sloppy, as I didn’t know what was the cause. There was no way it could be useful for Ivan (the kactivities library’s developer).
Hunting the beast
So first, I tried to investigate more about the conditions of the bug. What would trigger it? Why sometimes it seemed not to appear? I tracked it down to KWin’s handling of activities: setting up fresh activities meant that they worked, but only if it was restarted. I thought about pinging Martin, KWin’s maintainer, but I was not sure it was the right cause. As the bug made my activity usage worthless, I had two options: put up with it, or do some of the dirty work myself.
I chose the latter.
I have been learning C++, and while I’m not even close to being able to do something in Qt/KDE, it was enough for me to plant some debug information in KWin and in kactivitymanagerd, the activity manager daemon. After about two hours of tests and recompiles (remember, I’m quite inexperienced!) I found that KWin was not getting the lists of activities correctly from kactivitymanagerd.
But it was working before, wasn’t it? Exactly when, though? In that moment, I remembered that git offered a tool that would help me: git bisect. About thirty minutes later I found the commit causing the regression I was seeing. I then added all the information to the bug report. Not content, I also asked a few other people to reproduce it.
One of these was Aaron himself, who confirmed the issue and then brought it up to Ivan’s attention. With the information he had, he was able to find the cause and commit a possible fix to KDE’s git repository.
So what’s the conclusion of this? I doubt this would have happened without actually doing some of the dirty work myself. This does not mean you really need to go to these lengths when doing a bug report, but when you encounter one, try to give as much as information as possible: as you could see, my initial hypothesis of KWin being the culprit was not correct. If you file detailed bug reports, not only the developers will be able to fix the bugs faster, but it will also make their lives considerably better.
FOSS is all about collaboration and sharing: sharing my time to investigate an issue and helping the developer fix it made the software better for those that will use it tomorrow, or in the next version. And this is also possible thanks to the strength of the KDE community.
Luca Beltrame KDE · LINUX
activities KDE Linux plasma