Badges? We don’t need no badges.

It’s one of those yearly things, scheduled for less than two months from now. Frankly, I’m a little surprised that no one else — Paul Adams is a usual suspect — has bunged up some badges for this year yet. So here’s my entry for Akademy 2013 in Bilbao, showcasing, as always, my most excellent kolourpaint skills. And, like it says on the tin (brass? what material are badges made of anyway), Akademy doesn’t fit my schedule this year either. My only remaining hope is to integrate the conference with a three week train-and-bicycle vacation for two adults and two kids.

Posted in KDE | 2 Comments

FOSDEM 2013 (Legal Quotes)

“Minimal compliance vs. abundant compliance” “It is imperative that Free Software becomes visible in App Stores” “Morally wrong is sometimes practically convenient” “Clarification is difficult” “Bastards”

Last time I was at FOSDEM was three years ago, I think. Part of the venue has moved to a new building — it’s much bigger and airier. I must say that I don’t miss standing next to the drafty exit at the lower end of the H building, but it did have its charm. Plenty of interesting stands to visit. GNOME still have their nice round 2″ foot stickers. KDE is well-stocked with T-shirts, but our hoodies and bags have sold out already. Postgres has very nice frosted-glass mugs. Oracle has no mention of Solaris at all — drat, I was vaguely hoping they might still have Solaris beer mugs. For once, I’ve got some time to visit talks, the legal devroom in particular.
The legal devroom is just packed — has been all day.  I think that’s an amazing change (for the better) from a few years back when legal was still a tiny niche topic.
Posted in Bla Bla | Tagged | Comments Off on FOSDEM 2013 (Legal Quotes)

Keeping SSDs fresh

With a new SSD the laptop is quieter and feels faster than before. I want to keep it that way, which (still) means keeping the number of writes to it down. OpenSUSE has some tips, as does Fedora, but they leave a few bits untouched which might be useful, so I’m taking note here.

 – Make /tmp a tmpfs filesystem. This means no longer relying on /tmp across reboots, but those are pretty rare since I usually just suspend-to-RAM.
 – Make /var/log tmpfs, too. This is an agressive optimization, but I think it’s acceptable for a laptop.
 – Disable scheduler on disk sda, force syslog to write to /var/log in RAM.
 – Set syslog to log warn and above only.
The hard part is getting rid of a .xsession-errors that keeps growing (and getting written to). KDM can be configured to write the file elsewhere (and that’s documented) but you still need to hack the Xsession script to stop X from (re-)creating that file. I kept meaning to write down what I did, but .. good intentions and all.

