The developer sprints in Randa are officially over. I spent my
first full day at home today, and it feels almost odd to be in my
quiet office after all the energized atmosphere we got there during
a full week.
Anyway, remember the
[Platform11 Kanban](http://ervin.ipsquad.net/2011/06/04/sticky-notes-markers-and-chocolate-platform-11-in-randa/)
we setup on the first day? Well, here is how it looked on the last
night:
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1328247947_QMMK56V)
I think we made "some" progress. And that's not counting the
technical tasks which got handled in a separate Kanban. If we had
another day I wonder where we would have put the done tasks. As you
might notice on the picture above we simply reached the floor in
the "Done" column. :-)
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1328247933_Zgn8mQk)
So, is everything said and done now? Well, not really, what we did
really was putting into motion the on-going effort which will lead
us to the first iteration of the KDE Frameworks. We tried to create
the tracks in Randa, and I'm looking forward to get on the train
for this exciting journey!
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1328249452_b6L5GmZ)
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1320952718_CZ9tGh6)
It almost feel like forever since I blogged last. Turns out that
I'm on the road again for a KDE event and so it's the right time to
open my blog and take a few minutes to write something.
I'm sitting in a large house in Randa as I took some time to attend
the Platform 11 sprint. It seems to become a small tradition in the
sprints I attend to setup a
[Kanban](http://en.wikipedia.org/wiki/Kanban_(development)) to keep
track of what we're doing. Since this sprint is about giving some
love and direction to our frameworks offering, I also used the
opportunity to experiment with a couple of
[Innovation Games](http://en.wikipedia.org/wiki/Innovation_game).
The aim of those games was to facilitate the brainstorming groups
we had on the first day. We broke out the output of those groups
into discussion topics that we track in our Kanban, I think the
result is really telling:
[](http://ervin.smugmug.com/Events/Platform-11/17377032_2nhXRP#1320952863_sxRFJqW)
What you can probably imagine from that wall is that we have a lot
of ground to cover. So far it's going on at a nice pace, I'll
probably make another picture at the end of the sprint. We also
have some smaller somewhat individual technical tasks that we're
tracking in a smaller specific Kanban, I might take a picture of
that one as well later on.
We obviously had some very important discussions already, so we
have interesting preliminary results... But I won't talk about that
today, the paint is still fresh on them and we probably need to
consolidate all of that at the light of discussions yet to come.
If you like our frameworks already, or if you were too shy to
really use them: stay tuned for more awesomeness and love coming to
them!
This post is the second one out of two covering my thoughts about
the Solid Developers Sprint 2010 which happened this week-end. My
outbound flight being delayed, I've plenty of time for
introspection in the Madrid airport. :-)
**Disclaimer:** This blog post evolved as a short essay on "Agility
in a Free Software Developers Sprint Context". It is then a
somewhat long read (I don't blog often but when I do...). If you
are NOT interested in at least one of the following topics:
- How the Free Software community works;
- The practices used in the agile project management community;
- How both community driven development and agile management can
influence each other;
Then, you can safely skip this post... But if at least one of those
topics raised your curiosity, then brace yourself and keep reading.
:-)
### Introduction
We have a strong tendency in the [KDE](http://www.kde.org "KDE")
community (and even the Free Software community at large) to
organize so called *Developers Sprints*. We use them to gather
contributors (despite their name they're actually not developer
only events) sharing a common project. A *Developer Sprint* is
going on a short period of time (generally not more than a week,
very often less than four days).
Now, one has to be careful not to confuse our *Developers Sprints*
with the *Sprints* used by the
[Scrum](http://en.wikipedia.org/wiki/Scrum_(development) "Scrum")
practitioners community. They might look similar, in both cases
people are trying to get as much work done as humanly possible on a
time-boxed period of time. But they have a major difference:
*Developers Sprints* are irregular events, while the
*Scrum Sprints* are cyclic. In the latter they form the backbone of
the iterative development advocated by the agile community.
As I happen to teach both how to work in Free Software communities
(through the KDE student projects) and how to work with agile
project management (in particular in an eXtreme Programming
context), it made me wonder if the way *Scrum Sprints* are managed
could be a source of inspiration for the way we manage
*Developers Sprints*. And as some of you might have noticed, in the
past few days I had a perfect environment for experiment... The
Solid team of the KDE community had a *Developers Sprint* where I
ended up managing the work to be done there.
### The three cardinal sins of *Developers Sprints* regarding agility
As I pointed out in the introduction, our *Developers Sprints* are
irregular events, but also you don't have the same participants
from one sprint to another. Because of that, the ability to refine
the velocity (estimation of the amount of work that can be achieved
by the participants during a sprint) is severely reduced if not
completely void.
In turn, without the possibility to estimate the velocity, it
becomes dubious that estimating the work to be done is of any
interest. Indeed, what would be the point of estimating the work to
do, if you have no idea how much you can handle?
Even worse, most of the time there's nothing looking like a product
backlog (a list of fine grained user stories which is "consumed"
from one sprint to another) as advocated by the Scrum
practitioners. At best we have before the sprint starts a list of
very broad and general goals, or discussion topics (a.k.a pain
points)... And, of course, we also have the closest thing to a
product backlog: our bug-tracker. Which is borderline useless in
such a context, it's generally a white noise generated by the
support function, where we mix what we'd like to do, what user
reports (with plenty of duplicates) and so on. Of course, it has
value but in my opinion not to drive a project.
Because of all that, the situation sounds pretty bad to practice
agile project management during a *Developers Sprint*. We don't
know how much we can do, in turn there's no point in knowing how
much time is needed by some piece of work, and finally when the
sprint starts we have a very partial view on what needs to be
done.
Luckily, as we will see in the last parts of this essay, agile
practitioners know provide us tools that we can reuse by bending
the rules while retaining the spirit and values of the original
rule set
([Shuhari](http://en.wikipedia.org/wiki/Shuhari "Shuhari")). The
tools I'm proposing to reuse and combine are the
[Kanban](http://en.wikipedia.org/wiki/Kanban "Kanban") (even though
in an incomplete version for now), the
[Exploration Phase](http://en.wikipedia.org/wiki/Extreme_programming_practices#Planning_game "XP Planning Game")
(in the [XP](http://en.wikipedia.org/wiki/Extreme_programming)
meaning of the term) and
[Pair Programming](http://en.wikipedia.org/wiki/Pair_programming "Pair Programming").
### The perfect experiment: Solid Developers Sprint 2010
So, how did we proceed for this sprint? Let's stop the suspense
now. :-)
#### Exploration through Discussions and Goals
Obviously, it all started before the official start date with
something we're used to for our sprints: provide an agenda. Well,
we did it in a specific way: very lightweight (a few bullet points
with no much discussion between the participants), split into
"discussion topics" and "goals". The reasons for it to be a
lightweight process we'll see below, I'll first examine the
splitting in two lists.
The reason for the goals list is kind of obvious: we go to a sprint
to get stuff done, so we have goals. Stating them before the
beginning is actually a good way for people to engage into the
sprint and collectively give it a direction. The discussion topics
list is here to uncover all the things we don't want to look at. In
this sense, it is the complete opposite of the goals list. When
someone states a goal, he generally already have a plan in mind, is
motivated by it and feels it can be done, we're in the comfort
zone. If something still requires discussion, it means we're
uncertain about it, so putting it on the table when everyone is
here is the best (if not the only) way to push the issue forward
and transform it into a goal later on.
We then waited for the sprint to start (remember, collecting those
two lists is a very lightweight process). When everyone arrived at
the sprint we then started an *Exploration Phase*. To do so, we got
through the two lists we built. Each of the goals stated on the
corresponding list got split into tasks (this is the
straightforward part of the exploration). And each of the
discussion topics got (surprise!) discussed... this one was less
straightforward, so let's see how we managed those discussions.
We generally find those discussion topics in our sprints, they tend
to be broader though and to be mixed with "presentation topics" to
give an update to the other participants about the current state...
The problem is that it can quickly degenerate into a slide fest,
lots of presentations and so on. So we just set a few rules:
- the person who brought up the topic had to detail it in front
of everyone;
- it was achieved by giving a small status update on the topic
followed by the actual problems which were in need to be solved;
- people could then discuss the topic, provide input, disagree
and so on (a moderator might be needed there, we didn't need one
though);
- discussion stops after 20 minutes (it's a soft limit of course,
if something interesting is coming out of the discussion wait a bit
before stopping it);
- if everyone was feeling the topic still needed more
discussions, it was allocated an extra slot after all other topics
got discussed (so you could iterate a couple of times before
emptying the topics list);
- no laptop allowed policy (except for the one typing the
minutes), and this one is a strict rule.
By using such constraints we managed to keep everyone focused on
the discussion. They couldn't derail in a bike-shed because of the
time running, etc. In the background I was monitoring the
discussions to identify actual tasks to be done during the sprint
(and added them to the tasks coming from the refining of the goals
list).
Thanks to this very lean process, we managed to go through the
exploration phase in roughly two hours! That's really not much when
you think about it. I think it comes mostly from the way
[people ended up being very focused some of the pictures taken that day clearly show that](http://www.flickr.com/photos/vizzzion/sets/72157624950127005/with/5047791559/ "Sebas' Solid Sprint Pictures").
Look at the people faces for some of those pictures, you can
clearly feel how concentrated they are.
Once the Exploration Phase was over, we were sitting on a large
pile of tasks... That's obviously solving one of the cardinal sins
I pointed out earlier. Thanks to the exploration, we have a clear
picture of what needs to be done at the very beginning of the
sprint. Now, we still need to process those tasks in a meaningful
way, and remember we basically can't estimate.
#### Introducing the Kanban
Since we can't estimate (remember the other cardinal sins above),
and that we're in the unknown regarding the amount of work the team
can do during the *Developers Sprint*, we're then in the situation
where we want to maximize the throughput of the team. No matter how
much they achieve in the end, what matters is that they were
running at full speed (in other words: sprinting). That's why we
introduced a Kanban, it's the best tool I know for such a
situation. It comes from the Lean approach, and Scrum practitioners
tend to give it a close look these days, some are even talking
about "Scrum-ban", some hybrid between a Kanban and the usual Scrum
task board.
Anyway, our implementation of the Kanban was very low tech: a
whiteboard, plenty of sticky note, a couple of pens, a marker. No
need for anything fancy or expensive. We used the colors of the
sticky notes to give us a nice visual feedback on the type of
tasks: yellow for the regular ones, pink for the urgent ones, green
for the non technical ones (like writing a blog, documentation,
etc.). We regularly took pictures of its state for reference
purpose and blog, you can see the
[final state of our Kanban](http://www.flickr.com/photos/vizzzion/5048389060/in/set-72157624950127005/ "Solid Sprint 2010 Kanban in Final state")
online.
The Kanban itself was divided in three areas: *Waiting*,
*In Progress*, *Done*.
- In the *Waiting* area one could find all the tasks known for
the sprint. When someone was done with a task, he would turn to the
*Waiting* area to pick a new one;
- tasks picked from the *Waiting* area would end up in the
*In Progress* area you could see at a glance all the task which
were worked on by the other members of team, good way to take the
pulse of the project;
- when a task was done, it was moved to the *Done* area.
There was two ways to complete a task in order to move it to the
*Done* area. Either it was fine grained enough and then you just
had to implement/write what was required (roughly an hour of work
maximum) in order to consider it done. Or, it was too big and
abstract, in which case completing it meant: analyze it, do some
preparatory work to actually split it into smaller tasks added to
the *Waiting* area. In such a case it could be a good idea (even
though not mandatory) to add a small note to the original task
explaining that it got split further.
As you can clearly see from the description already, using this
system gave a lot of transparency about what was going on during
the sprint. Everyone could all the time check what was worked on,
how much was left, what was already achieved, etc. It also came in
very handy during the regular wrap up sessions we had. One could
just go through the *Done* area to remember all the tasks he worked
on, and then provide details about the outcomes, the problems to
implement the task, etc.
#### Raising the bus number through Pair Programming
Instead of implementing the complete Kanban model (which would, for
instance, limit the number of items in the *In Progress* area), we
tried to regulate the flow by another mean: Pair Programming. By
asking people to work in pairs, we were trying to indirectly limit
the amount of tasks which could be in the *In Progress* area.
The reason of this trick was that in the case of the Solid Sprint,
we try to blend more and more what used to be scattered teams. Pair
Programming is a good way to give the feeling of a single team and
to improve the knowledge sharing inside of this team. This way you
can effectively raise the so called bus number of the team. That's
definitely critical in a community based environment building on
the work of volunteers who sometimes drop unexpectedly.
### Where we could improve the model ([Kaizen](http://en.wikipedia.org/wiki/Kaizen "Kaizen"))
In short: re-introduce more of the Kanban features. For this first
experiment, I think we slightly oversimplified the model, removing
some of the constraints of the Kanban. We tried to hide the
slightly more rigid structure of the Kanban through an external
constraint of the type: "work in pairs as much as possible".
Sounded like a good idea, except that this kind of discipline is
just extremely hard to acquire alone or by being told. On the other
hand, modifying the rules of the game can gently push you in the
right direction.
And indeed, the Kanban provides us with the necessary rules: you're
supposed to cap the maximum number of tasks in the *In Progress*
area for instance. Make that number slightly below the number of
participants, and you should see people pairing more often. It
honestly sounds a bit harsh put this way, but that's likely a good
temporary measure to give a taste of Pair Programming in a team.
Another potential improvement we could have used during the Solid
developers sprint was to split the *Waiting* area into *Waiting*
and *Selected*. Again, the number of tasks in the *Selected* area
needs to be caped (generally at a somewhat low number). Then
someone would have to be responsible into making sure that the
*Selected* area is always full. By doing so we'd achieve two
things:
1. the developers would have to pick tasks which are not directly
in their core domain (stimulates even more collaboration among the
team and then cross-pollination... it basically puts the Pair
Programming on steroids);
2. the person in charge of the *Selected* area could influence the
priorities of what is achieved during the sprint (of course, that
puts quite some constraints on the person, in our context that has
to be someone with a good overview of the project, and enough
empathy to actually make sure people keep having fun during the
sprint).
Last but not least, the task splitting during the Exploration Phase
could have been a bit better. I was basically monitoring the
discussions and adding new task on the board each time I caught
something which looked like an action item. I had to proceed this
way because at that time I didn't introduce the Kanban to the team
yet (not to scare them away to early ;-)), but as a downside I
probably missed a few tasks in the process or introduced some tasks
which still needed to be refined. Next time, we should make sure it
is the person bringing the discussion who adds the tasks to the
board. By doing it this way the discussion will naturally flow
toward this task splitting.
### Conclusion
I think this Solid Developers Sprint 2010 was quite different from
some of the other *Developers Sprints* we (KDE) had in the past. It
really gave a pace to the whole team, and improved the transparency
within the team. As a consequence, it improved the cohesion as
everyone could easily know what was going on and exercise their
curiosity.
Of course, it was not perfect either, and I highlighted in this
essay what we could do better. I'll very likely experiment those
improvements the next time I have an opportunity. In particular I'm
looking forward to stimulating even more team cohesion, we're
sitting on a tremendous potential here, let's turn it into an
asset!
PS: If you read until this point: thank you and congratulation! I
hope you found this (somewhat) short essay at least a bit
interesting. Feedback, questions and comments are welcome.
This post is the first one out of two covering my thoughts about
the Solid Developers Sprint 2010 which happened this week-end. My
outbound flight being delayed, I've plenty of time for
introspection in the Madrid airport. :-)
Some of the fearless developers working on the Solid project in the
KDE community (calling themselves Metalworkers) gathered the past
week-end for a developers sprint. Surprisingly, it's the first time
that we had a sprint centered on the Solid effort.
The emergence of the need for such a sprint is actually a very
healthy sign. We moved away from Solid being mostly a one man show
with a couple of satellite components (again each time managed by a
single person), to Solid being really a sub-community of the larger
KDE community. Now, you can clearly feel several teams
collaborating and slowly blending into a coherent whole. This
movement started probably around the end of 2009, and is having now
enough momentum to produce results and impact the structure of the
community.
This sprint then became a possibility to boost this process and
tighten the bonds between the Metalworkers (the fact that we now
have a name we find fun and are proud to use tells a thing or two).
I think it was a success in this regard, a lot got achieved,
everyone sharing a common flame and motivation to push further to
get results. Talking about results we had a lot of them:
- a refactored KDE Power Management daemon (completely
componentized);
- preliminary version of an asynchronous API for device listing
(leaning toward dynamic lists);
- our network stack integrates with the bluetooth stack;
- improved compatibility with more device in our bluetooth stack;
- a brand new connection wizard;
- the new set of backends for libsolid reaching feature
completion for daily use (it's now realistic to see them become
default for 4.6);
- libsolidcontrol deprecation progressed quite a lot;
- and of course a lot of general bugfixing, polishing, etc. I
just highlighted in this list the (IMHO) biggest achievement.
It was hectic, to the point that the main day of the event
basically seemed to never end... for most of us it lasted 19 hours
straight! We only stopped in the evening to have a break for a team
dinner, but apart from that we hacked furiously.
Of course, when you spend 19 hours at the same place than a bunch
of other hackers, you'd better be in good company. And luckily
Metalworkers are kind and nice people. I'll never get enough of
them (in no particular order):
[Sebas](http://www.flickr.com/photos/vizzzion/5042131539/in/set-72157624950127005/ "Sebastian Kugler"),
[Alex](http://www.flickr.com/photos/vizzzion/5042737680/in/set-72157624950127005/ "Alex Fiestas"),
[Lamarque](http://www.flickr.com/photos/vizzzion/5042758864/in/set-72157624950127005/ "Lamarque Vieira Souza"),
[Rafael](http://www.flickr.com/photos/vizzzion/5042125459/in/set-72157624950127005/ "Rafael Fernandez Lopez"),
[Dario](http://www.flickr.com/photos/vizzzion/5042120429/in/set-72157624950127005/ "Dario Freddi")
and
[Will](http://www.flickr.com/photos/vizzzion/5042126603/in/set-72157624950127005/ "Will Stephenson").
We even had extra guests.
[Agustin](http://www.flickr.com/photos/vizzzion/5042116719/in/set-72157624950127005/ "Agustin Benito Bethencourt"),
Albert and Javier that maybe we can turn up in regular
Metalworkers. But also Will's wife and daughter. The baby girl even
showed how proud she was of her father. She's too young for now,
but
[she made a statement: she's almost ready to follow Will's involvement](http://www.flickr.com/photos/vizzzion/5048398208/in/set-72157624950127005/ "Too small for SOLIDs").
Obvious absents were Lukas, Mario, Michael and Paulo who are among
the latest to join our team. Unfortunately, they couldn't attend
this time for various reasons. Hopefully next time!
Last but not least, I'd like to thank
[Interdominios](http://www.interdominios.com "Interdominios") and
[UFO Coders](http://www.ufocoders.com "UFO Coders") who hosted and
organized this developers sprint. They did a great job at keeping
us comfortable, and provided a top notch work environment (being
able to use almost
[any surface as whiteboards](http://www.flickr.com/photos/vizzzion/5042757508/in/set-72157624950127005/ "Yes, that's a wall and a door")
was really amazing, war room at its best). It's definitely on my
Top 3 list for sprint venues. Also a big "thank you" to the
[KDE e.V.](http://ev.kde.org "KDE e.V.") and our sponsors
([organizations](http://ev.kde.org/supporting-members.php "KDE e.V. Supporting Members")
and [individuals](http://jointhegame.kde.org "Join the Game"))
without which those kind of events would be much more difficult to
fund and organize!
PS: We definitively need a catchy name for the Solid Developers
Sprints, after all our beloved Plasmoids have Tokamaks. I wonder
how we could name the corresponding events for us, Metalworkers.
;-)
I'm back from Milano. The first Plasma sprint has been a pretty
good event. My only regret is the low productivity on the first day
since we spent quite some time hunting for food. But once we found
the right balance, the productivity just got through the roof and
we got an humongous amount of things done (as the current activity
in the repository proves).
I'd like to thank everyone involved in this sprint, we really
formed a great bunch, that's nice to be able to get things done and
make new friends at the same time. A special thanks for Richard
Moore, without him I'm not sure we would have seen the end of the
API review. Also I'm really looking forward to collaborating with
the [JOLIE](http://jolie.sourceforge.net) developers, it'll
probably cover all our current Web Services needs.
Also congratulations to Alexis who led the effort to make WoC
finally happen in Plasma, and to Sebas who did a humongous job in
this area too. Yet another important piece of the Plasma project
finally done.
And now preparing for departure again, I'm going to
[FISL 9.0](http://fisl.softwarelivre.org/9.0/www/) where I'll give
a tutorial about developing applications with Qt and KDE. I
probably still have to rework a bit my slides to fit the target
audience and the time slot. I still have to pack too...
Tuesday and wednesday were basically spent doing API review and
refactoring the public API to address the issues found. It's great
to get input from people experts in the field... After all their
work on Qt proves they have a lot of expertise in making APIs which
rock.
That's why Solid is getting get a big facelift during this week.
I'm cleaning it up at a lot of places, and had to refactor the
internal API a bit. Hopefully now the most intrusive changes for
the hardware discovery part are done. It's kind of frustrating
because I'd basically like to see this week last for a month. I
opened the eyes in quite some shortcomings, and we probably won't
have the time to make a second round of API reviews.
So... Let's get the most of this week! Back on furious hacking!
As usual started with a very early flight. I had to woke up at 4:30
this morning to get it... No need to say I'm pretty tired while
writing this. Of course I'm also pretty excited, which explains
that despite being exhausted I'm hacking at... the
[Trolltech](http://www.trolltech.com) offices in Oslo. Today being
the first day of a 5 days long sprint about
[Phonon](http://phonon.kde.org) and [Solid](http://solid.kde.org).
It's always nice to meet old friends and new faces. The Trolltech
guys form a very friendly group.
Today, we basically travelled, setup our small network for the
sprint and had discussions about investigations and work for this
week. It already looks like it can become a highly productive week.
After this nice kick-off we gathered in a very nice restaurant in
Oslo with a few trolls. The food was just wonderful, and it was
very cheap (in particular compared to Oslo standards).
This night we finished the work on factoring XMLGUI out of
KMainWindow with Simon. It's now in trunk, so now we can
concentrate on the main purpose of this sprint...
Thanks a lot to the Trolltech people to allow this sprint to take
place.
Yesterday night and today, I got back on porting and bugfixing
mode. We've still some work to do to have everything ported to
D-Bus so everybody is participating to this on going effort. I
finally spotted a bug in kpersonalizer that made your session turn
black... so now you can actually see the content of your windows.
;-)
Today, we started to see a few boxes having KDE 4 sessions running
decently: kicker, kdesktop, konsole, kwrite... are running.
Konqueror can be started by hand, but it still requires some work
to make it launchable from the menu and kicker again. Of course
it's still rough on the edges, but that's really nice to see all
this running again after so many changes and refactoring. We've
still so much to do, but the improvements made in the last few days
are really motivating.
Just like yesterday, we had a truely nice lunch. It was prepared
with love by Will, great coder, awesome cook. Thanks a lot Will!
This evening, we're all hacking as usual. But it seems that today
we have quite a concentration of "hackers on a couch".
After all it's a really nice place to hack, why not using it. ;-)
Today, I finally committed the last part of my job refactoring in
KDE. We'll finally have jobs usable accross KDE application without
being tied to KIO. Moreover thanks to the UI delegate I introduced,
the dependency on GUI is now optional. It can even be used to have
several representations possible for a set of job. A UI Delegate
for the command line, one for classical dialogs, one to publish job
progresses in a Plasma message area.
Today meals were truely nice. For lunch, Will took the initiative
to make pastas for everybody. Thanks a lot Will! For dinner the
catering service provided us tons of food again. Almost no meat
which is a nice thing for the vegetarians here... we don't want
them to starve. ;-)
This evening a big part of the
[Trysil](http://dot.kde.org/1151271635/) team is watching the World
Cup:
As you might have noticed, there's one person really concentrated
in front of the TV. Ok, let's zoom in, see how Laurent is highly
motivated by the french team:
Ok, skipped one day... time to blog again. ;-)
Yesterday, everybody worked hard. I spent quite some time working
on splitting useful GUI related code outside of KIO. This way it'll
be reusable for other frameworks like Akonadi or Solid. It's a big
chunk of work, so it was far from finished but I decide to go to
bed early.
Hence why today morning I managed to wake up earlier... And caught
up Harald when he was trying to wake up:
Cute, isn't it? =)
During the whole day, I continued my work with jobs and kio, the
first phase of the changes is almost ready to commit. I've been
stopped mostly by only two events: a group meeting (will probably
end up as a proposal on k-c-d), and lunch. Hmmmm, Lunch! We had a
BBQ, it was just perfect! Thanks to Marius for managing this so
well.
George and Celeste arrived this afternoon, it's nice to see them
around again. We're almost all there, only Till is missing, but
he's supposed to arrive later tonight.
This evening the german team is playing in the world cup. That's
why we're facing a strange phenomenon, it started with coolo, but
people here are infected by a german fever:
Gooood evening Planet KDEEEE!
Woke up a bit late today, well that's understandable since I got to
sleep at almost 4am. On the other hand, when I left kdelibs was
able to compile so it was worth it. ;-)
Today I basically worked on the kdelibs and kdebase stabilization.
Now that we're moving them to Qt 4.2 we have a few things to fix.
We're slowling getting there, hopefully tomorrow the situation will
be ok there.
During the afternoon, we made a break to have a walk around the
area. It's really a beautiful place, we stopped at a swampy field
where we made a group photo:
Actually, what you're seeing above is the second try... For the
first take I had Aaron in all his glory:
See you later, I'm going back to kdebase porting.
Hello from [Trysil](http://dot.kde.org/1151271635/), Norway!
I finally arrived in Norway. No real event disturbed the trip,
which is always good even if a bit boring. I met for the first time
Alexander Neundorf and Tobias Koenig in Oslo airport. Nice to meet
you guys.
We found our way to the bus. While we were waiting for it Allan
Sandfeld arrived too... he was supposed to take the next bus, but
since it would have required him to wait for two hours he took the
same than us. Our bus was really full of people and we had the nice
surprise to find Zack Rusin and Marius Monsen in it.
After a three hours trip by bus, we reached the cabin... It's...
well... GREAT(tm). A picture says it all, here is the view we have
outside:
And inside it's cosy. Since we have a TV, a few hackers here
watched a soccer world cup match:
I'm really glad to be here, the next coming week will surely be
terrific. All the conditions are met to make us very productive!
