kdelibs splitting: looking back at april and going forward

[Kevin Ottens]

Hello,

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 
following months.



# 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 
kdeui.

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 
though;
 * kidletime, the only one not started, somewhat independent though, Dario is 
the maintainer.



# 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 
November now.

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.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120506/5dfcef05/attachment.sig>
-------------- next part --------------
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel at kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel