Good News for multiple battery KDE users

multiple battery support in KDE Plasma 4.4Today, a package was delivered to my house containing an item which I’ve been missing for a long time, years in fact. A second battery for my laptop. I’ve been working on various power management solutions in KDE in the past years, and they all had one problem: I couldn’t really test if everything worked with more than one battery plugged in. In that area, I always depended on others to help me debugging and fixing problems, not the ideal workflow, so some bugs have gone uncaught in the past.

Not anymore! Now I’ve got this second battery in the optical drive slot of my dear Thinkpad T60, I can immediately identify problems with displaying the charge rate of more than one battery, and I did. One bug displaying a wrongly formatted translation string in the battery’s popup has already bitten the dust, within one hour of delivery of the second battery, I committed a patch to the 4.4 branch and trunk of KDE SC. As far as I can see, showing the charge rate of multiple batteries basically works. I’ll probably find more room for improvement as I use this new setup, but for now, rejoice!

KDE SC 4.4 branched, trunk reopens

So tonight, release-team-hero Dirk has branched off KDE SC 4.4 from trunk. Let quickly explain what this means. Trunk/ is a directory in KDE’s SVN repository, the central place holding where all the code from different contributors spread across our planet comes together. In a big team like KDE, we need some coordination to be actually able to release our software packages once in a while. Since the release of KDE 4.0.0, a typical KDE release cycle takes 6 months. Roughly 4 months of development, followed by about 2 months of stabilization and testing towards a release. In the stabilization period, which starts with the feature and string freeze, only bugfixes and code improvements are allowed. This is also the period where we release regular test releases, in our case a beta1, right after the feature freeze, and a second beta (happened shortly before christmas). The next test release is coming soon, which is -rc1.

This time around, we have slightly changed the original schedule. This made it possible to depend on Qt 4.6 with KDE 4.4. Between the release of Qt 4.6.0 and KDE 4.4.0 needs to be a bit of time. The release brought a lot of changes and new features, so a bit more testing is in place. In a complex software stack like the KDE one, there’s many cases you can only find and fix with enough people running it. So we inserted an additional two weeks, which makes us align nicely with the new Qt, in fact there will be a Qt 4.6.1 available with a number of fixes that are pretty much essential for running Plasma and many KDE applications, like global shortcuts which has been a problem recently (a fix for that will be in 4.6.1, Thiago told me). We’ve inserted another release candidate, so there will be an -rc2 before KDE SC 4.4.0 is out, as you can see in the release schedule. KDE SC 4.4.0 will be released on 9th February. The x.y.0 releases are followed by monthly updates, which bring bugfixes and new translations.

I’ve done a clean build of KDE 4.4 trunk last night, and I must say I’m quite impressed. There’s a good amount of polish added, everything feels smoother, faster and a couple of really nice features have been added (Blogilo, the program I’m using to write this article, for one). I’ve also test-driven the new netbook-shell in KDE 4.4, and am really happy with it so far. I think, even with the huge amount of changes that went in, KDE 4.4.0 will be a very nice release already, followed up by the monthly bugfix and translation updates of course to provide fixes that arise post 4.4.0. The translation cycle of KDE (there are more than 50 languages available for KDE 4.4), differs a bit from the release cycle. Translators cannot sensibly work off of a constantly changing base. That’s why the feature freeze goes along with a string freeze. This way our localisation teams get the chance to produce a well translated release — something that might not matter a lot to many developers who run bleeding edge english UIs that haven’t even had a chance to get translated. The string freeze makes sure that no new translations are added. Starting with the string freeze, translators are constantly updating the translations for the test releases and then from the 4.4 branch, this way, our x.y.1+ releases are also ever more complete in other languages. In the end, he 4.4.2+ releases is what many people will actually be running for a while, so it’s important we provide a series of updates for them.

So much for a "quick "explanation of how the release process works. In the first paragraph, I told that KDE SC 4.4 is now branched off from trunk. This means that we now start to maintain the KDE SC 4.4 series in a separate directory in KDE’s SVN repository. It also means that if you have an SVN checkout pointing to trunk, you will now get what is to become KDE 4.5 this summer. Anything you commit to trunk from now on will not automatically appear in KDE 4.4.0 and its subsequent releases. That in turn means that through the normal distribution route, your particular patch will not end up on an end-user’s machine before somewhen in fall 2010.

There’s two ways to get those fixes that you’re making faster to the user:

  • svn switch to the 4.4 branch. This is actually what you should do (in the ideal world of the release team’s people, anyway). It would be good to have as many people as possible working with the 4.4 branch, at least until we tag 4.4.1. This makes it easy to fix the first wave of bugs we’re getting in after the release of 4.4.0. It’s basically the issues people find who don’t run betas (but are willing to install additional packages by hand to get a newer KDE)
  • svnbackport fixes you make. If you are working on some code and are fixing something, consider backporting this to the 4.4 branch (in case you’re using trunk, or another work branch). In kdesdk/scripts, you can find the excellent svnbackport script, which makes it really easy to commit a certain patch also to a branch. It can be as easy as one command, and your users might get a fix 6 months earlier.

While trunk is unfrozen (thawed?), the 4.4 branch of course stays frozen. In there, you shouldn’t commit new strings that would need translation, also new features should only be added to trunk.

As Aaron mentions in his retrospective article, the release team is well in place. I have to agree there. My experience as the "dude who does the announcements" is that the collaboration is really good and natural. We manage to keep the amount of policy sane (believe me, we do!), and we do actually succeed in getting good and stable releases out the door. We’ve hardly slipped our 6 months cycle since the release of KDE 4.0, 2 years ago. And we make our users (new and potential) happy with regular releases, and then actually care about them and supplying monthly updates. The work within the team is also pretty relaxed. For all the work that needs to be done, we have responsible and reliable people that "do the actual thing", we keep short communication lines. At the same time, the decision-making processes feel very natural. KDE does not have a benevolent dictator other big projects (the Linux kernel as a popular one), instead decision-making is done by "those who do the work", taking input from others. Decisions are taken by consensus. This might lead to deadlocks in some cases (strong opinions on either side), but it appears to work really well for KDE development. This takes a bit of discipline from everybody, but I think it yields great results.

Lastly, Dirk (one of "those who do the work") tagged KDE SC RC1 tonight. Tagging means creating a copy of the KDE SC in KDE’s SVN repository, which is then smoke-tested and tarred up as release (and sometimes amended with a last minute critical fix). The tarballs are then uploaded to the FTP master, which distributes the source code packages to the local mirrors, we usually give the syncing 4 – 6 hours, and then announce the release on kde.org, the Dot and to the announcement mailing list. Normally, we’ve put about one week between tagging and actual release. This gives us some time to test the packages (does everything work? does it compile with all likely combinations of dependencies and platforms? and so on). Within this week, the packages from various distros get the packages already, so that they can provide zero-hour packages to their users. (Ever read a release announcement, drooled, and immediately wanted to install it? — This is why zero-day packages are important!) For the test releases, we felt that it’s more important to get the test sources out to the users as quickly as possible, since the version people test with should be as close to what developers are working on (trunk) to make fixing bugs and confirming something’s fixed easier. So RC1 might be out as soon as tomorrow, as it looks quite solid up until now. It means that there might not be zero day packages for those test releases, but it also means that nobody needs to hold back fine RC1 packages until the release team peeps give their blessing.

Thanks for reading all of it, I hope it was entertaining, interesting or enlightening, and that it gives a better idea about some of the inner workings of KDE. My next blog entry will contain a screenshot. I promise. :-)