Speaking of good intentions: I’ll be at FOSDEM, mostly at the KDE booth (everyone at the booth has also written “but I hope to attend some talks, too” on the schedule, so we’ll see. It’s been quite some time since I remember sitting with Anne-Marie at the bar across from Manneken Pis, ordering all the beers we couldn’t pronounce.

Posted in Bla Bla | 10 Comments

Activity Blobs

Albert’s item about Okular contributors (a great idea to thank those who contributed their time over the past year — and I’ll say thank you to all the Okular developers who make my document-reading-life a nicer place) and also Seif writing about Mozilla contributions spurred me to quickly hack together a tool to give an idea of the activity in one of KDE’s git repositories. It’s much like the venerable green-blobs graph that Paul Adams makes. It’s just an indicator — I’ve written about this time and time again, the graphs from one repository cannot be compared with other repositories, and the best you can quickly conclude based on these pictures is whether development activity in a repository is carrying on “as usual” or has changed.

So here’s a graph of Parley, a small program that is probably considered feature complete.
This is three different graphs mashed into one. There’s no dates on the graph, but it covers roughly the past year of development.
  • The green blobs indicate that the named contributor committed in that week. So for Albert (the same one) there’s a single commit at about week 40 in this view. Christian (Muschick, I was lazy in coding up the labels and just cut off the string at 10 characters) was active about half a year ago, and there are incidental commits from others. Script Kid is our own translation commit-bot, who shows up everywhere. Anyway, the green blobs give an idea of who’s active, when.
  • The red line is an indicator of how large the active contributor community is. The bottom of the image is 0 (up to a maximum of all the contributors). In the past, we defined all kinds of complicated metrics to do so, with exponential decay applied to each contributor’s “activeness” and such. This one is dead simple: a participant is an active contributor if he or she has a commit in a given week or in the previous week. That is, each person is considered active for at least seven days after their last commit. This is easiest to see at the beginning of the graph, where Jan’s single commit shows two weeks of “active community size is 1″, and right in the middle, where Scripty counts for two weeks and then drops away.
  • The top black-ish line gives an indication of “temperature” in the repository, mapping the number of commits that week to a color, where pure red is “the maximum number of commits” and black is “none at all”. Since this repository has a maximum of three commits in a week, the color scale shows few different levels. This is another way of looking at the activity of the repository. Instead of number of active contributors, look at the average commit-churn.
Each of these indicators in itself isn’t all that interesting. And they’re naturally correlated in Parley, with the most active week with the most contributors coinciding. It’s possble for that to be otherwise, though.
(The temperature graph, in particular, is something I’m not really happy about as it doesn’t give a good feel for activity; most of the weeks are way too dark even when something is happening, and you can hardly tell #000000 and #230000 apart in small boxes like this. I’d like to have something more sophisticated than a linear interpolation between 0 and 255. Ideally something that goes from “cold” to “hot” in a colourful fashion, but I don’t know about color curves and things like that.)
So how about Okular?
I hope that’s the same list of contributors as what Albert — who you can see is almost always active — mentions in his thank-you note. You can see who the “regulars” are in Okular, who drops in occasionally, and who seems to be a one-off occurrence (which means a bug fix, or a single contribution — those too are appreciated!). On average, there’s five, maybe six people active. You can see some “hot” weeks commit-wise, even weeks uncorrelated with increased contributor numbers. (O yeah, Ivan: the Python Imaging Library doesn’t like Unicode when used with its default font, so your name and others get short shrift).
Supposing you’re a community manager (or a project leader, or just concerned about the activity in some particular application) then you might watch one of these graphs to detect changes. Although given the implementation here, you’re always a week late (and again: you’re then looking for explanations a posteriori).
I’d show the kdelibs repository as well, but it’s mostly very tall. because there’s lots of names in it in total, and an average active contributor count of sixteen or so (by my primitive definition of “active”). There’s something weird going on with the distinction between “authored date” and “committed date”, but that’s for a different time.
Posted in KDE | Comments Off on Activity Blobs


Over the Christmas season we bought an electronic drum kit so that my daughter can practice at home; she’s 9, but I hope that some day we can play “Ace of Spades” together. But the most exciting item in the large box was the empty box! I have not opened it up to ascertain if, indeed, the box is empty. Who knows, it might even contain KDE 4.9.3 packages for FreeBSD.

ObKDE: I found David Narváez post about the term “real-life” intriguing. Way back, Sebas and I used the terms “work-work” and “kde-work” to distinguish between “the time spent developing software for which (time) we are paid” and “the time spent developing software which is fun”. That seems a little less pejorative (and sometimes the two overlapped). But there’s another angle, not one pitting “KDE time” against “useful time” like David suggests. It may be that people writing about “real life” use that as a contrast to “that portion of life spent in virtual environments”, i.e. that it’s about computer-vs-non-computer related time with no value judgement on the value of either. But I feel he makes a good point: the words we use to describe the effort we put into KDE makes an emotional difference.
(Edit: somewhere the combination of Blogilo and WordPress makes a mess if you fill in an HTML element like <div/> in the post title — you can help out Blogilo and KDE-PIM here.)
Posted in Bla Bla | 1 Comment

Eerie silence

The Samsung 840 SSD drives have dropped enough in price that I bought one (for this year’s combined sinterxmasbirthday). Then I pulled my older AMD machine out of the storage closet and installed OpenSUSE 12.2. Which in itself isn’t much of a story, except that installing from a silent USB stick, onto a silent SSD, with a energy efficient low-power CPU and a silent fan is an eerie, creepy experience. A machine that, within the limits of my hearing and against a background of one humming hard disk in a NAS box, is totally silent while doing work — that just doen’t fit with my ideas about how machines work. Kind of like electric bicycles and cars need some kind of noisemaker to announce their presence, otherwise they are scary as well.

The difference an SSD makes is amazing; those little starting-up fireflies from OpenSUSE buzz around like they’re cooked up on amphetamines and cold-start to KDE (with auto-login) is something like 15 seconds. It’s moving into my laptop, where I hope it will also have a positive effect on battery life.
And for noisy working machines, I can always stick to my Core i7 with three bricks full of spinning rust; that really sounds like it’s doing some work, especially when building KDE in a FreeBSD VM.
Posted in Bla Bla | 1 Comment

New year

Ah, new years. A time of (sometimes planned) changes. Inge, I hope your hand gets better, or whatever it is. Me, I’ve resolved to quit being such a wuss with respect to git and actually use it a bit, and so after a long absence put something into the KDE source repositories again. I’ve contacted some maintainers for a little guidance. David’s post from two months back is going to help, too, since SVN fits in my brain (as do some distributed VCSses, but not git so far — not without violence).

Posted in Bla Bla, KDE | 2 Comments

KDE Testing

David Edmundson’s two little entries on the planet about KDE testing for 4.10 reminded me that there’s another release coming up, and that I could help out. Besides, it’ll be fun, futzing around with a bit of C++ code again and around with apps that I normally wouldn’t use. Last I tried this, it was to clean up the KDE 4.4 buglist, so it’s been a while. I shuffled some hardware around so I could set up some virtual machines.

For some reason I don’t understand, I  get completely bogged down in modern Linuxes when trying to do any kind of development. Maybe it’s the rabbit hole of OpenSUSE documentation that stops me. In any case, after spending some time trying to get the excellent build-tool working (I know it’s excellent, I’ve used it in the past) I gave up on that VM. It’ll be a test-machine for future upgrades or something.
I tried to get OpenSolaris (well, OpenIndiana) up again, but my existing virtual disks wouldn’t boot. I didn’t feel like re-starting entirely and then trying to figure out how to get a compiler again, since the KDE4-OpenSolaris stuff was written for the SunCC compiler which is no longer easily obtainable. So strike that off the list for now. At some point I’ll have to do some comparisons across VMs with a similar version of KDE, for kicks. A quad-core CPU ought to be able to run three VMs with single-core virtual processors at once, right?
So I end up back up with my old love, FreeBSD. By accident I downloaded the 9.1-RC3 disk, which installs just the barest of systems (for FreeBSD, anyway, so that means a complete set of development tools, ports and src if you want them). Since it is an -RC there are also no pre-built packages for it, so that meant compiling everything. Which isn’t that bad, you can (roughly) just start in kdebase-workspace and xorg, build and install those two (plus all their dependencies) and you’re good. I followed the area51 instructions, which (for me at least) do the right amount of explanation and I can follow along the compilation steps in the Makefiles. Some ports have been recently updated while area51 hasn’t been updated to match, but a little chat on the K-F channel cleared that right up (PCRE has a newer .so version, as does SASL, which also has a broken -ish header file — that kind of things). After a few other gotcha’s (system-configuration thingies, basically because I haven’t used FBSD much these past two years), I’ve now got a suitable KDE 4.9.3 system up and running. Time to update bits of that to 4.10 and commence testing!
Posted in FreeBSD, KDE | 2 Comments

Patching TRAC

At work-work, I maintain a Trac installation for our project management stuff. Well, PM is probably a too-big word for it, it’s mostly a list of tickets (bug reports) that get sorted through as and when we have time to do so, and a wiki for documentation. There’s a timeline in Trac, too, showing what has happened recently: wiki edits, commits, and ticket changes. This week we got a ticket asking for an improvement in the ticketing system — asking for a filter to suppress commits to trunk (in SVN) so that only the fixes to the released branches are visible. For an application administrator who want to see whether there are relevant fixes for their installation, that’s a useful feature.

So for the first time in ages, I’ve ended up sort-of being paid to work on some Free Software (Trac is BSD 3-clause licensed, with  no-endorsement). Well, since it was a fun kind of project, I did it on the train home. A downside to that is that I wrote a hack to add a specific filter to the timeline, with specific settings for our SVN. That makes the patch — only two dozen lines — unsuitable for publication. When I got home I went looking for existing implementations (one might say that this is backwards, but really, what else is there to do on the train between Utrecht and Nijmegen?), and found that timeline filters are much-requested and rather fiddly to get just right. There was a plugin for older versions of Trac, but it no longer works with Trac 0.12.2 and is unmaintained. And now I’ve got a replacement that works, but only works for one particular setup. This is unsatisfactory for me personally, but it’ll take a bunch more train trips to massage it to a point that it might work elsewhere.
So that was a brief, but fun, excursion into some other code base than our own, and I found it quite refreshing to be reading Python code done in a different style for once.
Posted in Bla Bla | Comments Off on Patching TRAC

Sharing bugs, fixing code

Bug sharing is sexy!Martin Graesslin has taught me much this week. Back in april I wasn’t paying attention, so I missed his series of blog posts on for developers, and in particular I missed the bit on saved and shared searches. It bears repeating: if you have an interesting search and are logged in, you can save it (with a name) right from the search results; then, go to Preferences (upper right) -> Saved Searches (middle tab) and you can share a search with others. 

Saved search list

On the consuming end, you can also check particular searches that have been shared (e.g. by Martin for KWin, or by the Amarok folks) and they will follow you around in the web interface to, ready for instant use. Probably at some point the list is going to get too long and we’ll have to think about whether “KDE 4.4.4 bugs in KWin on FreeBSD” is really a highly visible category of bug that needs to be in that list (it isn’t, relax).
By answering a few questions, Martin also helped me futz around with KWin, trying to patch up one bug that I spotted in the KWin list. I also found Dominik’s Compiling KDE4 notes useful – I remember using them as well when trying to scratch an itch in Kate.
It feels good to be writing (and reading) C++ again, I’ve been under a pile of Python WTF rocks for so long I’d almost lost the feeling for when code is beautiful. (O yeah, and where did the KDE Development book come from?)
Posted in KDE | Comments Off on Sharing bugs, fixing code