Planet KDE

Colour is a big topic at the Libre Graphics Meeting. Today, Kai-Uwe Behrmann will speak about his Oyranos project. Yesterday, it was Emanuele Tamponi's turn. Emanuele presented his work on the Kubelka-Munk colorspace. His presentation went very well, even though some of the less mathematical-inclined people left at the third slide with formulas. I was glad to see, however, that there are a number of rather more in-depth presentations at this LGM.

Showing off the mixing algorithm in Krita

Emanuele discussed the research in the field of pigment representation and his totally new roundtrip conversion method for going from RGB to a realistic pigment colour representation and back with a high degree of realism and fidelity. There are also way more applications for his work than just the colour mixer in Krita.

Emanuele discussing the finer points of colour theory with SVG guru Chris Lilley

Just like last year, it's a really great conference. It's mostly meeting up and talking and getting to know each other, but there's also real, hard work being done. Gilles Caullier from Digikam fame presented the current and future Digikam and has started all kinds of cooperation with other photo handling applications.

By the way, this is my hotel room:

But Wroclaw is a city with many beautiful spots. We had a nice walk with the Scribus people last night, ending up at a restaurant next to this arch: (which Alexandre Prokoudine was nice enough to photograph for me):

Yesterday we took a walk with Udi Fuchs from UFRaw, his girlfriend and a random collection of other hackers to the Japanese Gardens, which unfortunately was closed, but I managed to make this picture of the Centennial Building, built when Wroclaw was still Breslau:

Just like last year the KDE-family did provide us again a gsoc-slot to work on Improve ISO OpenDocument support (in KOffice, particularly in KWord). Not only did the number of mentors drastically increased but personally I also had the feeling the number of very good proposals did. To be allowed to read all of them was such exciting that I found myself spending hours over hours on the huge list reading lots of proposals again and again just for fun. To be able to see such a pool of impressing ideas and developers was already reason enough for me to participate again as mentor rather then as student. Thanks to google for this unique opportunity!

One of the things I totally dislike about the mentor-role is the need to coordinate with all the other mentors on the try to "rank" those proposals somehow what is needed since we can't just select all of them or at least those who are very good but we are limited to a more or less fixed number. The fate of having so much good choices. I also remember my own frustration in 2005 and 2006 where none of my proposals got selected (though looking with my current experience at them they didn't matched into the "very good" category but at the best case in the "good" one). I guess part of that dislike is also the need to base such a decision only on the proposal itself which is text- rather then code-based and therefore, in my eyes, much more difficult to parse. One thing what helps here a lot is to see some kind of planing the student made. So, dates with milestones that allows to see what to expect next few months and probably even some details how the job should be technical achieved - but that may only my biased view on things. Another thing I dislike is that gsoc happens during the summertime which is not exactly the best time to be productive cause of all those sun out there. A gwoc (winter of code) would maybe match better

I guess it's quit usual that everything has two sides and once those ugly selection-burden got taken, the real work and with it the fun starts/continues. As mentor it's important to guide the student specially at the beginning. It may needed to help him to setup a developing-environment (up-to-date trunk, SVN-account, blog, etc.), to guide through the probably already existing code-base, to coordinate (align times, provide a path to start to walk on, offer co-mentors that can help if the mentor himself turns ill, has a hang-over or just needs his weekly sleep-phase to reboot), etc. Really a lot of initial work but it pays out if you see the commits rolling in. That's not only a thing of code but also of a great feeling to see that at least some of the experience collected within last years went "upstream" (probably a similar kind of feeling school-teachers have and what may drive them to continue there underpayed job?). Over the time it may turn from teaching over pair-programming like teamwork till being teached what is then another very great experience.

Back to the topic this blog started with; So, I'll mentor the improving OpenDocument-support and will try this time to blog a bit more about the progress we are doing there since there are rumours out that not everybody does monitor those thousands of commits KDE has each week

After spending the last few days to discuss and plan what needs to be done to solve that rather complex task the most effective way, we did land a first series of commits for this years gsoc just yesterday and that even 2 weeks before the official gsoc-start. Thanks goes here to Pinaraf, the student that does mentor me (or was it the other way around? guess not since he did participate already at gsoc and KDE before and we where able to skip some of the inital steps and are atm already in the teamwork-mode), the KOffice-developers for providing again such a great environment to work in, the KDE-family for there trust in us and the believe in open and free documents and last but not least google for making all this possible. You all rock!

Two days ago, I've blogged about the environmental variable that sets the correct path to the GTK theme was broken. This made GTK apps use the default theme, which looks rather clunky. Yesterday, Kevin Kofler and Rex Dieter committed a fix for this bug. Rocking, dude! :-)

