We have a location for it now as well: Randa, Switzerland. If that name sounds familiar, that's because we held Tokamak III there. It's so beautiful, we just had to go back. Ok, and having Mario offer to host it along with two other sprints helps. (Mario is a superhero of developer springs; I think that KDE e.V. should sponsor a superhero costume for him: Sprint Man! But no capes!) Mario being in Zürich is also a bonus, as it will make it easy for me to collaborate with him on logistics starting in March. The sprint is currently scheduled to take place on the first week of June.
There is the usual sprint planning wiki page for it and the number of people who have already signaled interest is great. I want to see a good mix of kdelibs hackers, packagers, developers and our key partners such as Qt devs there.
What is the goal of this sprint? To lay down a near-future practical roadmap that covers the next 2 or so years of development for kdelibs, kde-runtime and our engagement of the platform ecosystem around us. Getting down to work will also be important, so that we can leave not only with plans but also something to show for it all, even if it is just early steps, in the source code.
The participants will ultimately end up driving the actual topics and direction, let alone the conclusions, but here are the points likely to be hot at this sprint:
- Modular, Baby! Did you know Solid only depend on QtCore? What other dependency chains can we streamline? How can downstream packaging strategies shift to reflect these changes so more app developers can take advantage of this progress?
- Mission: Platform Profiles In 2010, we began the work of creating target platform profiles, particularly to differentiate mobile, tablet and desktop usage of the libraries. We have a lot more knowledge of the internal and external needs after this early effort, and need to take it to a compelling milestone.
- The Orphans of 4.0. Some areas of kdelibs did not get the API and design love they deserved, and other libraries got, leading up to 4.0. KIO is one such library. We need concrete plans for them.
- Embracing and Extending Qt Ok, that's a phrase that's most often associated with nefarious plots to do nasty, predatory things to other people's technologies. In this case it's completely friendly, however. We have a number of open questions regarding the role of KDE's libraries and Qt, how to best roll in things like QtQuick effectively without it feeling like a tack-on, how to identify and limit duplication between Qt and KDE libraries, etc. There are many opportunities here to broaden our reach, gift more app devs with ever better tools and help make Qt rock harder. (Relevant to recent bits of news: I've already invited dconf-qt devs to join us for this part.)
If that doesn't sound exciting and challenging to you, you probably aren't a library developer. ;) To me, however, it gives me that feeling I get when at the top of a roller coaster hill: excitement mixed with a little stomach churn. It's going to be an amazing ride.
To get involved, please add your name to the wiki page. If you have already added it, please make sure that it contains approximately how much it will cost to get you there so that I can do up a budget for KDE e.V. to take under consideration. I do need to start adding more meat to the bones of that wiki page as well, and will do so over the next few weeks. I'll keep you all posted.
Oh, and we need a kick ass logo for the event, too. Preferably with a George Clooney reference in it. Ok, maybe not. We do need a logo, though. ;)