kdelibs splitting: April iteration

[Kevin Ottens]

Hello,

On Tuesday 3 April 2012 16:16:16 Stephen Kelly wrote:
> Kevin Ottens wrote:
> > [...]
> >  * kitemviews: Stephen Kelly;
> 
> Most of what I wrote that used to be in there has already been moved to
> tier1/itemmodels. Of what remains, the stuff that I wrote will have to move
> to a tier4 level, and the rest was written by ereslibre. Is he still around
> to maintain that stuff? I don't think I want to.

AFAIK ereslibre isn't around anymore. Can you work at least on the split? 
Means we'll have to find another maintainer though.

> > If anyone sees a problem with those goals for April (apart from the points
> > I address later on in this email), please speak now!
> 
> I'm not sure you're progress tracking is using the right metrics and working
> towords the right goals. You're TODO lists are aiming at finished
> frameworks,

Well, the list of the kdelibs splitting page aims at *splitted* frameworks. 
They don't need to be completely finished (kwindowsystem is not for instance, 
there's a port to xcb going on). The checklist was originally focusing on 
splitting only (roughly buildsystem adjustement, source compatibility warning 
and enforcing policies), now I admit a couple of extra things (like Q_WS* 
cleanups) crept up which maybe shouldn't be there.

> but I rather think we should focus on the intermediate goals
> which enable those final goals. We should focus on the horizontal struts
> that tie otherwise unrelated code in kdelibs together (and
> interdependencies).

That's what "kdelibs cleanups" (I don't like the name though) is intended for.
http://community.kde.org/Frameworks/Epics/kdelibs_cleanups