I found a video in youtube, which explains how to use QDevelop. SWEET. vijayiitm, you totally kick ass, thanks! Bring more videos!

(lets try to embed it, I wonder if the planet supports this)

http://www.youtube.com/watch?v=b8ev_b46ln0

...that's what my friends all call me.

Actually they don't but since I am a huge fan of Lynyrd Skynyrd and this blog entry is closely related to the previous one I am (ab-)using yet another of their song titles.

Earlier this week I got rid of the "org.kde" namespace in Akonadi's D-Bus names, e.g. org.kde.Akonadi.Resource is now called org.freedesktop.Akonadi.Resource, to emphasize that we are a cross-desktop project and that the real interaction point for interested parties are the interfaces (and the data transfer protocol), not some specific implementation like libakonad-kde.

Speaking of renaming: I am not yet quite satisfied with one of our D-Bus names, so if you have any suggestions I'd like to hear them.

To further facilitate contributions outside the KDE sphere we have requested project infrastructure on freedesktop.org
Since this will take a while, let all any interested contributors know that getting commit access to KDE's SVN is not an arcane procedure and anyone with a proven track record on another free software project will most likely get approved quickly (I am talking about the order of minutes here).

QDevelop fails to load when running under Qt4.4. This was fixed by revision 321, so if you are running an SVN snapshot, please update. If you are running a packages version, downgrade to Qt 4.3 or compile from SVN, sorry.

This new little guy tells you on the KDE-Edu website that you can find a tutorial related to the program page. Thanks to Arindam Ghosh, you can find a tutorial on how to add words in Kanagram, in KHangMan and how to add a map in KGeography.
This will trigger more contributions and when KNewStuff upload feature is available (in 4.2 only probably) we'll have everything needed to share data. Those tutorials are fun to read and easy to follow, thanks Arindam! Anyone is free to improve them as the .odf sources are also available!

Regardless of what release cycles we will have in future, the next release will come. Depending on how much time you can spend on hacking KDE it might also be there rather soon. Nevertheless the same things will happen for every major release: a bunch of new strings have to be translated.

While the translation teams for Greek, Ukrainian and Portugese are obviously competing for the 100% crown (go on, guys! *g*) other teams fell way behind them. That is not a problem yet, as trunk is still very much work in progress. But one or the other day the string freeze will come and then there is a bunch of work to do. Keep in mind that every percent is more than 1000 strings to translate.

While Germany has a great amount of KDE coders the number of strings untranslated e.g. in this team is big. Many modules from playground have noone actually caring about them. Worst example is playground-network with more than 2000 strings, which is completely untranslated. New translators are very welcome, also we have some requirements. I don't think the other language teams will send you home when you step up to help them, so ask them.

Translation is a good entry point if you want to contribute to KDE (the other one is writing documentation) and don't want to or are not able to do coding. Of course you have to know both english and the language you want to translate to rather well. Nevertheless it's a great help for the module translation maintainers if you even pick only the low hanging fruits and translate the trivial 20% of strings from a big module so he or she only needs to do a quick review. Many terms are rather common between many programs (think of the "File" menu entries and the descriptions in the about box) so you can just copy them from other places without making too much mistakes.

I found the way to the translation team by coding in KGpg. As I'm a native speaker of German I thought it would be best if I not only write the English strings, but the German ones, too. Since I exactly know what happens at certain points in code it was very easy for me to find a useful translation. Afterwards the translation team only went by and polished some wordings, but again I saved them some work that they could spend on other modules. So if you are a maintainer of a program and are a good writer in a non-English language: contact your translation team and ask if they need help for your program (or anywhere else).

And for all those that are not sure what the heck I meant in KGpg with one or the other string: just ask me. The number of string changes until the release should be rather small for KGpg, the work I plan to do is only internal and shouldn't normally touch the strings. So if you translate it now hopefully nothing of your work should get lost and you have some time for other modules later.

By the way: the translation results for the documentation are even worse than the GUI ones (hey Greek team, where are you there? *g*). Be extra careful if you want to work there to check if the documentation still matches the program features. If not mail the documentation author first with a patch to improve the English documentation or ask someone else to assist you with that. A good starting point is the #kde-docs channel on Freenode.

Screenshot of AccuWeather.com just now (to those who said "Gee, it is cold up there!" the moment they knew I was about to move to Oslo):

Ok, we all know, blogs are the new mailing lists, so here just some quick comments from my side on all the release-cycle stuff.

