14:04:56 <jreznik> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-05-18
14:04:56 <zodbot> Meeting started Tue May 18 14:04:56 2010 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:05:11 <jreznik> #meetingname kde-sig
14:05:11 <zodbot> The meeting name has been set to 'kde-sig'
14:05:39 <jreznik> #chair Kevin_Kofler than ltinkl rdieter rdieter_work SMParrish
14:05:39 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter rdieter_work than
14:05:48 <jreznik> #topic roll call
14:05:54 <jreznik> who's present today?
14:06:05 * thomasj 
14:06:10 <Kevin_Kofler> Present.
14:06:19 <SMParrish_mobile> Here
14:06:56 * than is present
14:07:02 * ltinkl is present
14:07:35 <jreznik> #info Kevin_Kofler SMParrish_mobile than ltinkl present
14:08:05 <jreznik> #topic agenda
14:08:44 <jreznik> #link https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-05-18#Agenda
14:08:48 <jreznik> anything more?
14:09:02 <rdieter> here
14:09:11 <jreznik> rdieter: great
14:09:57 <jreznik> should we start? no more agenda?
14:09:58 <rdieter> if we have time, could consider having an irc meeting with the board
14:10:17 <jreznik> rdieter: +1
14:10:36 <Kevin_Kofler> What for? Trying to lobby for a less GNOME-centric attitude?
14:10:47 <Kevin_Kofler> Or for a sane approach to updates?
14:11:05 <Kevin_Kofler> (i.e. not Ubuntu / Debian stable / RHEL style paranoia)
14:11:09 <jreznik> ok, added
14:11:41 <jreznik> Kevin_Kofler: that's why we should talk to them directly (probably no chance to get anything)
14:11:44 <jreznik> ok, let's start
14:12:06 <jreznik> #topic backport Solid and KNM ModemManager support?
14:12:26 <jreznik> Kevin_Kofler: your topic
14:12:35 <Kevin_Kofler> So somebody is now working on mobile broadband (MobileManager) support in Solid and KNM:
14:12:38 <Kevin_Kofler> #link http://lamarque-lvs.blogspot.com/2010/05/solid-and-modemmanager.html
14:12:47 <Kevin_Kofler> #link http://lamarque-lvs.blogspot.com/2010/05/solid-and-modemmanager-update.html
14:12:54 <rdieter> it's on reviewboard too I think
14:12:56 <Kevin_Kofler> But this is targeted only for 4.6.0.
14:13:06 <Kevin_Kofler> rdieter: Yes:
14:13:14 <Kevin_Kofler> #link http://reviewboard.kde.org/r/3769
14:13:16 <Kevin_Kofler> #link http://reviewboard.kde.org/r/3778
14:13:26 <Kevin_Kofler> IMHO we want these much earlier than 4.6.0.
14:14:02 <jreznik> but that's the state? it's probably unfinished as it targets 4.6
14:14:09 <ltinkl> Kevin_Kofler: ye, but from what I've read, it is still work in progress
14:14:11 <jreznik> sorry what's
14:14:29 <Kevin_Kofler> Well, AFAICT it basically works, but yes, it's not finished.
14:14:45 <Kevin_Kofler> He wants to have it finished for this year's Akademy.
14:15:19 <rdieter> wait until it's been reviewed, and code committed to trunk/ at least, to be on the safe side
14:15:29 <ltinkl> Kevin_Kofler: we may want to reconsider it after Akademy then
14:15:35 <ltinkl> rdieter: +1
14:15:36 <rdieter> makes me nervous about touching solid ...
14:15:57 <Kevin_Kofler> I'm more of the "if it compiles, ship it!" school. :-)
14:16:07 <rdieter> we could help test it though, via unofficial builds
14:16:09 <than> it's too early to backport it now
14:16:36 <jreznik> than: yes, too early - but let's wait and we'll see
14:16:41 <jreznik> anyone modem user here?
14:16:57 <jreznik> (mobile broadband, not old modems)
14:17:24 <rdieter> jreznik: good point, we need someone handy to test it
14:17:36 <ltinkl> jreznik: my lappy has it, altho the SIM card inside is not activated, so I didnt try this yet
14:20:05 <ltinkl> so? :)
14:20:12 <SMParrish_mobile> +1 on testing via unofficial builds
14:20:14 <jreznik> I'm not against backport but let's wait to see what's baking in there
14:20:41 <ltinkl> I'd suggest to watch this project, once it gets committed, we can try to backport it via unofficial builds and call for testing
14:20:42 <jreznik> it wouldn't be probably easy to maintain it (as it's under heavy development right now)
14:20:55 <than> yes, we will wait after Akademy
14:20:56 <jreznik> ltinkl: +1
14:21:04 <SMParrish_mobile> And testing by more than 1 person
14:21:04 <rdieter> Kevin_Kofler: you interested in leading the effort here? (or anyone else)?  contacting the coder working on it, possibly helping with the code review, etc...
14:21:34 <rdieter> hand-off patches to me to make test-builds...
14:22:18 <rdieter> but maybe this will all become easier and clearer by simply waiting too, but getting actively involved earlier may speed the process...
14:23:01 <jreznik> yes but it's better to invest time to upstream development instead of backportin
14:23:02 <jreznik> g
14:23:31 <Kevin_Kofler> Backporting stuff gets the feature to our users now.
14:23:31 <jreznik> it's not top task for us - we need working knm and kpkg first
14:23:52 <Kevin_Kofler> Waiting for upstream, even if we help, won't get it out there for more than half a year.
14:23:58 <jreznik> Kevin_Kofler: yes, but we should prioritize stuff we really need and that annoys our users now
14:24:07 <Kevin_Kofler> Maybe a whole year depending on how Fedora's update policies develop. :-(
14:24:41 <SMParrish_mobile> Kevin_Kofler: And backporting broken and nonworking code gets us nowhere
14:24:57 <than> SMParrish_mobile: +1
14:25:39 <than> jreznik: let move on
14:26:00 <jreznik> so what's the conclusion?
14:26:24 <jreznik> ltinkl's proposal?
14:26:28 <than> jreznik: we will wait
14:26:58 <jreznik> rdieter, Kevin_Kofler: ?
14:26:59 <than> it's just low prio for us
14:27:04 <jreznik> yes, it is
14:27:20 <Kevin_Kofler> I can see if I can come up with a backport to use in unofficial packages.
14:27:25 <rdieter> no one's offerred work on it... so wait +1 I guess
14:27:54 <Kevin_Kofler> But I'll give it low priority given that you all think it shouldn't be in our official packages any time soon. :-(
14:27:54 <rdieter> oh, if I get consumable patches, test builds can happen too
14:27:59 <jreznik> #action Kevin_Kofler to check current state ans possibility of backport for unofficial updates
14:28:36 <jreznik> #agreed to wait for now
14:29:15 <jreznik> #topic default install paths for apidocs (follow-up)
14:29:28 <jreznik> anyone has looked on kdevelop code?
14:29:45 <jreznik> looks like the documentation is now shipped as plugins in kdevelop 4
14:29:58 <than> rdieter: any infos?
14:30:01 <jreznik> and only cmake and qt are supported by now, no generic ones
14:30:15 <rdieter> sorry, no update from me -ENOTIME this past week
14:30:23 <Kevin_Kofler> So there's no support for kdelibs docs in KDevelop?!
14:30:27 <jreznik> Kevin_Kofler: no
14:30:29 <jreznik> not yet
14:30:31 <Kevin_Kofler> Ugh!
14:30:44 <than> jreznik: it's supported!
14:30:54 <jreznik> than: where?
14:31:05 <than> i think i kdevelop
14:31:06 <ltinkl> they will hopefully code it, otherwise a KDE IDE without KDE docs is a bit strange :)
14:31:08 <jreznik> I checked it and I got only cmake and qt help
14:31:12 <Kevin_Kofler> I guess it could be patched in rather easily using the Qt docs plugin if we build the qch.
14:31:32 <Kevin_Kofler> We should really build the kdelibs and kdepimlibs qch files.
14:31:33 <jreznik> Kevin_Kofler: probably yes
14:31:41 <Kevin_Kofler> There's some blog post upstream which explains how to do it.
14:31:50 <Kevin_Kofler> It might also be possible for some other stuff, like Soprano.
14:32:21 <Kevin_Kofler> Once we have QCH files built, I can try to patch KDevelop to pick them up.
14:32:24 <jreznik> but currently it looks for qt.qch
14:32:55 <jreznik> so it's not generic qch plugin!
14:33:10 <Kevin_Kofler> It might be necessary to clone the Qt docs plugin and make it search for another QCH.
14:34:32 <jreznik> but the conclussion is - we do not depend on kdevelop 4
14:34:41 <jreznik> (now)
14:35:05 <jreznik> and we really want one common path to store apidocs
14:35:42 <Kevin_Kofler> OK
14:37:14 <than> jreznik: in my opinion we should  keep the current apidoc path before we have a fix in kdevelop
14:37:30 <Kevin_Kofler> Yes, but which one?
14:37:32 <jreznik> than: and for new packages?
14:37:46 <Kevin_Kofler> kdelibs and kdepimlibs do one thing, soprano does another.
14:37:52 <than> it's same for new packages
14:37:53 <jreznik> it blocks grantlee review
14:39:16 <rdieter> imo, this shouldn't be a review blocker.  pick a place, and use it for *now*, interate and adjust later
14:39:25 <Kevin_Kofler> But what place to pick?
14:39:36 <than> rdieter: +1
14:39:37 <rdieter> or don't install them at all, I don't care.
14:40:01 <Kevin_Kofler> Is /usr/share/doc/HTML/en/%{name}-apidocs a decent convention?
14:40:04 <rdieter> drives me nuts when reviewers block on picky stuff
14:40:11 <Kevin_Kofler> If it is, I'll fix Soprano do to the same.
14:40:18 <Kevin_Kofler> The current setup in Soprano is just broken.
14:40:20 <than> for new package we just use the apidoc path like in kdelibs
14:40:25 <Kevin_Kofler> (changes with each version, ugh!)
14:40:34 <jreznik> rdieter: indeed, but I've blocked it only because I know, we are going to talk about it in one week
14:41:07 <than> it's not needed to rebuild soprano before we don't have the fix in kdevelop
14:41:22 <Kevin_Kofler> It is. The docdir changes with each version. This is a PITA.
14:41:24 <jreznik> than: but we can wait for kdevelop few years :D
14:41:38 <Kevin_Kofler> I have old Soprano doc URLs all over my browser history.
14:41:51 <jreznik> so we can choose one path now and we can patch kdevelop later
14:41:57 <than> jreznik: we should set high proritiy for this!
14:42:17 <than> jreznik: yes
14:42:23 <jreznik> we will be consistent - for old packages, new packages, soprano is going to be fixed...
14:42:29 <Kevin_Kofler> I'll do what I can to get at least kdelibs and kdepimlibs apidocs into KDevelop 4 ASAP.
14:42:41 <rdieter> I think Kevin_Kofler's suggested /usr/share/doc/HTML/en/%{name}-apidocs is a reasonable one
14:43:03 <Kevin_Kofler> It's what kdelibs and kdepimlibs currently use.
14:43:28 <Kevin_Kofler> (well, kdelibs uses kdelibs4-apidocs because kdelibs-apidocs is kdelibs3, ugh)
14:44:27 <jreznik> I think it's ok to stick with what kdelibs and kdepimlibs uses now
14:44:34 <jreznik> as these are most important ones
14:44:54 <than> jreznik: yes
14:45:34 <Kevin_Kofler> OK
14:45:38 <Kevin_Kofler> I'll fix Soprano in Rawhide now.
14:45:39 <jreznik> +1 for /usr/share/doc/HTML/en/%{name}-apidocs
14:45:57 <Kevin_Kofler> I guess the best time to fix it in releases is the next version upgrade, where the path would change anyway under the current scheme.
14:46:22 <jreznik> yes
14:46:29 <Kevin_Kofler> I could fix F13 now too though.
14:47:55 <jreznik> I think we agreed on path
14:48:12 <jreznik> #agreed /usr/share/doc/HTML/en/%{name}-apidocs as a default path for apidocs
14:48:19 * thomasj goes and fix grantlee
14:48:43 <jreznik> thomasj: it should be ok (if I remember it correctly)
14:49:07 <jreznik> Kevin_Kofler: ok
14:49:10 <jreznik> let's move
14:49:28 <jreznik> #topic kmail 2?
14:49:51 <jreznik> will stephensons asked on kde-packager ml what to do with kmail 2
14:49:58 <jreznik> we should reply as it affects us
14:50:07 <jreznik> they don't want to hurt downstreams
14:50:19 <Kevin_Kofler> It's a really big nightmare.
14:50:37 <Kevin_Kofler> We need some solution.
14:50:54 <ltinkl> I'm for sticking with kdepim 4.4 for the time being
14:51:01 <Kevin_Kofler> Possible solutions include: withhold KMail from the kdepim 4.5 upgrade, withhold all of kdepim 4.5, withhold all of KDE SC 4.5.
14:51:11 <ltinkl> all of kdepim imho
14:51:18 <Kevin_Kofler> I think I agree with ltinkl.
14:51:27 <Kevin_Kofler> We'll just need some hack to kde-l10n to make it work properly.
14:51:34 <ltinkl> not sure how well would the different parts of kdepim mix
14:51:45 <ltinkl> kdepim+kdepimlibs that is
14:52:05 <jreznik> I like wstephnenson idea - "
14:52:06 <jreznik> I recommend releasing 4.5 without kdepim as was done with 4.0 and doing an
14:52:08 <jreznik> interim kdepim release cycle (call it akonadi tech preview) before 4.6
14:52:09 <jreznik> "
14:52:25 <ltinkl> yes, but how to handle the translations?
14:52:44 <ltinkl> there is no separate kdepim-4.4 branch in kde-l10n
14:52:53 <ltinkl> only stable and trunk
14:53:26 <Kevin_Kofler> Picking up stable @ last revision which matched 4.4 is the best we can do.
14:53:38 <Kevin_Kofler> I guess we need to somehow script diffing the 4.4 and 4.5 versions of all the kdepim translations and applying the diffs in the package.
14:53:48 <Kevin_Kofler> (the reverse diffs, of course)
14:54:07 <Kevin_Kofler> But if kde-l10n omits kdepim entirely, we need to do it differently. E.g. hack the extragear-release script yet again.
14:54:52 <Kevin_Kofler> I think this is a really big mess the kdepim folks have gotten us into there. :-(
14:55:53 <ltinkl> well kdepim folks could block the kdepim translations from going into stable branch, if they decide not to release kdepim with KDE 4.5
14:56:12 <ltinkl> that way we could just package kde-l10n from stable
14:56:49 <ltinkl> or take the 4.5 tarballs which would contain 4.4 kdepim translations
14:59:17 <Kevin_Kofler> ltinkl: Yeah, that would be the best outcome.
14:59:40 <Kevin_Kofler> But we should make sure kde-l10n includes kdepim translations for 4.4 then.
14:59:58 <Kevin_Kofler> Because if they omit them entirely, that makes stuff a PITA for us.
15:00:50 <ltinkl> yes, that was my idea
15:01:23 <ltinkl> Dirk usually copies PO files from trunk to stable once a new version gets released
15:01:35 <Kevin_Kofler> Well, it's not just this copy that has to be omitted.
15:01:47 <Kevin_Kofler> But scripty also needs to be tweaked to use 4.4 for kdepim.
15:01:47 <ltinkl> so the solution is to copy everything except kdepim + kdepimlibs
15:01:52 <jreznik> we are out of time...
15:01:57 <ltinkl> Kevin_Kofler: hmm yes
15:02:03 <Kevin_Kofler> And BTW, kdepimlibs is not affected, the kdepim folks say.
15:02:09 <jreznik> let's finnish discussion at #fedora-kde
15:02:16 <ltinkl> so that the new translations get merged correctly
15:03:03 <jreznik> thanks guys
15:03:05 <jreznik> #endmeeting