[](http://ervin.smugmug.com/Events/Forge-2011-Madrid/19455801_Sk5GZ5#1522274978_wfsbc3S)
From September 29th to October 2nd, we had the yearly developer gathering of
the Solid team in Madrid named Forge 2011. It's the perfect opportunity for
metalworkers to meet and make plans for the year to come.
This year was especially interesting because we had an usability expert on
board which is a good thing for us metalworkers. We spend most of the time
stuck in the middleware, but we also end up integration and presenting our
work in the workspace where it should be easy and pleasant to use. I'll cover
that aspect in more details in a another post.
We also took some time to record a few videos, mainly a demo of a new feature
and a couple of interviews with key people. Took me some time to put everything
together, but it's now in a state where I can share them!
# Dario on Power Management and Multi-Screen
In this video Dario shows a nice new feature implemented thanks to the
collaboration between power management and the multi-screen support. This
way we can put in place refined policies on when to suspend or not.
(if you cannot see the embed, direct link to video for you)
# Björn about Usability
In this video, Björn Balazs our resident usability person for the sprint
talks about his job and what he worked on during the sprint.
(if you cannot see the embed, direct link to video for you)
# Lamarque about Network Management
In this video, Lamarque Souza covers the work started during the sprint
to revamp the network management support in the workspace. We also learn
a bit more from his early KDE involvement.
(if you cannot see the embed, direct link to video for you)
# Dario on Power Management
In this video, Dario explains the history of power management support in our
workspaces. He covers quickly the past and gives us more clues about what is
about to land in the next release. He also talks about his take on the
interesting innovations in the community.
PS: And yes, Dario is very tired in this video. We had to charge the battery of
the camera, it went empty during the first take. So yeah, he actually meant
"4.10" there's no plan for a "5.0" workspace yet. ;-)
(if you cannot see the embed, direct link to video for you)
# Alex on being the New Solid Maintainer
In this last interview, featuring Alex host of the sprint and new Solid
maintainer, I had to step up and be in front of the camera to conduct the
interview... It was the last one, probably around 3 or 4 in the morning...
(if you cannot see the embed, direct link to video for you)
# B-Side! What Happened Behind the Scene...
And last but not least, I kept quite a lot of the rushes and failed attempts.
So I also put together a "B-Side" for the videos so that you can also witness
the nice atmosphere we had during the sprint!
(if you cannot see the embed, direct link to video for you)
PS: I think there's a bit of the video which might not be clear, so I'll give
a few words of explanation. When the red circle and arrow appear, look very
closely in the circle. I'm actually crawling behind the couch to retrieve
the remote control of the TV... I'm totally in stealth mode! Except that you
can briefly see my hand which totally killed Alex's concentration. Apparently
it looked like the Thing in the Addams Family. If you couldn't see it watch
again, veeery closely, it's furtive! :-)
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.
;-)
Just like the fellow gearheads who already published this kind of
blog, I'd like to claim that, yes!
[](http://akademy2010.kde.org)
This year I will be spread on several fronts (like every years in
fact), but you will for sure meet me during the following events:
- My
[talk about KDE Mobile](http://akademy2010.kde.org/node/433 "Kevin Ottens, Akademy 2010 talk, KDE Mobile"),
which will happen on saturday afternoon;
- The
[KDE Mobile BoF](http://techbase.kde.org/Projects/Mobile/Meetings/Akademy2010 "Akademy 2010, KDE Mobile BoF")
which I will be moderating, people willing to discuss the future of
the KDE Platform and how to contribute more to the the Maemo /
MeeGo ecosystem;
- The
[Solid BoFs](http://techbase.kde.org/Projects/Solid/Meetings/Akademy2010 "Akademy 2010, Solid BoFs")
where I'll meet my fellow metalworkers, strengthening our plans for
4.6; note the plural there, there will be two of such meetings
(because some people will attend remotely, and then because of
timezone constraints).
Apart from those three events, I'll run around as usual, probably
trying to poke a bit the Plasma people as well or furiously hacking
somewhere.
Looking forward to meeting you all!
Since even before the start of Tokamak4, it has been pitched as a
"three in one" sprint. But that was without counting on the Solid
people. In the great tradition of hardware awareness in KDE, we're
doing our job correctly only if Solid gets unnoticed by the user...
and nobody noticed that almost all the core "metalworkers" were
attending Tokamak4.
So we used the opportunity to have a Solid meeting to summarize the
current situation of our infrastructure, and to make plans for
2010. That includes quite a few of clean ups on our stack, but also
more ambitious and cool stuff like reporting devices reachable via
the network. If you're interested in details, I sent
[a mail summarizing the Solid meeting at Tokamak4](http://mail.kde.org/pipermail/kde-hardware-devel/2010-February/000701.html),
and you should probably
[subscribe to kde-hardware-devel](https://mail.kde.org/mailman/listinfo/kde-hardware-devel)
if you're not there yet.
Damn! I didn't even finish my blogging about the Oslo sprint... so
much stuff to do. Well, I'll probably make another post about it,
more focused on the results we obtained regarding
[Solid](http://solid.kde.org) and what I learned there (in short: a
lot!).
The three weeks which followed were quite exhausting. First just
after the Oslo sprint, we still had quite some work to finish the
required refactoring in time for the freeze on the 1st May. But we
managed to merge the branch, do the work and have it working for
the Alpha1. So you'll get nice Solid and Phonon with kdelibs 4.0
Alpha1. There's probably a couple of cleanups to do until the 4.0
release, but nothing huge. In my opinion, the APIs matured quite a
bit thanks to the trolls expertise. Once again it proves that when
you work next to other people next door you can achieve far more in
less time. We should really keep in mind that more sprints are good
for the project!
After that I spent most of my time on my PhD... My life was the one
of a monomaniac: sleep, eat, write, sleep eat write, etc. But now I
have issued the first draft of my PhD thesis! Was hard but worth
it, there's only half a chapter missing because I'm waiting for
someone else data. That's just nice to finally see something that
looks like a thesis, not a bunch of notes and files scattered on my
disks. It's now in the lab for internal review. When it'll be done
I'll write the missing bit (hopefully it should be straightforward)
and be able to enter the official review process... and maybe get
my diploma. That's still a few months away though, since because of
the length of the review process and the summer coming the
(potential) diploma won't be delivered before september or october.
Administration takes holidays very seriously here. :-)
And now? Well, I'm going to travel again! Actually I noticed that
I'm only spending two or three weeks at home between my trips this
year... It's going to last like this until
[aKademy](http://akademy.kde.org). But, the coming trip has
something special, I'll be on the other side of the globe this
time, the first time I go that far. I got a paper accepted to
[AAMAS 2007](http://www.aamas2007.org) and since I'll attend
tomorrow morning I'll travel to
[Honolulu](http://en.wikipedia.org/wiki/Honolulu) by plane.
Since I'm staying longer
[for](http://en.wikipedia.org/wiki/Image:Oahu_from_air2.jpg)
[obvious](http://en.wikipedia.org/wiki/Image:Oahu_windward_side_beach.jpg)
[reasons](http://en.wikipedia.org/wiki/Image:Valley_Oahu.png), I'll
be back home in two weeks. I don't know since I'll probably have
trouble having internet access (depends a lot on the conference
organisation): see you in two weeks!
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.
*Yup, it somehow looks like a [famous Green Day song](http://en.wikipedia.org/wiki/Wake_Me_Up_When_September_Ends)...*
* * * * *
Akademy has come and passed
Ten days has gone so fast
Wake me up when october ends
Back in office again
Falling from the stars
Drenched in my work again
Becoming who we are
As my memory rests
But never forgets what I lost
Wake me up when october ends
Akademy has come and passed
Ten days has gone so fast
Wake me up when october ends
Wake me up when october ends
Wake me up when october ends
* * * * *
This lame attempt at borrowing a song lyrics for my own blog comes
from the fact that october is exhausting here... I've basically
been unable to do anything useful in the free software land since
the end of aKademy. Too much work both on the research and teaching
front. But it seems I survived once again. :-)
Hopefully starting this week-end my schedule will slowly come back
to it's normal state, so I'll have some spare time to spend. I
already sent a bunch of patches for HAL and committed some code
into [Solid](http://solid.kde.org). It feels good to be able to
work on this again!
Today we finally made the [Solid](http://solid.kde.org) libraries
enter kdelibs! That means that a most of the milestones of the
[roadmap](http://solid.kde.org/cms/1002) are done. Now it's mostly
about polishing, writing more backends, and making use of it in
applications. It couldn't have been achieved without the help of
Will Stephenson who
[mastered most of the network management classes](http://www.kdedevelopers.org/node/2409)
all by himself. I'd like also to thank Laurent Montel who gaves a
few advices related to the build system during the merge, and Dirk
Mueller who already made a few pedantic cleanups on the code base.
;-)
After this achievement, I finally took some time to walk downtown
with Peter. Dublin is really a nice city, I really enjoyed what I
saw. We passed by the Saint Andrew's Church which has an
interesting architecture. This church somehow summarize this town
quite well. It's very old, and that's what you notice first, but if
you come closer you'll see that on the inside it's been renovated
in a really modern way. Dublin is like this, it looks both old and
modern.
We stopped by the Saint Stephen's Green Park, walked a bit and sat
on a bench. It's a really nice a peaceful place. That's actually
interesting to look at people in this kind of place. Parents and
children playing together, couples walking, people simply
chatting... that's really refreshing. We're really lucky to have
the opportunity to appreciate moments like this. Interestingly, a
couple of elder people stopped by a bench next to the one we were
sitting and started to sing together. It sounded like a very old
and melancholic song. Precious moments...
After the successive refactorings of the next few days, it's time
to get ready for merging in kdelibs. So today I spent almost all my
time finishing the refactorings, documenting and reviewing the API.
In the meantime Will was working on the fake backend for network
management. I also gave a hand at it.
I took a break since API documenting can quickly become boring. And
I attended Sebas' BoF on marketing. Quite a few interesting
ideas...
Tomorrow we'll concentrate on unit tests. Once they are ready,
we'll finally be able to move Solid in kdelibs!
Mental note: I should really try to find some time to visit the
city center. I'll surely go with Ken and Peter tomorrow afternoon.
Already the second day of the coding marathon. I didn't attend many
BoF and talks this time. I concentrated much more on preparing
Solid to enter kdelibs. Not yet done, but we're coming closer.
Apart from this code work I took some time to attend the Qt
tutorial done by Mirko Böhm to Trinity students. Since I'm doing
something similar in my university I was trying to see if I could
find a few ideas to improve my own course material. ;-)
I also attended Mirko's BoF on multithreading and performances. It
raises a few interesting questions. Done right it could give a
boost to our application startup time and responsiveness. We
probably can find patterns to make implementing those concepts more
easily, it'll probably require some time to get it but that's for
the better.
A new day is now starting, see you later. Greetings from Dublin!
Today was the
[OpenDocument Day](http://conference2006.kde.org/codingmarathon/opendocumentday.php)
at aKademy. Very nice idea, it allowed a quite some people to get
in contact about this important topic.
I attended the lighting talks and breakout sessions. Lot of
interesting topics, but I won't enter in more details here, there
would be too much to write, and I'm a bit tired. ;-)
I made a break to attend the Strigi BoF. The design looks sane, its
main developer cares about resources. It seems that we have a
winner here. There's only a few things that I dislike about the
daemon part, in particular how the D-Bus support is implemented, it
seems to be too much effort for the tools we currently have. But
well that's nothing critical, really.
This break was in fact during lunch time... So I get back directly
to the lighting talks session of the OpenDocument Day. Luckily
Peter kept me some food, so I was able to have a lunch after all.
=)
During the breakout sessions I found some time to work on
[Solid](http://solid.kde.org) to prepare its merge in kdelibs, that
led me to some cleanup and refactoring. I'm waiting for the network
related parts to be ready and then the merge will occur.
The OpenDocument Day ended with a sponsored dinner for all the
attending people. Fine food and lot of talks... Once again a nice
way to end the day. ;-)
This week has also been interesting on the
[Solid](http://solid.kde.org) front. The API is slowly improving
(because of my limited spare time). And the day when we'll have all
the necessary classes and methods to port kio\_media on Solid will
surely come soon.
I'm currently implementing capabilities support, my primary targets
are of course the ones necessary to manage media. Hence why storage
and volume capabilities are half done. Even mount, unmount and
eject support are there.
As expected, I'm focusing on the HAL backend, which had an
interesting side-effect. This backend make an extensive use of our
upcoming DBUS binding and then strengthen it by providing uses
cases. For sure, it's for the better and Thiago is really helpful
in this area, I'm glad he maintains those bindings.
And before I forget, I'd like to point something new under the
Solid umbrella : solidshell. This new tool will allow to the most
important features of the framework from the command line. It
already allows to list devices and to display their properties.
Mount, unmount and eject are also provided.
During the following days/weeks I'll focus on polishing what is
currently there. After this (hopefully short) phase I'll introduce
more features again.
As the design and the code is slowly shaping up in KDE's
repository, I'm in the mood to make some noise. Yes, KDE 4 will
have yet another brand new framework:
[Solid](http://solid.kde.org). After
[Plasma](http://plasma.kde.org) and
[Oxygen](http://www.oxygen-icons.org) that will deal with fluidity
on the desktop, we're focusing on another state of matter because
in the end we have real devices to interact with.
[Solid](http://solid.kde.org) will be a way to finally make the
hardware and desktop applications work better together. First,
it'll be a middleware KDE applications will be able to use in order
to discover devices or networks available to the system. Second,
it'll deliver a Plasma engine, to easier desktop applets creation.
Third, it'll provide a knowledge base to add and consult devices
behavior reports. I think this last point will be interesting in
the long run, it'll be another way for the users to be involved by
updating it.
What will this all mean to the average user? A desktop that is more
robust and does more with the devices available. It'll also mean an
easier access to hardware features. Most of those changes will be
under the hood, but we expect some pretty neat new applications and
applets using them.
And, what will this all mean to the developer? It means that the
features provided by different platform will be streamlined while
portability is kept by implementing Solid backends (currently only
two backends are provided a
[HAL](http://freedesktop.org/wiki/Software_2fhal) one, and a fake
one allowing unit tests). It also means that all the building
blocks to deal with the hardware will be at hand, they just need to
be used.
A [new website](http://solid.kde.org) is around for this framework,
it looks similar to the [Plasma website](http://plasma.kde.org) and
that's perfectly intended since I consider both to be
complementary. They are the pieces of a same puzzle, and I'll do my
best to see them fit together perfectly.
Speaking of Plasma, it leads me to beauty. In this area
[pinheiro](http://pinheiro-kde.blogspot.com/) strikes again since
he designed the Solid logo. Moreover, the
[Oxygen](http://www.oxygen-icons.org) crew provided us two brand
new (and not seen before!) icons used on
[our website](http://solid.kde.org). Thanks a lot to our artists!
They do a marvelous job!
And Happy New Year Everybody!