That's an extra dimension, so tracked separately although of course there's 
ties between both the splits and the cleanups (just like with the Qt 5.x 
tasks, the cmake ones, etc. it's never perfectly orthogonal).

Now to be honest I think we shouldn't focus more on one than the other. That 
said I probably did a crappy job at advertising the cleanup tasks indeed. It's 
partly because it's easier to me to advertise the splits and because initially 
it was mostly what the discussions were bearing (started in inner circles so 
the cleanups were considered a "given" from people with a kdelibs track 
record)... that's why the page itself appeared only later, we figured out it 
was missing just before the first volunteer day.

> I'm thinking of intermediate goals like:
> 
> * Removing the use of classes that we no longer really need to have (eg
> KPushButton, more on that below),
> * Porting from K_GLOBAL_STATIC to Q_GLOBAL_STATIC (the Q_GLOBAL_STATIC which
> will be in Qt 5.1 will have the same API as the one which is in Qt4 - we
> can port the actual code now. If the Qt 5.1 API is a bit different, there
> will need to be a script to port Qt anyway, and we can use the same script
> to port in kdelibs if we port to the existing API now),
> * Porting from KGlobal::locale to KLocale::global, etc,
> * After the above, removing kglobal.h from files where it is no longer used
> (simplifying the task of creating a framework for the people who don't
> realize that that needs to be done, and reducing the build fixes that are
> required because they don't do a clean build after moving stuff around and
> changing include_directories)
> * Actioning the tasks jlayt has listed regarding the future of KLocale
> (http://community.kde.org/KDE_Core/KLocale/Frameworks)

Pretty please add those tasks to the page mentionned above.

> * Look into K-classes where Q classes exist, find out why the K-class
> exists, find out if the K-features are actually used, decide if it should
> remain, or be renamed to something more appropriate, document that in the
> wiki, and what changes in Qt are required, and/or make the changes. That is,
> investigate, decide, document and do. The result of such a TODO would
> either be documenting what should happen with a class, or doing it.

For this one, I'm pondering between either having it in the Qt 5.x pages or 
start a new epic page just for it. Early on, we had those cases in the Qt 5.x 
pages (KSaveFile was tracked there for instance). I'd say we'd need to produce 
the list of relevant K-classes first. Depending on how long it is, it probably 
makes sense to have a specific page for it. Any taker for producing said list?

> The one
> line per class we have in the spreadsheet isn't complete enough, and
> doesn't focus on the K-classes where a Q-class exists, but lists all
> classes and is therefore not as focussed.

Agreed.

> There are probably less than 10 items that would need to be on this list.
> There was some effort on the KAction stuff, but I'm not sure the
> investigation took the right direction.
> I'd have to look again.

Not sure the list would be that small. We'll see. And yes, I think Valentin 
needs help on the KAction front.

> > # Why is the list large this month?
> > As I pointed out, the list for this month is somewhat large, it contains
> > 10 frameworks in total! I've been wondering if I should postpone some of
> > 
> > the frameworks then and decided against for the following reasons:
> >  * karchive, kaction, kguiaddons, kwidgets and kcolorwidgets got already
> > 
> > started in the previous months and are close to be done anyway, so it's
> > really just a matter of the people involved to not disappear and complete
> > the work;
> 
> I looked through one of the branches a few weeks ago (the one that starts
> off moving colors stuff, then icons, kdialogs and kpushbutton etc), and have
> a rebased copy of it locally.
> 
> I think it takes the wrong approach to how we should process code that is
> not yet in a framework.
> 
> It's a lot of moving files around, and it seems that after some files were
> moved around, some other files were noticed as dependencies, so they were
> then moved too. There doesn't seem to have been any questioning of 'should
> this class even still exist anymore', with the exception of porting
> KColorDialog away from KHBox (which I have just cherry-picked into
> frameworks).

Yes, that's exactly what happened. And that's perfectly understandable why, we 
got two nice motivated persons with no prior kdelibs experience so they hack 
and slash. That helps a lot to make progress, but that also mean they need 
help and guidance, which they didn't really get so far.

IMHO the crux of the issue here is that we lack involvement on helping new 
people getting up to speed.

> For example, KDialog was pulled in because the color dialogs use KDialog
> presumably. I don't know if KDialog should still exist, but in a later patch
> KPushButton was pulled in too, presumably because KDialog uses KPushButton.
> One of the problem is that the patches are upside-down (If KPushButton is a
> dependency, it should be moved before KDialog), but actually I don't think
> KPushButton needs to exist at all anymore.
> 
> If there is concensus on that, the code which is to be moved should instead
> first be ported away from KPushButton before being moved to a framework.
>
> The reasons I don't think KPushButton needs to exist are:
> [...]

Agreed with all of that.

> We shouldn't put items of 'splitting frameworks out' onto our TODO list, but
> rather things I have listed in this email IMO. The problem with splitting
> frameworks out is that it's harder than the things I have listed here.
> People don't know how to do it, as evidenced by the commits in the
> branches, which is of course understandable. It requires knowledge of
> CMake, what include directories are, what exports and export macros are,
> what linking is, etc. I think splitting (a vertical orientated task) is
> more difficult than decoupling (a horizontal task), and so we shouldn't ask
> newbies to do splitting. It's more frustrating and mysterious than it needs
> to be I think.

=> kdelibs cleanup page, then let's advertise it more

And I still don't think we should postpone the splitting to ensure all the 
cleanups are done. But someone working on a split should definitely look at 
what's blocking for the split dependency why, and if that matches a cleanup 
proceed with it. Most of the time (apart in kdeui in fact), there's only a 
couple such blockers. And initially, we found some of those issues *because* 
we attempted a split. For instance, KSaveFile was totally overlooked before we 
tried to split karchive, going through all our classes manually only just 
doesn't work.

Now, maybe we shouldn't have allowed newcomers to make split... but a) 
allowing them to do so fostered quite some progress even though it's far from 
perfect and b) we have a clear lack of potential maintainers for the upcoming 
frameworks, pushing newcomers away isn't going to help and will ultimately 
lead to stagnation.

> > # RFC: rebase frameworks-kactions and frameworks-kcolors branches
> > The work on kaction, kguiaddons, kwidgets and kcolorwidgets is for now
> > happening in two separate branches. I think that was a good move at the
> > time to get Giorgos and Antonis up to speed. But now that they are in a
> > somewhat good shape (only kdeguiaddons seem to need some renaming at that
> > point), it's probably time to rebase them on top of the frameworks branch
> > and kill them to give more exposure to that work. Any opinion?
> 
> Maybe. I'd like to finalize some of the decisions around KPushButton,
> KGuiItem, KDialog etc first and get those changes into the frameworks
> branch, then it will be easier to rebase those branches, and it will be
> easier to define why the split-out framework exists.

Looks fair indeed. This should be made a goal to settle on that fairly quickly 
though (not necessarily have the work done on all of them, but know what the 
solution is on most of them). It can't be lingering for too long.

> I think for any class that we're putting into a framework, we should be able
> to answer the question 'Why would a developer using Qt use this class?'.
> For KPushButton I think the closest answer might be 'If he's using KAuth',
> but it needs to be more fully investigated.
> 
> For the icons stuff, I think there should be some renaming. The engine class
> there is an implementation of QIconEngine which loads icons from an Xdg
> theme, right? So it should be KXdgIconEngine. The answer to the question of
> why use it would then be 'Use it if you want to be able to load themes
> which follow the xdg icon spec', if the engine is generic enough for
> that...
> 
> I can also see a reason for the color widgets to exist in a framework.
> 
> I don't like that kwindowsystem was pulled in as a dependency into that
> framework though. It's not clear from the history why that was needed. This
> is also something that should be investigated, rather than simply pulled in
> as a dependency. Frameworks is largely about breaking up interdependencies
> where they are not really needed, so simply pulling all additional
> dependencies when doing splits isn't really productive towards that goal.

Yes, same issue than pointed out earlier, provide help.

I get an overall uneasy feeling with some of the points you're making in this 
email BTW. You took the time to look into kcolorwidgets and spot the 
depencendy to kwindowsystem. Then to send an email pointing out it's wrong. 
This dependency is here for a single call. If we cumulate the time you took 
and the one I'm taking to reply it'd be fixed already.

Of course that doesn't rule out that you're making very good points here, but 
I'd rather see us be proactive in fixing this kind of problems when we see 
them arise than engaging in meta-discussions.

To summarize my point:
 * You think we miss tracking for the K-classes? Very good point, put them in 
the wiki and notify people it's there;
 * You think a small dependency isn't right? Good you saw it, fix it and 
CCMAIL;
 * This way we can collectively improve if people lead by example and show how 
they do it.

And of course larger issues needs to be discussed accordyingly, but when 
there's an obvious action, let's seize it. The team is small enough that we 
can afford that.

> On the subject of kwindowsystem, I saw it was moved out of staging. Given
> that it doesn't work with Qt 5, I think it should still be in staging.
> Moving to a tier should indicate that a framework is 'done done' at least in
> the sense of building in the environment we want it to work in (that is,
> against Qt 5). I think it should be moved back.

I disagree there, see the reasons somewhere above.

> I also think that there should be no use of Q_WS_* in tier frameworks.
> Currently KAuth has a few uses of them (in its CMake stuff), but they can be
> removed quite easily. I can maybe do that later. I think being clean of
> that stuff should be part of the checklist before considering a framework
> done though.

Right, our collective bad there for forgetting that point which was in the 
check list for splits (even though I think that's one of those creep ups I 
mentionned earlier).
 
> > Thanks for listening, feedback and comments are welcome.
> 
> I hope this is useful feedback for you.

Definitely. Since it's way more than can be practical by email IMO (and 
touches several topics), let me sum that up as a list of actions:
 * Investigate the relevancy of KPushButton and its final place;
 * Investigate the relevancy of KDialog and its final place;
 * Finalize KAction plan;
 * Complete on the wiki the list of K-Classes to investigate;
 * Cut the dependency of kcolorwidgets toward kwindowsystem;
 * Split the kdelibs cleanup list in monthly goals like the other pages.

Please people step up to pick those actions. Last one is probably for me once 
we completed it a bit.

> If you agree with me, we can work on a new TODO list, and some goals which I
> think are more realistic to achieve also for newbies, and which help the
> effort of making the useful parts of kdelibs available to people who use
> Qt.

I don't think we need a new TODO list. I think we need to improve on how we 
use the ones we currently have and make them live more actively.

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-frameworks-devel/attachments/20120403/52bc2b61/attachment-0001.sig>