I’m travelling back from LinuxConf.EU right now. The
conference was very well organised, taking place in the beautiful Cambridge. My talk went pretty
well. For me it was the first time I relied on KDE 4 not letting me down, I did the presentation
from a KDE 4 desktop, using okular. Glad to tell you it didn’t let me down. :-)
Most of the talks were very technical and largely related to kernel-like stuff. No wonder that,
there were quite some kernel developers around, some of which I got to give me some insight what we
as desktop and their upstream can do better.
regular checks with powertop and see who’s the worst offender in waking up the CPU. He mentioned
that 2 wakeups per second is a good value and that we should be aiming for that. (Not having a
recent enough kernel on my notebook right now, I can’t check how KDE 4 does with respect to that
right now.) He also mentioned that the worst offenders are not-aligned timers, so if we use timers
at all, they should all be aligned with each other so that multiple timer events don’t wake up the
CPU more often than necessary. I understand that there’s work in plasma going on to accomplish that,
and that there’s also a patch for Qt lying on a desk somewhere in Oslo which does this for the whole
of Qt. Would be nice if that could make it in quickly. Arjen noted that there’s also related work in
glibc going on. On monday night at Duxford Imperial War Museum, I did an interview
with Linux User & Developer Magazine. Make sure you don’t
miss the next edition if you want to read it. Yesterday, I chatted with Linus about version control systems, especially the difference between git
and subversion. Important aspects are that git does not do well with binary data (especially not if
it changes frequently), it’s just not designed for that (no surprise here). There also seem to be a
couple of performance issues when importing very large repositories (such as KDE).
My major gripes on the whole VCS issue are the following (take git as an example for any distributed
VCS here):
-
Switching from a centralised VCS to a distributed model makes some changes in our social
structure necessary. In a way, a centralised VCS repository is also some sort of social glue that
keeps us focused on one authoritative codebase. We should prevent forking (the bad version) — this
will do harm to our community. Also, I do understand that a centralised way of using git is
possible, but that’s not quite the point here. Also remember that we do not even have maintainers for
all the module in KDE. -
Contributors will inevitably have to adjust their personal workflow. We should make
absolutely sure that this does not increase the barrier to start contributing to KDE. -
Using two VCS in parallel can harm the community. If you really want to use git, make sure
your code is available for others, sync with our SVN repo on a regular basis. I’ve already seen
people using git and not caring about updating the copy in SVN. This hurts our development process,
especially while we want to get KDE 4.0 ready for consumption. -
Consider that switching important tools such as our VCS is a huge step that doesn’t come
without costs. It might even be a disruptive change to how we work as a community. We should not
tinker with our tools more than necessary. -
Switching VCS before we are well underway in the 4.0 release cycle is a stupid
thing to do. One major challenge at a time is already enough for us.
That said, I do see potential benefits from using git. Most of them have been pointed out
by others already. My concerns and thoughts go out more into the social aspects. Git (or any other
distributed VCS for that matter) might perfectly fit how we (should) collaborate as a project. It
might make new ways of creating kick-ass software possible for us, just like it did for other
projects, such as Linus’ baby.