14:03:13 <jreznik> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-12-07
14:03:13 <zodbot> Meeting started Tue Dec  7 14:03:13 2010 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:25 <jreznik> #meetingname kde-sig
14:03:25 <zodbot> The meeting name has been set to 'kde-sig'
14:03:55 <jreznik> #chair jreznik Kevin_Kofler ltinkl than rdieter_work rnovacek thomasj
14:03:55 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter_work rnovacek than thomasj
14:04:07 <jreznik> #topic roll call
14:04:09 * thomasj present
14:04:15 * rnovacek here
14:04:15 * ltinkl present
14:05:12 <Kevin_Kofler> Present.
14:05:39 * than present
14:05:53 <jreznik> seems like rdieter_work has some _work duties
14:06:30 <jreznik> #info thomasj rnovacek ltinkl Kevin_Kofler than jreznik present
14:06:41 <jreznik> #topic roll call
14:06:48 <jreznik> corry
14:06:57 <jreznik> #topic agenda
14:07:34 <jreznik> agenda is quite full today
14:07:37 <Kevin_Kofler> We already have more than enough topics.
14:07:39 <Kevin_Kofler> Let's start.
14:07:45 <jreznik> yep
14:07:59 <jreznik> #topic kde-4.5.4 status
14:08:51 <than> kde-4.5.4 was already built for f13/f14
14:08:51 <nucleo> 4.5.4 and kdepim 4.4.8 from kde-testing works fine for me
14:09:01 <thomasj> 4.5.4 looks good so far. Basic testing with my usual workflow, nothing bad happened.
14:09:21 <than> i think we can push 4.5.4 to update-testing
14:09:34 <thomasj> +1
14:10:14 <ltinkl> +1
14:10:21 <jreznik> ok, +1
14:10:50 <than> Kevin_Kofler: ?
14:11:03 <Kevin_Kofler> +1, go ahead.
14:11:13 <Kevin_Kofler> Testing is what updates-testing is for. :-)
14:11:22 <thomasj> He's fighting with kile ;)
14:12:02 <jreznik> #agreed to push 4.5.4 to updates-testing
14:12:13 <jreznik> anyone to prepare update?
14:13:39 <nucleo> kde-4.5.4 and kdepim-4.4.8 for F14 may be should be in one update
14:13:39 <than> i will take care of it
14:14:05 <jreznik> #info than to prepare update
14:14:06 <than> nucleo: yes, we cann add it together
14:14:13 <nucleo> kdepim built with kde 4.5.4 for F14
14:14:18 * jreznik has some matahari duties today...
14:14:59 <than> are there any other packages which we want to add to 4.5.4 update?
14:15:11 <jreznik> #info kde-4.5.4 and kdepim-4.4.8 to be grouped in one update
14:16:37 <Kevin_Kofler> than: None that I know of.
14:17:25 <jreznik> can we move?
14:17:36 <rdieter_work> hi (sorry, I was in-transit, got in a bit late).
14:17:57 <jreznik> #info rdieter_work joined as later - in-transit
14:18:05 <jreznik> #topic qt-4.7.x for f13 : where are we? push forward? drop it?
14:18:18 <jreznik> it's again here... but we have to decide finally...
14:18:39 <Kevin_Kofler> push +1
14:19:03 <rdieter_work> well, we don't *have* to decide now, but making this decision earlier rather than later, can make things smoother moving forward
14:20:00 <rdieter_work> consider me firmly on the fence, can understand either approach (conservative and stick with 4.6, or a bit more agressive and up to 4.7)
14:20:22 <thomasj> Sorry, drop +1
14:20:38 <rdieter_work> fwiw, I'd feel a *little* better about 4.7 if the 'qt-x11 depends on qtwebkit' issue/regression were sorted out
14:20:53 <Kevin_Kofler> thomasj: Why? Basically, it just works.
14:21:04 <Kevin_Kofler> We should just try to sort out the Lokalize backspace regression in 4.7.1.
14:21:22 <Kevin_Kofler> I think I know what upstream Qt commit causes this, maybe reverting that could work as a workaround?
14:21:27 <rdieter_work> ok, count that as 2 regressions
14:21:28 <thomasj> Kevin_Kofler, leave F13 as it is. everyone who *needs* 4.7 (your last argument) can run F14.
14:21:31 <jreznik> rdieter_work: sorry, not now - but it's quite a long time now without decision...
14:21:31 <Kevin_Kofler> rdieter_work: That's not a regression.
14:21:42 <Kevin_Kofler> QtWebKit is also always dragged in in 4.6.
14:21:55 <rdieter_work> oh, really?  ugh
14:22:05 <Kevin_Kofler> It's part of qt-x11 to begin with.
14:22:10 <Kevin_Kofler> And assistant-qt4 also links it.
14:22:53 <than> yes, assistant-qt4 links against webkit  by default
14:22:56 <rdieter_work> confirmed, ok.
14:23:12 <than> but it can use qtextbrowser instead webkit
14:23:15 <Kevin_Kofler> FWIW, than committed a patch to Rawhide to disable QtWebKit support in assistant-qt4.
14:23:22 <Kevin_Kofler> I'm not convinced we want that.
14:23:51 <Kevin_Kofler> It'd help prevent a circular dependency if we want to build QtWebKit separately.
14:24:05 <rdieter_work> I don't mind much either way, but it's an issue that's not relavent to the conversation at hand.
14:24:09 <Kevin_Kofler> But it also means degrading assistant-qt4 for no good reason.
14:24:33 <Kevin_Kofler> Right, this is not a regression, so I don't see why we'd hold up Qt 4.7 for that.
14:24:46 <rdieter_work> jreznik, than, ltinkl : what do you think about f13/qt47?
14:25:32 <jreznik> I already said that - it's more political decision, not technical... technical is easy f13/qt47
14:25:54 <ltinkl> yup, I'm undecided on that
14:27:12 <rdieter_work> fwiw, we do have a few tracked bugs that get fixed with 4.7
14:27:29 <than> i'm not against for f13/qt47
14:28:12 <rdieter_work> a slight side-topic, how goes investigating qtwebkit packaging ?
14:28:26 <thomasj> AFAIK, we accepted to keep our hands off of a Qt update in N-1 with FESCo. Not that i'm, afraid of FESCo..
14:29:04 <rdieter_work> thomasj: that's a good point, *if* we want to move forward, we ought to let them know
14:29:06 <jreznik> thomasj: did we really accept it? fesco was against any qt updates
14:29:28 <thomasj> I can't recall any official veto jreznik
14:29:38 <jreznik> rdieter_work: then we have to prepare good arguments
14:29:44 <rdieter_work> jreznik: it was more a theoretical conversation about whether a f13/kde-4.5 update would be acceptable, and I took the qt47 out of the conversation
14:29:57 <jreznik> rdieter_work: yep
14:30:03 <rdieter_work> once that was done, there was more support for it
14:31:31 <rdieter_work> from the looks of it, seems Kevin_Kofler is the only one much in favor of this, anyone else?
14:32:00 <Kevin_Kofler> I really don't see a good reason not to do it, if the one known regression (Lokalize) is addressed somehow.
14:32:09 <ltinkl> I'm not against but we should probably let Fesco know first, or at least get the opinion
14:32:10 <Kevin_Kofler> (Backspace not working in an app is not nice. ;-) )
14:32:19 <Kevin_Kofler> ltinkl: No.
14:32:22 <Kevin_Kofler> We should just do it.
14:32:29 <ltinkl> no
14:32:31 <thomasj> no
14:32:38 <rdieter_work> one (slight) regression:  konversation gets slower (occasionally).  it's not a well-understood problem, but at least I thought I'd mention it
14:32:38 <Kevin_Kofler> Do first, ask for forgiveness later is the best way if you really want something done.
14:32:43 <ltinkl> no sabotage please :)
14:32:52 <jreznik> rdieter_work: the question is - we already going to have 4.5.4 in f13... do we really want to follow that one major update per release?
14:33:09 <Kevin_Kofler> Of course, if you don't care either way, you want to ask others… But I do care. :-)
14:33:20 <jreznik> rdieter_work: I can feel it sometimes (konversation)
14:33:48 <rdieter_work> jreznik: on f13 or f14?
14:34:03 <jreznik> f13
14:34:04 <Kevin_Kofler> 4.5.4 is not a major update.
14:34:07 <Kevin_Kofler> It's irrelevant here.
14:34:28 <rdieter_work> jreznik: yeah, what's the point about one major update?  or are you hinting at kde46 ?
14:34:52 <than> i think for f13 we stay with kde-4.5.x
14:35:12 <jreznik> sorry, just tired today...
14:35:12 <rdieter_work> or that kde-4.5 = one major update, and qt-4.7 could count as another one?
14:35:42 * jreznik is lost in versions... :)
14:35:50 <Kevin_Kofler> Qt != KDE :-)
14:36:21 <Kevin_Kofler> FWIW, I think we should also push KDE 4.6 to F13, but I'm probably alone in that. :-(
14:36:23 <jreznik> but qt is more sensitive update
14:36:28 <Kevin_Kofler> (When it's released, of course.)
14:36:37 <Kevin_Kofler> And KDE 4.6 would also imply Qt 4.7 anyway. ;-)
14:36:53 <rdieter_work> alright, I'm turning old and fuddy-duddy, just to get some movement and strive for clarity, let's consider me -1 for the 4.7 update then.  if we can't come up with any convincing arguments and activism for it here, we won't have much chance convincing fesco either.
14:36:59 * Kevin_Kofler misses the good old F9/F10/F11 days where we fully supported Fn-1.
14:37:19 * jreznik likes idea - do no touch Fn-1, let it sink with stability-lovers on board
14:37:43 <Kevin_Kofler> Convincing arguments: actually FIXES BUGS for our users on Fn-1!
14:37:58 <Kevin_Kofler> If we let it bitrot, what's the point of "supporting" it at all?
14:38:02 <jreznik> Kevin_Kofler: could you prepare the list of pros/cons for update?
14:38:22 <Kevin_Kofler> No. I don't see any cons, so I'm not a good person to prepare such a list, sorry. ;-)
14:38:26 <jreznik> summary for everyone - without arguments it does not have sense to vote now... seems like more feelings are in
14:38:37 <jreznik> Kevin_Kofler: so just pros :)
14:38:47 <jreznik> you'll see more than we :)
14:38:53 <rdieter_work> I'd be more convinced as well, if a separately packaged qtwebkit were close to a reality... which is most sanely deployable against qt47
14:39:29 <Kevin_Kofler> Several bugs fixed, allows building current upstream versions of a bunch of other software, makes it easier to fix QtWebKit security issues etc.
14:40:14 <Kevin_Kofler> rdieter_work: Actually, without separate QtWebKit, we don't have a good way to push QtWebKit security fixes to 4.6.
14:40:32 <thomasj> Kevin_Kofler, let me ask you a question. What is the difference between F13 and f14 for you if you push all updates to both versions?
14:40:41 <rdieter_work> 4.6 is harder, true, due to it's older bundled webkit
14:40:48 <than> Kevin_Kofler: we have a working standalone qtwebkit
14:40:51 <Kevin_Kofler> Those updates which we don't push because they break things. :-)
14:41:09 <than> it works with qt.4,6.
14:41:10 <Kevin_Kofler> I don't know if there are any relevant ones KDE-wise in this cycle, but I mean this as a general policy.
14:41:43 <rdieter_work> than: it could be made to work against 4.6 I suppose, but would be a bit more work too.
14:41:46 <jreznik> standalone webkit - -1 for qt 4.7 update, otherwise I'm +1 as WebKit SIG guy :)
14:42:09 <jreznik> rdieter_work: it should work against qt 4.6 - it should be supported by upstream!
14:42:36 <rdieter_work> alright, I'd suggest taking the continuing discussion elsewhere (#fedora-kde and onlist), and move on here
14:42:54 <jreznik> ok
14:43:04 <jreznik> #info move discussion onlist and #fedora-kde
14:43:24 <jreznik> #topic Calligra
14:43:49 <jreznik> it's going to be quick one - Calligra is KOffice replacement, we will see it with v2.4
14:43:54 <ltinkl> http://dot.kde.org/2010/12/06/kde-announces-calligra-suite
14:44:07 <jreznik> #link http://dot.kde.org/2010/12/06/kde-announces-calligra-suite
14:44:17 <rdieter_work> oh boy
14:44:23 <Kevin_Kofler> Those names are really lame. :-/
14:44:23 <jreznik> we have time to prepare - it's the group B - and I think we want this one
14:44:32 <jreznik> Kevin_Kofler: and inconsistent
14:44:51 <jreznik> Words, Tables but Stage... and then Kexi instead Bases for example
14:44:59 <than> hm, why was the name koffice changed?
14:45:00 <Kevin_Kofler> And "Words"? Will that get them sued by M$?
14:45:17 <ltinkl> all your Base^Stages are belong to us
14:45:18 <jreznik> than: it's fork
14:45:37 <jreznik> than: KWord maintainer is/was ...
14:46:07 <ltinkl> yup, I fear Calligra Words asks for a trademark problem
14:46:08 <jreznik> Kevin_Kofler: yep, I'd like to ask Inge if they considered it
14:46:54 <Kevin_Kofler> And what I don't understand is why they didn't just rename KWord? All the other apps clearly said they want to join the group that's now Calligra, so why did they have to rename them?
14:46:59 <thomasj_> sorry, got disconnected
14:49:36 <jreznik> lets check some bugs...
14:49:40 <jreznik> #topic qt-x11 (assistant) depends on qt-webkit
14:49:43 <rdieter_work> ok, looks like a winner.  As a matter of fact, do we really have to choose?  we could theoretically package both koffice forks (provided they don't conflict)
14:50:07 <Kevin_Kofler> That last part could be an issue.
14:50:15 <jreznik> rdieter_work: I think it's better to choose one (especially with nearly the same code)
14:50:20 <ltinkl> rdieter_work: they will most probably conflict
14:50:30 <Kevin_Kofler> Plus, will Mr. "Group A" even have something to release?
14:50:30 <rdieter_work> ok
14:50:42 <Kevin_Kofler> I didn't see even one person intending to join him on the ML.
14:50:49 <rdieter_work> we'll wait-n-see, but calligra is clearly the short term winner
14:50:50 <ltinkl> and that too, don't think the other group will ever release anything
14:51:52 <jreznik> Callibra has support from KO, KO money from Nokia (but also they tend to support mobile versions more, because of Nokia)
14:52:22 <jreznik> we have few minutes left - back to topic - qtwebkit in qt-assistant (spin positions we can later)
14:52:36 <jreznik> than prepared patch... do we really want it? as Kevin_Kofler asked?
14:52:45 <Kevin_Kofler> I feel bad taking sides without knowing the whole story, as I'm sure he sees things differently (I've been in such a project split, I know how it feels), but from the outside, it looks a lot like Calligra is the only version with any chance to survive.
14:53:53 <Kevin_Kofler> Re Assistant, I'm concerned that we'll make the documentation look bad by using the minimalist QTextBrowser instead of QtWebKit.
14:54:06 <Kevin_Kofler> Upstream must be defaulting to QtWebKit for a reason.
14:54:20 <rdieter_work> we can at least test it, though perhaps we have to simply accept qtwebkit as a usual runtime dep (for qt-x11)
14:54:23 <jreznik> Kevin_Kofler: does it matter for documentation? than, have you tested it?
14:55:15 <than> i don't see any difference here
14:55:19 <rdieter_work> another alternative, ... split out assistant packaging (may require dep changes in apps that need/use it)
14:55:31 <than> it works fine with qtextbrowser
14:55:38 <ltinkl> I wouldn't go that far
14:56:03 <rdieter_work> OK, we already include a Provides: qt4-assistant , apps should already depend on that
14:56:08 <ltinkl> and tbh, I don't think applications use some fancy HTML/JS tricks for their docu, so  qtextbrowser should just work fine
14:56:21 <than> ltinkl: +1
14:56:28 <Kevin_Kofler> QTextBrowser doesn't even support CSS (or does it?).
14:56:42 * ltinkl checking
14:56:56 <rdieter_work> I'd feel a little better about the patch, if upstream was asked for comment/feedback.  than, can you do that?
14:57:01 <jreznik> Kevin_Kofler: it does (some basic)
14:57:01 <than> Kevin_Kofler: i haven't checked it
14:57:37 <ltinkl> looks like it does
14:57:38 <than> rdieter_work: i can ask upstream
14:57:41 <jreznik> some subset, same as for HTML
14:57:45 <ltinkl> yup
14:57:49 <rdieter_work> in the meantime, I'd like to see the patch tested for feedback by our devs/users
14:57:52 <Kevin_Kofler> Well, I guess we can try this patch in Rawhide and see whether we get any incoming complaints. :-)
14:58:04 <jreznik> Kevin_Kofler, rdieter_work: +1
14:58:15 <jreznik> than, ltinkl:?
14:58:21 <than> yes, it's good to have it in rawhide
14:58:26 <ltinkl> yup, +1
14:58:27 <than> so users can test it
14:58:39 <jreznik> #agreed on testing patch in rawhide for feedback by our devs/users
14:59:31 <jreznik> two minutes left - we can discuss that few items on todo at #fedora-kde
14:59:41 <jreznik> one minute actually...
14:59:51 <rdieter_work> ok
15:00:02 <jreznik> thanks for coming today!
15:00:24 <jreznik> #endmeeting