About being in sync with releases of other projects: I am caring for our buildsystem which uses CMake, so the releases of CMake and KDE matter to me. I want to provide a stable (as in "not chanigng too often") build environment. If project A (KDE) depends on project B (CMake), it doesn't help project A anything if it's releases are in sync with project B. Why ?
Because, well, in order to have a stable environment I don't want to force developers to have to update their cmake from non-distro packages (the binary cmake packages provided by Kitware work flawlessly on all systems I tested so far, btw). This is frustrating ("damn, which package do I have to update today to make KDE build again ?") and takes away a lot of time (not for a single developer, but accumulated for all).
So, before we (KDE) require a new version of CMake, I personally want this not to happen before that version of cmake is shipped by the most common distros (i.e. a few months after its release).
So I see also a value in not depending on always the latest and greatest releases of other projects.

Regarding DVCS: I don't have much experiences with them, but when I tried git, it wasn't really easy. Mercurial is said to be much more user friendly, which for me would be a big advantage, lowering the entry barrier to KDE development etc.

But, what I wanted to say: I big part of the value cvs/svn provide is IMO that all code in development is visible to all developers immediately, not only once a while. Especially for KDE with its many many developers this means that current code will be tested (at least built, maybe also run) immediately by many developers, so problems should be found quickly. We don't have that many developers on "exotic" platforms like Windows, OSX, Solaris, *BSD. For keeping KDE working on these platforms it is IMO important not to create more work for them, by requiring them to deal with more repositories.

About "always summer in trunk": sounds really good, but I also see the risk that less people will be working on the stable branch as soon as it is created.

About the 6 months vs. 9 months vs. 3 weeks: I agree with Aaron that 6 months is quite short. It leaves 4 months for feature development. Which also means you should start with the features really soon after the release, otherwise you may have only 2 or 3 months left for that. At least for me it has always been the case that there are weeks where I just don't have the time to do anything significant on KDE. E.g. when I was student, there were the weeks with the exams, sometimes you go on vacation, real-world stuff like moving, visiting friends and relatives etc. add up from time to time. For me this also means a time span like proposed by Aaron of 3 to 4 days for a stabilizing period absolutely wouldn't work for me, since it will happen often that just during these days I won't have anytime at all.

So, this was probably not as nicely written as the other blogs on this topic, but I just wanted to share my view on this too.

Alex

Yesterday was the second day of the meeting, Emanuele has finally arrived and made his final preparation for its talk which is going to happen later today. I aslo finally met Gilles Caullier of Digikam.

We all meet in that nice building of the Technological University of Wroclaw:





Yesterday starded with a talk from Boudewijn about the reason that drive him to work on Krita, so it was mostly an overview of what has been happening in the Academic and Commercial world around digital simulation of painting. Then Pablo did a demo of what you can do with Hugin, panorama and also image calibration to feed the lensfun database, which is cool project whose intention is to allow to easily find the distortion correction parameters for lenses, instead of spending time playing with the parameters.

In the afternoon, we had an interesting talk on how "coders" and "designers" interact, and the problem and solution you can use to make both worlds work together. Then there was a demo of Scribus. And the day finished with an OpenICC meeting to discuss what has been done, what needs to be done, and what we are currently doing at OpenICC, to bring more color management on the linux desktop.

Sebas writes a tremendously great blog, in my opinion, on the issues we face with a 6 month cycle. Please go and read it, as he really gets the issues at hand on all sides.

Sebas also proposes the rather radical idea of, "What if we never froze trunk?" Or, as he put it, "always summer in trunk".

My dream situation would be to have 2 weeks of devel, 3-4 days minimum to stabilize that work (but longer if necessary), rince and repeat with natural breaks for things like life's little interferences, bug fixing orgies and what not. I think we'd find a natural cycle where significant feature improvements would land every quarter or so.

At each known stable point we'd push the changes in the branch back to mainline for others to use and test. The beauty here would be that other developers and testers wouldn't get horrible breakage periods, just steps from relatively stable to relatively stable.

When a release time comes up, we'd sync the last stable point to the release branch and continue on working. No further syncs would happen until the release process of betas and RCs was over, at which point we'd sync up again at the next stable point.

Bugs and other issues that come up during the release periods would be addressed and backported, just as we do for minor releases (though in the other direction).

It would allow KDE to do whatever release cycles the umbrella project wanted while allowing us to breath, as Sebas put it so eloquently, to our own heartbeat.

