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