kdelibs splitting: looking back at april and going forward

[Stephen Kelly]

Kevin Ottens wrote:

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

For those who don't know (kcd, presumably), apart from splits, there was a 
lot of stuff that did get done:

* Porting away from obsolete stuff to Qt stuff for example. That's the work 
that makes splits possible. For example, porting from K_GLOBAL_STATIC to 
Q_GLOBAL_STATIC, KListWidget to QListWidget, KProgressDialog to 
QProgressDialogm, KUrl to QUrl etc.
* Ongoing porting to (the still somewhat moving target) Qt 5.
* Work on installation. We can build kdepimlibs, kdepim[*], kde-baseapps, 
kde-workspace, kde-runtime and calligra against an installed kf5 (with some 
porting patches)
* I started some work on porting scripts that can be used by applications 
porting to Qt 5/KF5.

[*] When I ported kdepim and started some applications, it was a few minutes 
later when I realized that I hadn't ported kdepim-runtime, so I was using 
the kdelibs4 versions of my akonadi resources with my kf5 based applications 
:).

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

Yes, I expect so.

> # 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 guess we don't have much choice but to wait until KDE developers take 
notice of Qt5/KF5, test their application and fix whatever is broken in the 
frameworks they use.

I don't disagree with dropping the maintainer requirement to consider a 
framework done.

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

Yes. Hopefully also more managable though.

> 
> 
> Feedback welcome as usual.

Thanks,

Steve.