Frameworks/Meetings/20111204
KDE Frameworks Meeting - 20111204
Agenda
[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
A round of "where we are at" status report
CMake
alexn gives an overview about cmake progress. Achievements so far:
- automoc is in CMake since 2.8.6
- package/repository extra-cmake-modules created
- no release of it yet
- the Find-modules from kdelibs, which also exist in cmake, have all been synced into cmake
- several macros merged into cmake and not necessary in kdelibs anymore (incompatibilities documented in http://techbase.kde.org/Development/ECM_SourceIncompatChanges )
- because of Qt5 split:
- Qt5 now installs config files. No need to have a FindQt5.cmake
- there is now find_package(Qt5Core) find_package(Qt5Gui)
- some cmake variables are changed, such as QT_QTCORE_LIBRARIES → Qt5Core_LIBRARIES
To-do:
- all the cmake files in kdelibs/cmake/modules/ need to be reviewed and a) upstreamed into cmake, b) upstreamed into e-c-m, or c) removed
- easy-to-distribute task
- aseigo suggests "get it done" day(s)
- <alexn> let's not simply go through the huge list of files, but instead do it modularized library by modularized library; i.e. if itemmodels is ready to be separated, let's check what Find-modules it needs, and let's get those into e-c-m
- ↳ ervin, valir, aseigo agree
- more API changes to come
- discussion on who is responsible to fix what breaks due to those API changes
- <alexn> all I can do is to document the changes, fixing everything that broke is beyond what I can do in the time I have
- <ervin> the person making incompatible CMake changes should warn on k-f-d
- ☐ mention this on the wiki page
- steveire: many things devs can do to "pre-port" kde4 apps, like upgrading cmake version (is this actually possible?), using QIcon instead of KIcon, etc
- ☐ porting steps should get documented
- svuorela requests post-meeting cmake+multiarch discussion
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
Qt5 merging status report and split up
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
- QPrinter: svuorela says it's moved out of QtBase & QtWidgets, so it can wait to 5.1. Also needs jlayt...
- KProcess/KShell/KUser: ossi has "plans", nothing more concrete, never thought about KUser
- dfaure: if ossi makes precise plans dfaure can do the work, like with QSaveFile
- "what does KAction have that QAction should have, and patching QAction accordingly"
- valir volunteers :)
- need someone to work on cmdlineargs in qt, with hopefully something closer to the kde4 solution than what people have been suggesting on qt5-feedback
- (kde4 = a big static const array ; the qt5 proposal = c++ method calls to define args)
- dfaure: everyone agrees the impl sucks, but what about the API? Should we try to keep the big static const or have method calls?
- tsdgeos: kde4 should have renamed it to KCommandLineArguments already
- the method approach is useful for i18n as we don't need "delayed translation"
[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." :)
- dfaure would like to start on kde4support soon since he's deprecating stuff
- ervin agrees it's the right moment to do it
- alexn suggests renaming to kde4compat to avoid confusion with kdesupport
[22:37] <dfaure> cmake exports is a side discussion on how to fix the current error when compiling kdelibs-frameworks.
libplasma:
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.
kio/kfile:
[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
Build an action plan
[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)
Distribute tasks
- Add CMake ECM review to the done definition of the splitting kdelibs epic (alexn)
- Add "warn k-f-d on CMake API changes" to the done definition of the CMake epic (alexn)
- Add a page on porting to frameworks (everyone longer term, started by steveire for the cmake stuff)
- Review the Qt 5.0 Merge epic and make sure everything needed is in the list (dfaure)
- Organize a meeting to device what's needed to move i18n forward (ossi, Chusslove, more?)
- Work on KAction vs QAction topic on Qt 5.0 merge allocated to valir
- Start kde4support (dfaure)
- Find a volunteer for KCmdLineArgs (valir)
- Update the class by class spreadsheet to make it less confusing to newcomers (ervin with help from tsdgeos)
- Add for the items in the backlog in the kdelibs splitting epic where they exist right now in kdelibs to help newcomers wanting to help (ervin)
- Figure out how/when to deal with the git split in the kdelibs split epic (ervin)
- Organize volunteer days to attract volunteers (aseigo: those days will require presence of ervin, dfaure and alexn to be effective... they coordinate the three active epics after all)
- Set goals and timelines within the current epics (dfaure, ervin, alexn)
- Define and write down what a "Tier" is
[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.