kdelibs splitting: looking back at april and going forward
ervin at kde.org
Sun May 6 15:48:18 UTC 2012
May is upon us, flowers are blooming, temperature is rising... time for
another quick recap on the progresses (or lack thereof) in the kdelibs
splitting department. I'll also present the revised backlog for May and
# What happened in April?
Unfortunately no split was completed in April. It mainly comes from less
availability of the volunteers for those splits than expected. But it has also
been caused by some disagreement showing up regarding the ongoing splitting of
big chunks of kdeui (basically a clash between the "let's make a try and
iterate" vs "let's decide on what to do of the classes and apply" approaches).
The real bad news is that it effectively turned down the people helping on
The good news is that we're now having the discussion on finding the
(hopefully) final splitting lines in kdeui. That works was done for kdecore in
Platform 11, but not really exhaustively for kdeui so far. Perhaps that'll
lead us to finally dealing with kdeui once and for all.
# What should happen in May?
So for May we'll try to keep the risk low: low number of splits, as remote
from kdeui as possible, preferrably already started. We're planning on three
splits to be completed in May:
* karchive, it's been long in the making, Mario is working on it and not much
is left to complete it;
* kconfig, David started the work on it already, it's somewhat independent
already, and Benjamin volunteered to finish it... we have no maintainer for it
* kidletime, the only one not started, somewhat independent though, Dario is
# Beyond May?
I used the opportunity of the April hiccup to rework the plans we had so far
for the splitting (already effective for May). We're going to have smaller
batches than previous months, which means the plan now goes all the way into
Also, I changed some of the ordering to have anything touching kdeui out of
the way until July. The frameworks planned for May and June have of course
some use of kdeui, but that should be minor and easily ported away (assuming I
didn't miss a critical dependency).
This way, the discussions over kdeui can occur in parallel without disrupting
or blocking the ongoing splits for the coming two months. The idea being to
nail down kdeui splitting in July. I think it'll be the perfect time for that
as: a) two months should be far enough to agree on the splitting lines and b)
beginning of July will see Akademy, it'll be the perfect time to frantically
hack the kdeui splitting and make it real.
# Maintainers (still) needed.
We have no known maintainers for the future frameworks to be processed apart
from plasma, karchive, kbookmarks, kidletime and kio*.
Short term I think I'll simply remove the "have a maintainer" constraint from
the definition of done of a split as it obviously seems to not be a good
representation of a split anyway (I introduced it as a mean to push for
volunteers but the effect seems to be disappearning now). Anyone disagreeing
with that change?
Longer term, it is a rather concerning prospect IMO. We must find a solution
for that sooner rather than later to avoid a big batch of frameworks with no
maintainers. Ideas are very welcome in that department...
I'd like to note however that it's not really a new situation. Some of you
might remember I mentionned for a while that we operate on the "dfaure as
default maintainer" scheme... I still think it's unhealthy, but the splitting
work makes it more visible.
Feedback welcome as usual.
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Kde-frameworks-devel