My hope in discussing this is openly is that we can make necessary changes to allow the above utopia to occur. Maybe not today, or even for 4.2. But eventually. It probably means using a tool that is better than the current svn release (I see a number of improvements in svn 1.5; maybe that will be enough? I'm doubtful, but also hopeful), it means making release branch development not the norm (which it is today) and it means trusting our own rhythms. Such an approach is applicable to far more than just Plasma; many of the more interesting application in KDE's svn face these same issues.

At the same time I don't want to see KDE's development become a difuse diaspora of repositories and chaos. We can come up with best practices together and find a way to satisfy both the release desires of downstream and the development desires of upstream (that's us =)

Of the Libre Graphics Meeting? It seems it is... Emanuele has arrived, as has Gilles Caullier -- doubling the KDE attendance compared to last year. Next year we really must, must, must, must! bring the ksvg2 people, the karbon people -- everyone interested in graphics and free software should be here. The KDE e.V. should start saving up, because it's likely that next year's venue will be Singapore.

My impressions of Poland... The language really threw me off. I've never been in a country where I couldn't understand more than one or two words, and only today I managed "goodbye" in Polish -- and I still couldn't spell it. The train journey from Berlin to Wroclaw was awesome! So much countryside! Beer is fair to great, food is somewhat difficult. But last night we went to a very expensive, high-class restaurant and had a really great dinner -- for about 20 Euro's. Wonderful mushrooms, fresh vegetables, not too salty. I am sorely tempted to go there again before I leave Wroclaw. Wroclaw is a very interesting city with a lot of very beautiful spots. I've recharged my camera batteries, so I might be able to post some pictures when I find my usb cable.

Our hotel, the Hotel Polonia is a once in a lifetime experience. We probably shouldn't have gone there. The entrance looks more like a sex shop than a hotel. The decor is authentic fifties. The rooms are dusty, musty and run-down. The lights tend to be broken, the beds are extremely uncomfortable. And I suspect that On the plus side, there's theater stage in the breakfast room, and breakfast is pretty good. And there's a 24h shop and a taxi stop nearby.

I've given my presentation: it was a bit more generic than last year: the topic was natural media simulation, the field and the future. For most people in the attendance it was a first introduction to the field, and I'm not sure I didn't overwhelm then. But I got very favorable reactions.

Pippin's talk about Gegl was not only deliciously technical and accompanied by frenzied recompiling, but also too long: I had to skip the end to attend Chris Lilley's SVG talk. We had a great OpenICC bof. As with the previous LGM there's a healthy mix of coders, designers and artists, and the artists are giving presentations, too, which is great!

Robert has posted his thoughts, mostly a summary of Mark Shuttleworth's talk at a past Akademy, about 6 month release cycles. It's an interesting read and worth taking the time to do so.

Unfortunately, Mark's presentation was simply full of the same unfounded or just plain ridiculous assertions that Mark is fond of making in public these days. Let's take a few of them:

"Regular, predictable releases which are synced with appropriate other projects provide a sense of rhythm and structure."

To whom? And to what end? It turns out that this rhythm is mostly to downstream, and the structure is completely based on the sense of perception not anything concrete. We can provide for downstream's desire for rhythm, but we don't need to harmonize release cycles with every other "appropriate" project.

It would be like going into a large company that makes hundreds of different products with a loose common theme (ours is software; Lockheed-Martin would be aerospace; GE would be anything that attempts to make money ;) to sync up all those product cycles. Not only is it ridiculously expensive to do so, it just doesn't add up to anything meaningful production wise.

This is the classic mistaking of "what I want translates to what you do". I completely am on side with providing downstream with what works for them, but at the expense of our productivity? Nope. Thankfully I think we can have both.

"It allows projects up/down and across-stream to plan better and co-operate more efficiently."

I've yet to see any evidence for this.

Let's assume project A depends on B, and B releases at the same time as A. That means that A is either going to be one cycle behind B in using what B provides, or will have to track B's bleeding edge for the latter part of their cycle allowing some usage. What you really want is a staggered approach where B releases right about when A starts to work on things.

This goes completely counter to the "everyone on the same month, every 6 months" doctrine Mark preaches, of course.

If A and B are orthogonal, then who cares. There is no cooperation to be had. Unless, of course, you are a downstream integrator wanting new features across the board on every release. I don't think that's really what the mass market wants or cares about, but it's useful to recognize the real drive behind this: it isn't software development, it's software integration for a very specific set of people.

"If distributors believe they can trust KDE's release schedule and release quality then they will allow a smaller safety margin between the time KDE makes a release and the time when distributors need to ship their next release."

The implied statement here is that distributors can't trust KDE if there isn't a set cycle. History proves this one wrong on its face, both in the general sense (last time I checked Oracle, SAP, Microsoft, etc.. didn't do this) and in the specific sense (lots of trust in KDE out there). So this one rubs me wrong just for how it's phrased: it's meant to manipulate based on fear of being left out. I hate being manipulated.

Beyond semantics, however, this can be achieved by KDE simply setting schedules and sticking to them, as we did throughout KDE2 and KDE3 and have begun doing again now that KDE4 is on the tracks. It has nothing to do with set schedules or synchronization.

"Getting the release out is the most important feature."

Absolutely.

"It would be wrong for KDE to specifically pick a distribution to sync with. Instead pick a date which 'conveniently' matches that of other software at the same level in the stack"

This is a classic tactic: recognize the flaw in your position, then spin it slightly differently. Honestly, I don't care if we were sync'd with someone. I care that our development processes work well. Synchronicity matters not one bit if the product is hobbled.

"Regular time-based releases are much easier if features can be landed when they are complete, so that the primary work going on in trunk is integration [..] The kernel developers have proved that this approach can work."

Absolutely; but again this doesn't address the issue of the size of the time based schedule. The kernel developers do not use a six month cycle.

"The regular cycle may have to be suspended for big backwards-compatibility breaking upgrades (KDE 4)"

Absolutely.

"The value of synchronization is sufficiently high"

What is the value, exactly? I mean to the software development process that actually creates the value in the software in the first place. I get downstream's benefit, but since this "value" to them comes at a cost to me and their value is a derivative of my value ... can't they see the shortsighted nature of this position? Really, show me the value. I've challenged people who take this position to do it many times in the past and it turns out the value is in integration and immediate gratification for users. Excuse me for being a strategist, but I'd prefer to win in the long term.

So show me the value. Show me the actual measured benefits of a six month cycle that is generally applicable to every software project.

"The time delay is subject to debate."

Great, because that's pretty much what I'm debating. We either need a way to allow for multiplicity in time delay for development while keeping synchronicity in delay for release, or we need to adjust the delay. But seriously, when Mark says this and then follows it up with "oh, but 6 months is what we found best because ..." and then continues to go on at every opportunity how people should be on a 6 month cycle, the agenda is pretty clear. It may be up for debate ... as long as that debate is whether it should be 6 months starting in April or 6 months starting in October.

So, to reiterate: I'm not against time based development, I'm just not in favour of binding development time frames to the artifice of 6 month release cycles that have exactly one benefactor (distros) and many who pay (upstream and eventually the users).

Tom and Aaron discuss timing and release schedules, and development cycles. Aaron talks about trunk/ and freezes therein should follow a natural lifecycle. This assumes that the whole KDE community lives and breathes as one individual, synchronised and all. So a development-and-release-cycle forces all developers into one rhythm. Everyone has to follow this one release rhythm. It's a good idea, but I think we should also make the lives of those easier that choose another breathing ryhthm. There are a couple of things to consider here. The most obvious being that we need this flexibility anyway. We rely on certain release mechanisms and interface stability policies in other projects as well. (We partly solve this problem by providing abstraction layers, think phonon and solid). Now the interesting case is that Phonon, which is new in Qt's 4.4 release is also provided by Qt. Phonon now breathes in a 9 month release cycle in Qt, and a 6 months one in KDE. So one could argue that it's a smart idea to breathe in the same rhythm as Qt does. We could follow up every release of Qt with a KDE release.
This does not solve the initial problem I think, which I think is "different parts of KDE have different heartbeats". Neither Tom nor Aaron have really questioned the way we currently deal with SVN before releases, so I'll put on my shiny pink asbestos suit and do it.

What if we never froze trunk? Others (such as, incidentally Qt) have no freezes in trunk/ and it seems to be a popular and well-working development style for some. When a release enters a freeze, a branch is created that will be stabilised towards the release. trunk/ at the same time stays open for feature additions. The Golden Rule is "You don't break trunk/ (this is what branches are for)".

(For those not too intimate with development schedules of KDE: trunk/ is frozen roughly 2 months in advance of a release (supposedly every 6 months). After the actual release, trunk/ is opened again for new features. Features that take longer than the allotted time be developed in a branch and moved into trunk/ "when they're ready, but not during freeze".)

The obvious downside of this "It's always summer in trunk" is that you need to spend extra efforts to get people to stabilise, i.e. working in a stabilise-branch rather than in trunk/. It needs more discipline, and probably puts some extra weight on the shoulders of those who simply care about good KDE releases. But as we all agree, SVN sucks for branching and merging. So right now we make it hard for people to work with different branches (stable/ and trunk/). It would allow those that need more time to do their thing to stay in sync with latest features. Basically, it would allow for different rhythms in the community. As this community grows and becomes more diverse this might pay off in the end.
New tools are on the horizon as well. Distributed version control systems allow for a more flexible way of sharing code between peers.

The thing is that we cannot really choose, people are using git anyway. And after having used it for a bit, and git-svn to interact with svn, I have to say that it makes a lot of things much easier. For one, it doesn't force the commit policy of the project ("don't break trunk" maybe ;-)) on yourself or your team, and it makes it easy to share code with others. That might want to work one a feature (or some surgery) together, but others (those that don't want to be affected by this surgery just want their desktop to work. Now imagine these peeps, just start developing features by sharing a number of git trees and committing features to trunk/ when they stabilise, i.e. presumably don't cause regressions. It also nicely solves another issue we had recently. Rafael needs some time to finish Goya (have it API reviewed by Kevin ;-)), but Jeremy already wants to use this feature in GetHotNewStuff2. Those three share a "review" branch, which is merged when everyone's happy (after having been announced on kde-core-devel. (Imagine integration of some sort of peer review system, like review board with this branch!). This development style can partly be tested by a subproject, of course. This subproject can then track trunk/ from SVN and develops features in a distributed way, probably with another branch as master that sits on top of it and tracks. It's not really a technical problem, after all, the tools should support the natural way of breathing for the community. For git in particular, I see the steep learning curve as one of the major show-stoppers right now. It would, at this point simply make the barrier of entering a project much higher, which is not a good thing. With distributed source code management, the question "Which one is the authoritative copy?" becomes a purely social thing. In the SVN case, it's always the SVN server, in the DVCS (OMG!) case, it's "who you trust", that would be the version we publish via SVN.

Interestingly, the KDE's Internationalisation people already work in a distributed fashion. In the Netherlands for example, Rinse collects translations; that are sent to him by the people in the translation team he reviews them and commits them to SVN.

Does this whole mess of an idea also contain a solution for "synching downstream"? One of the reasons why the Release Team initially decided to adopt 6 months releases is to make it easier for downstream (distributions, for example) to ship a recent version of KDE. The thing is that those distributions also have different heartbeats, OpenSuse comes 8-9 monthly, Fedora comes 6 monthly, others as well. Now we're trying to sync with upstream, in different heartbeats and downstream in different heartbeats. Right now, we have the unfortunate situation that we're just too late for OpenSuse 11 (which is really one of the symptoms of "heartbeats out of sync"). At last year's Akademy, Mark Shuttleworth brought up the idea of synching release over the whole Free software stack. While this is a nice vision, I do not see this happen 'globally enough' so that it really works. The trend in the Free Software world seems to be to move to a more distributed way of development.

This "we all breathe synchronously" might be one of the things that ties us together. We've seen this a lot in the time up to 4.0. That was where we as a community acted as one and lifted KDE from 'utterly broken' into a releasable desktop. In KDE 4.x, things are fundamentally different. With all the new frameworks and libraries solidly in place now we we want this to be a stable platform for a long time. That means we develop features on top of it and fix bugs in the infrastructure and extend it - not break it. Basically that's the "Binary Compatible until KDE 5.0" promise.

Moving from one, proven style of development to another is something we should not take lightly. On the one hand it would help us solving some scalability challenges in the community (such as too many different people, expectations, needs for their product and whatnot) and adopting new styles of collaboration in a community where you're free to share.

Things such as new ways of working together and the ever more diverse community's needs, expectations and lifestyles are not something we can ignore. We need to constantly look at ourselves and our environement and think about how we can improve it. Probably not one big step ("starting tomorrow we never freeze trunk again, promised") but hundreds of little baby steps.

What a nice video player. Simple and clean. If you open the application it asks whether you want to use a file or a disk. If disk is selected, it opens the dvd you have in your drive. Files open fine. If you close the app while watching a file, and reload it, it knows where you left off. Very nice. There are few settings available, you can view full screen or window. I believe it uses Phonon, and

Sebas, Tom and Aaron discuss a regular 6 month release cycle. This was first brought up in Mark Shuttleworth's keynote at Akademy 2007. The relevant section starts around 30:00 and in the questions at 42:00. There was more to his argument than just "release every 6 months". The exact time delay was a detail, albeit an important one. For the benefit of those who weren't there and perhaps also those who were, I'll summarize his points:

• Regular, predictable releases which are synced with appropriate other projects provide a sense of rhythm and structure. It allows projects up/down and across-stream to plan better and co-operate more efficiently.
• If distributors believe they can trust KDE's release schedule and release quality then they will allow a smaller safety margin between the time KDE makes a release and the time when distributors need to ship their next release. Consequently, new releases will get to users faster and hence feedback from recent developments will get back to developers faster. Gnome already benefits from this trust.
• Getting the release out is the most important feature.
• It would be wrong for KDE to specifically pick a distribution to sync with. Instead pick a date which 'conveniently' matches that of other software at the same level in the stack. This synchronization may be explicit or it may be "coincidental" (if arranging and publicly announcing such co-operation is unpalatable for whatever reason)
• Regular time-based releases are much easier if features can be landed when they are complete, so that the primary work going on in trunk is integration, as opposed to dividing up the 6 months into slots of X months feature development, Y months bug fixing, Z weeks releasing. The kernel developers have proved that this approach can work.
• The regular cycle may have to be suspended for big backwards-compatibility breaking upgrades (KDE 4)
• The value of synchronization is sufficiently high that it may justify re-arranging the structure of a big project to accommodate it.
• The time delay is subject to debate. Ubuntu found that 6 months works well for them because, for example, it divides evenly into a year so holidays etc. can be planned around it. The appropriate delay depends on where a project is in the stack and what its up/down and across-stream are doing. Further upstream projects can generally get away with a shorter delay because there is of the buffer provided by downstream.

From what I recall, there was a general consensus amongst attendees in favor of the idea - which left the details to sort out. My personal experience with large projects is limited but I think the above arguments are good, particularly the key first point and the evidence from projects which have tried to follow this approach is positive on the whole.

Toma took the time to reply to my blog entry on the six month cycle. He raised some ambiguities that I could probably clarify on a bit.

"First point is the very complex reasoning of the available time to do new features with a six months release cycle, which according to Aarons calculation means that half of the year we are in non-feature development. I don't understand that. "

As Toma calculates, 4 out of 6 months are spend in feature development. At least that's what the schedule says. A common pitfall in management (of any sort) is to keep your eyes on what is written on paper (the theory) and not glance up to examine what's really going on in reality. Reality is that right after a release I spend time doing the following three things:

• Catching my breath a bit (let's call that a day or three, so not significant)


• Responding to bug and wishlist reports; these tend to pick up right after a release and I like to spend the start of each cycle working on the x.1 release that is going to come out soon after the x.0 release. This is usually a significant time sink in the first couple weeks.


• Surveying the landscape, revisiting the feature plan and figuring out exactly what will be done in this next cycle. This is impacted by the results of the last cycle as well as the ever evolving needs and desires for the product. This too takes time and prevents immediately diving in to new feature development

It is not unusual, in my experience, for working on bugs, wishlists and drafting the next cycle's hit list (which hopefully is based partly on an already laid out set of goals, but must also include what got punted as well as shifted priorities) to take a few weeks of time. Therefore, I don't expect a ton of new feature development in the first month of a cycle. This is born out by what happened this first cycle around, and matches with my experience from past projects as well.

That means that effectively we have 3 months of feature development. Sure, what's written down in the theory (the schedule) says 4 months ... but I live in reality, and therefore management of my resources should too.

"I hear you scream that svn branches suck."

No arguments from me there ;)

"moving it to git repositories will give you a lot more overhead and merging that all back at intervals to KDE's svn will frustrate you as well."

Not if we don't do any development in KDE's svn and simply use it as a release dump. There are decent scripts out there to replay git commits into, e.g. svn. This would be a lot easier if KDE were using git as well, but really .. I don't want to start the vcs discussion here. This is about release schedules, the tools that we use making that harder or easier to cope with is another discussion altogether.

"With git you usually merge a completed feature, making the diff too large for people to check on the mailinglists. At least I prefer ten smaller commits to review than one big one."

We use review board for this and it works just fine, actually, especially for larger patches. We can always replay the git commits one by one if we wish, but really that too is a detail. With development happening in a separate repository, we can do all our small commits in usual chunks there and then merge back to the release branch however we see fit.

This is where I get really uncomfortable, though: to solve the issue with an inappropriately sized cycle, I end up moving the development away from the KDE infrastructure which is totally counter productive from the perspective of shared development. This particularly hits us when it comes to internationalization (i18n), but more on that in a minute.

That alone makes me hesitate. I feel like I'm between a rock and a hard place on this one. The rock is a poor choice of release cycle for my work in plasma, and the hard place is our current vcs tool being too poor at merging branches to even consider using it as a solution to the release cycle problem.

Ugh.

"After the period merge back, people using KDE's svn will make build fixes, etc. That will need to sync back to the git repository."

The number of such commits would be trivial and easily tracked even manually. Still not wonderful, but I'd rather optimize for mainline development speed than occasional build and bug fixes.

Note that I already read every commit to the plasma codebases (libplasma, plasma, krunner, extragear, ..) so this is already factored into my work life.

It actually isn't the build fixes, however, that will be a paint. It's the translations: those are scripted to work against our shared svn repository and those would need to get sync'd back and forth regularly. Supporting i18n scares me in this scenario.

"I'm sorry, but if you want more hacking time, this is not the way to go in my opinion."

Merging from a mainline devel git repository to an virtual read-only release branch in one big go is 15 minutes work. Watching for code commits from svn and syncing those back isn't a big issue either, and also mostly able to be automated.

So I think you're vastly overstating the overhead this would incur on my part. Unfortunately, it would really hinder i18n and raise the bar for new people to get involved (another repo you have to know about and another vcs that you have to know how to use).

It's really interesting how this choice in cycles results in degrading one or more of the following: existing development efforts, new comer involvement and i18n. Yes, I know it all looks good in theory ... but history is littered with failures due to deciding based on theory instead of what the theory actually means in practice.

I also disagree with the general remark that a 'six month cycle' does not work for you in this project. How on earth is it possible to judge that, when the very first cycle is not even completed.

Well, this isn't exactly the first project I've ever worked on. =) As for plasma itself, I've seen what this cycle has done and have already spent some time mapping out the next one; I fully expect the next cycle to be a repeat in many ways of this one. So, lots of good development, but lots of punting combined with sprinting to get features in under the wire. This is really the funny thing about the choice of "6 months": it's short enough that timing matters a lot, but not short enough to be suited for fast iterations in development.

It's a lot like trying to avoid stepping on the cracks in a sidewalk where the slabs aren't quite a multiple of your natural stride: you can do it but you end up losing your rhythm and looking like a bit of a goofball in the process.

"I always learned from my mother (hi mam!) that I need to give it a try for a couple of times before deciding it does not work."

That's good advice from your mother. I'm sure she'd also tell you to learn from the mistakes and successes of others, to not repeat errors you've made in the past and to repeat your successes whenever possible. It's not like creation cycles are a new science.

It may be the first time KDE's tried to stick consistently to such a short cycle period, but it's not my first time around.

"The schedule is not set in stone and if you have reasons to change things, mail the release-team."

If I had an idea of what would both work globally and also wouldn't result in me sinking days of my time into a discussion and decisions process I would. Right now, I'm not sure what the best solution is for all of KDE. I honestly haven't gotten to that point in thinking about it. I just know that for the project I'm most deeply involved in, it sucks. That doesn't mean it isn't perfect for other aspects of the project; as I said in my original blog this is a "one size does not fit all" sort of issue, and I suspect 6 months might work just fine for kdelibs.

If you're wondering why previous release cycles didn't cause such angst, it's because if a cycle is longer than you need or short enough to match natural short-term iterations it's not a big deal. KDE always tended to have longer-than-strictly-needed cycles which made them fit really well a broad cross section of the project and, I would argue, thereby actually increasing the development pace.

It's really hard to argue with the pace of KDE3 development.

So, I've no concrete solutions for the problems mentioned in Aarons blog,

Damn! And here I was hoping someone smarter than me would come up with the brilliant and obvious solution ;)

I can understand that a new project requires a lot of setup for the infratructure, but when that's done things will get easier.

This is the "it will eventually be done" theory. That theory works really well for projects which have a fairly limited scope (so a limited amount of internal pressure) that gets applied in an environment that is mostly static (so little to no external pressure). Unfortunately, Plasma has both huge ambitions (so lots of internal pressure to keep moving) and competes in what is right now one of the more competitive and evolving areas (primary user interfaces and the bling that makes them sing) which means lots of external pressure to keep moving.

I'd be very surprised if core Plasma development settles down within two years time. While we may not be mucking with existing code (source and binary compat being what it is), there is a lot left to be added.

Anyways, thanks, Toma, for taking the time for a well reasoned reply. Hopefully the above gives you a bit clearer idea of what thoughts are rattling around my wee little head.

I just used the Kubuntu upgrade tool to get the latest goodies from Hardy (wobbly windows here I come). However, this resulted in a strange looking system. I've found three symptoms:

#1 Klipper and friends start in windows in the top left corner before finding their way down to the kicker dock.

#2 Selecting "logout" or pressing ctrl-alt-backspace results in a blank screen, a hard reset is required to get back to business.

#3 Window decorations are messed up. For instance, Firefox gets some old-style KDE 2-ish look and RMB clicking on the title bar results in what looks like an unthemed menu. However, the desktop menu looks alright.

Desktop menu

Window menu


If anyone knows of a good way to resolve these issues, do let me know.

I arrived in Poland two days ago for the Libre Graphics Meeting 2008. It's an interesting conference where developers and users of graphics applications open source application meet and discuss.

The afternoon before the start of the conference, I had some time to do a little tour of the city:




The first talk on the first day was about Hugin, the panorama creation tool. Then there was one about Phatch, it's a batch processing tools which is very similar to Workflow, except that Phatch is dedicated to image manipulation, and was released.

Then the afternoon started by a talk by some Bruxelles designers who use open source software to do their job. Then there was a presentation about Font and Free Software: the tool to create fonts and how the best way to propagate your work.

Then there was the yearly gegl presentation which was much more technical than previous years, and concentrating on some internal of gegl, it's quiet interesting to see how different and similar are the core of Krita and gegl (the future core of the Gimp). Then I went to a presentation on the upcoming SVG 1.2, and new cool features like movies as background of a text.