[17:17] <alexn> so, what's the state of the kdelibs frameworks branch ?
[17:18] <dfaure> partially splitted into separate frameworks, but not yet
[17:18] <ervin> http://community.kde.org/Frameworks/Epics/Splitting_kdelibs
[17:18] <ervin> it's kind of the standard answer, I want that tracked on that page so we know
[17:18] <ervin> currently only one framework ready
[17:18] <ervin> more in the work or missing maintainers
alexn gives an overview about cmake progress. Achievements so far:
alexn added some to-dos to the wiki: http://community.kde.org/KDE_Core/Platform_11/Buildsystem/FindFilesSurvey#TODOs
[18:11] <ervin> alexn: looks good, I'd like the cmake epic page to be the primary list, that's where we're going to direct people for work
dfaure: deadline for the Qt5 merging (feature freezes) was pushed from Nov 2011 to around March/April 2012 (not exact). ervin expects it to jump higher in priority once we get more progress on kdelibs.
ossi says there's no date set yet
[17:55] <alexn> so the wiki page is complete and correct, i.e. this is everything we'd like to get in ?
[17:55] <dfaure> no I think there are more things we might want to get in
[17:56] <ervin> they definitely need to be in the wiki asap, means we're working on wrong ground here
i18n: [help welcome to turn raw log into proper notes]
[17:55] <dfaure> too bad John Layt isn't here, I'm very curious about the status of that.
[17:55] <dfaure> (especially the i18n() vs tr() issue)
[17:56] <ossi> that's more a thing for Chusslove. john strategically rejected this topic
[17:56] <tsdgeos> to be honest i don't think the i18n/tr is being tackled by anyone
[17:56] <tsdgeos> Chusslove specifically said he did not want to rewrite it just for the fun again
[17:57] <ossi> thing is, we can't just remove tr() anyway (compat constraint), and whatever new we produce, it will be more like i18n()
[17:57] <aseigo> dfaure: so a get together on that topic with chusslove, ossi, you, layt... would be useful?
Chusslove wanted to push it to Gettext even wrote a detailed proposal of features (based on the epic kcd i18n thread) at http://nedohodnik.net/gettextbis/ but it didn't garner any interest.
[18:07] <Chusslove> At the moment, as ossi says, tr() cannot be dumped as such.
[18:08] <Chusslove> So I thought of simply having a translation module in frameworks. So you choose, use that (let's call it i18n() as it is) or use tr().
[18:09] <dfaure> well that's the fallback plan. I don't like it (kde app vs qt app), but if there's no other choice, so be it.
[18:09] <ervin> yeah, that's the thing we try to avoid
[18:09] <Chusslove> You choose tr() if you want to cut down on dependencies from framework, or you like Qt linguist for whatever reason.
[18:09] <Chusslove> You choose i18n() if you don't mind dependencies from framework, or you like PO plus extras.
[18:09] <dfaure> at least I hope we can support both kinds of apps within KDE's translation system.
[18:10] <dfaure> otherwise it creates a stupid barrier against "let's have (say) scribus in kde git".
another action item is to replace QLocalizedString which is a temporary porting helper in kdelibs frameworks
<dfaure> but this is mostly used for kcmdlineargs (and kaboutdata) stuff, so maybe we have to fix that first => conclusion of i18n: it's a huge topic, needs dedicated meeting
ervin: what's missing on the tracking page? how do we make sure it's all there? dfaure suggested there's more
dfaure will re-read other documents
[18:19] <aseigo> what would be fantastic is to have concise "blueprints" for what needs to be done for each of these things, and then we can pair the tasks up with willing developers.
[18:19] <aseigo> i fear too much of this exists in your head where others can't see it and so can't do the work...
[18:20] <dfaure> this is a good example where there is no blue print yet.
[18:20] <dfaure> my head only says "we need to think about this"
[18:20] <aseigo> that's a fine starting blueprint. "research klocalizedstring, taking A, B and C into consideration." :)
[22:37] <dfaure> cmake exports is a side discussion on how to fix the current error when compiling kdelibs-frameworks.
Talk about where libplasma2 lands: tier 3 (because of kconfig dependency) and goes to solutions (aseigo still needs to check about kio dependency or just QNA
About the eventual splitting of the frameworks repositories:
[22:37] <PovAddict> would that keep the entire pre-frameworks (or pre-split) kdelibs history in each repo, with a commit that deletes everything except the one framework being kept?
[22:38] <dfaure> with git graft
[22:38] <dfaure> for each framework: first import has all code as new, and with graft you can look up old history coming from the kde4 kdelibs.git
[22:39] <PovAddict> what I was thinking is that if we're going to 'break repos' anyway, I could try improving the svn conversion; it's far from perfect especially regarding svn work branches
[22:45] <PovAddict> dfaure: and that also gives another option, instead of grafting libplasma.git on kdelibs.git, make a new git repo containing only the history of kdelibs/plasma (and *then* you do have the opportunity to break things) and use that as a base for the new libplasma.git
[22:47] <dfaure> PovAddict: anyway, to conclude, if you feel it's worth it and since you're volunteering, I'm not opposing, of course.
[22:45] <dfaure> on the todo list, we need to split up kio too ... I seem to have lost the preliminary list that ervin and I made in Randa :-(
[22:45] <ervin> dfaure: kbookmarks, kio-core, kio-widgets
[22:46] <ervin> dfaure: I left kio/kfile out though, I'm never sure how it plays with kfile
[22:50] <ervin> we did a list of technical tasks along the way, but I'd like to touch a bit about the "how to get more people on board"
We need documentation: http://community.kde.org/Frameworks
[22:52] <dfaure> I think it's more about getting the people who are here right now, actually involved in the actual work ;)
[22:53] <valir> organize a new KDE sprint?
[22:53] <richmoore1> perhaps making clear which jobs are small/medium/large so that people can get a feel for how likely it is they can manage one
[22:54] <svuorela> yeah. job size. and maybe requirements 'intimate knowledge of ssl' 'normal sanity' 'knowing weirdnesses of http protocol' ...
[22:54] <dfaure> the issue is, nothing is "monkey work", there's quite some thinking to be done. E.g. anyone trying to make a framework from kdeui classes, ends up with issues like "so, this is using klineedit, but why? can I just use a qlineedit? do we need to get some of klineedit features into qt first? ..."
[22:55] <dfaure> I don't have a solution for that (we can't do all the thinking ahead of time, what we need is people to help us with that work, not just with the splitting) No split and run, you need to think, so no small tasks.
[22:56] <dfaure> I can only say, be prepared to face such issues, and to potentially have to contribute to qt.
You need to check e.g. why KLineEdit and not QLineEdit and this for every new existense. Ask this questions on k-f-e
About Monkey works:
[22:58] <dfaure> I want people who run the unittests to make sure they haven't broken anything, and think hard about what the change could break in areas that are not unit-tested
Make new people do this work, send a review, ask them about the unit tests and let the learn to do it in the future automatically
[22:59] <richmoore1> i think adding unit tests is another thing that should be relatively easy to get new people into, even if they're only testing basic stuff it's better than no unit testes
[22:59] <dfaure> anyway I want to point out that "porting" is NOT the biggest part of the job here.
[22:59] <tsdgeos> i'm more concerned about the contribute to qt part
[23:00] <ervin> from the current ongoing work the problem we face is more people willing to split stuff at all
[23:05] <aseigo> build small to big
[23:07] <aseigo> so. . documentation, a developer outreach effort and some timelines.
Another idea is to host special days for this on IRC (see Bug Days of Plasma and Co)
Human interaction: Blogs, hold hands, IRC, documentation, timelines/deadline, split the jobs up in achievable tasks, volunteer days
Rythm/iterations of work:
[23:09] <ervin> dfaure: it's about saying X, Y and Z will be done during current iteration
[23:09] <ervin> X', Y', Z' in the next one
[23:09] <ervin> based on the amount of people doing stuff About what's going to Qt5 and when is it in libinqt5:
[23:12] <ervin> dfaure: when something is in progress in the qt5 merge, it should be in libinqt5
[23:12] <ervin> the current "let's wait for it to be in qt5" just stall the efforts for too long
[23:13] <dfaure> I guess the truth is in between, yeah, we could add to libinqt5 once it's reasonably sure that it -will- go into qt5, and we're in the phase of handling the nitpicking ;-)
What is libinqt5: => it's a temporary lib containing stuff that *is* in qt5, so that we can use that stuff already (dfaure)
[22:42] <tsdgeos> ervin: let me ask again then, http://community.kde.org/Frameworks/Epics/Splitting_kdelibs says "Tier 1" and in there it lists "idletime". Is there a place to learn what that "idletime" means in case i want to help creating it's framework? => Documented on the Policies page.