14:00:12 <jreznik> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-08-10
14:00:12 <zodbot> Meeting started Tue Aug 10 14:00:12 2010 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:51 <jreznik> #meetingname kde-sig
14:00:51 <zodbot> The meeting name has been set to 'kde-sig'
14:01:23 <jreznik> #chair Kevin_Kofler than rdieter rnovacek SMParrish
14:01:23 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik rdieter rnovacek than
14:01:55 <jreznik> #topic roll call
14:02:04 <jreznik> who's present?
14:02:13 <jreznik> #chair ltinkl
14:02:13 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter rnovacek than
14:02:21 <rnovacek> here
14:02:22 * ltinkl is here
14:02:31 <rdieter> here
14:02:35 * than is here
14:03:23 <jreznik> #info jreznik rnovacek ltinkl rdieter than present
14:03:56 <jreznik> anyone else here?
14:04:09 <jreznik> #topic agenda
14:05:49 <jreznik> no more agenda to discuss today?
14:06:22 <jreznik> maybe again more on branding (if time allows)
14:06:28 <jreznik> let's start
14:06:37 <Kevin_Kofler> Present.
14:06:51 <jreznik> #info Kevin_Kofler present too
14:07:08 <jreznik> #topic kde sc 4.5.0 status (rdieter)
14:07:12 <Kevin_Kofler> I think we have enough on the agenda already. :-)
14:07:24 <jreznik> let's start with most important...
14:07:40 <jreznik> 4.5.0 is official out (and for the first time not as KDE SC!)
14:07:41 <rdieter> I've queue'd kde-4.5.0 for f14 updates-testing and kde-testing
14:07:56 <rdieter> not sc?  ugh
14:08:07 <rdieter> I mentioned that in the updates notes, but no big deal
14:08:39 <jreznik> as I already said - using KDE SC was mistake
14:08:40 <than> no, KDE Releases Development Platform, Applications and Plasma Workspaces 4.5.0
14:08:42 <jreznik> KDE Releases Development Platform, Applications and Plasma Workspaces 4.5.0
14:08:59 <jreznik> #link http://www.asinen.org/2010/08/releases-release-notes-and-branding/
14:09:12 <Kevin_Kofler> This is all bullshit.
14:09:16 <Kevin_Kofler> Let's just call it KDE again.
14:09:28 * ltinkl nods
14:09:41 <Kevin_Kofler> With every release, what they want us to call it gets longer.
14:09:44 <Kevin_Kofler> This is just nonsense.
14:09:58 <rdieter> it's an improvement at least
14:10:53 <rdieter> otherwise, that's the end of my own report wrt 4.5.0
14:11:07 <ltinkl> what about F13 & co.?
14:11:25 <than> who want to take care of kde-4.5.0 build for F13?
14:11:35 <Kevin_Kofler> We should take care of the deps for kdeedu.
14:11:55 <rdieter> I have builds @ kde-redhat/unstable already, though I really think we ought to wait for 4.5.1 before considering for official updates
14:11:55 <Kevin_Kofler> libindi needs to be updated, avogadro built for F12 and F13, both need to be enabled as BRs in kdeedu.
14:12:00 <than> Kevin_Kofler: what is problem in kdeedu?
14:12:05 <ltinkl> than: I can take care of that but I guess I will have to fight my way thru with the git business :)
14:12:08 <Kevin_Kofler> Otherwise we lose features.
14:12:32 <Kevin_Kofler> (4.4.x supported the older libindi and used a bundled snapshot of libavogadro, now the library is shared with avogadro the app.)
14:12:57 <rdieter> Kevin_Kofler: I believe that's marked as a kde-4.5 blocker, yes?
14:12:58 <jreznik> rdieter: why waiting for 4.5.1?
14:13:15 <rdieter> several serious bugs were fixed post 4.5.0
14:13:39 <rdieter> we backported the kded/network kio one already, good
14:13:59 <than> i have not tested kde-4.5.0. how stable is it?
14:14:18 <rdieter> darn good, but 4.5.1 should be safer is all
14:14:19 <than> has someone already installed it?
14:14:19 <jreznik> than: it's stable
14:14:35 <rdieter> I suppose that doesn't necessarily block working on builds now though
14:14:38 <jreznik> much more better than 4.4.5 - at least krunner is again usable
14:15:04 <rnovacek> I tried to install it today....
14:15:13 <than> great, then it's ok for f13 update
14:15:32 <rnovacek> It seems slower with nvidia proprietary driver, will try it with nouveau
14:16:27 <than> ltinkl: if you use clone -B ...
14:17:03 <jreznik> than: git workflow is agenda item for todays meeting
14:17:10 <ltinkl> yup, I have no idea :)
14:17:20 <ltinkl> how to best "backport" the stuff from F14
14:17:23 <jreznik> rnovacek: it's OK with nouveau and some people reported even composite working
14:17:32 <ltinkl> merge, clone, copy?
14:18:04 <Kevin_Kofler> I'd copy the files to make the contents of the branches coincide, then "merge" (which will be a trivial merge) to allow further merges from devel.
14:18:06 <rnovacek> jreznik: great, I'll try tomorrow
14:18:17 <Kevin_Kofler> FWIW, we now need to do merges from devel to F-14 too.
14:18:25 <Kevin_Kofler> rdieter: The way you merged those changes was bad.
14:18:40 <Kevin_Kofler> F14 was branched in git from devel, you could just have merged the devel commits.
14:18:44 <ltinkl> looks like git will be fun to handle, at least until we find the best practices :)
14:18:57 <jreznik> ok, anything more to 4.5.0 status? f12?
14:19:01 <Kevin_Kofler> Now we need to merge anyway, and your commits will just be in the way, forcing an actual merge instead of a fast-forward one.
14:19:14 <Kevin_Kofler> But at least the merge should be trivial (identical contents) => no conflicts.
14:19:19 <jreznik> or we can seamlessly step into git workflow topic :D
14:19:24 <than> do we want to do kde-4.5.0 for f12 update?
14:19:26 <rdieter> Kevin_Kofler: I had been waiting for someone else to do it, or show me how, but that didn't happen.  so, I just did it the only way I knew how
14:19:44 <ltinkl> rdieter: feels the same :)
14:20:17 <rdieter> than: maybe, but it'll need extra updates-testing time, imo, again, 4.5.1 is a better candidate
14:20:24 <ltinkl> FWIW, I think the infrastructure team should have provided some quick howtos/videos/tutorials on this topic before the switch to git
14:20:37 <than> rdieter: it's fine with me
14:20:50 <jreznik> #info kde-4.5.0 queue'd for f14 updates-testing and kde-testing
14:20:56 <Kevin_Kofler> How I do merges: Fire up git-cola, switch branch to f14/master, pull (otherwise git-cola will spit out a strange error when trying to merge), merge devel, push.
14:21:09 <rdieter> Sho_ expressed wanting kde-4.5.x for f12, since that's the latest release supporting ppc
14:21:12 <Kevin_Kofler> s/devel/master/, sorry.
14:22:08 <ltinkl> Kevin_Kofler: mind writing a page on wiki with different scenarios, using kdelibs as an example? :)
14:22:12 <jreznik> let's build 4.5.0 for f13 -> updates-testing and we can wait for 4.5.1 there
14:22:24 <ltinkl> might be useful for other (even future) contributors
14:22:29 <Kevin_Kofler> ltinkl: Well, I suspect most people will prefer the command line. :-)
14:22:38 <ltinkl> ye sure, using command line
14:22:39 <Kevin_Kofler> Even with CVS, I think I was the only one using Cervisia.
14:22:48 <ltinkl> kinda suprises me :)
14:22:54 <Kevin_Kofler> I like GUIs.
14:23:02 <jreznik> hey, please - finish 4.5.0 status topic, then we can talk about git...
14:23:08 <ltinkl> yup
14:23:20 <ltinkl> so what to do with F12? wait for 4.5.1?
14:23:41 <Kevin_Kofler> IMHO, if we do F13, we should do F12 too.
14:23:46 <Kevin_Kofler> But we need to get the blockers sorted out.
14:23:54 <Kevin_Kofler> Especially the kdeedu deps.
14:24:06 <than> as i already said it's fine with me to wait for 4.5.1
14:24:15 <jreznik> I would build 4.5.0 (and solve blockers) and put it to updates-testing, we can test it and push into stable or wait for 4.5.1
14:24:40 <jreznik> but I really like it - 4.5.0 is quite good release (even some backports are needed)
14:25:09 <rdieter> remember too, our kde-4.5.x builds BR: qt-4.7.0
14:25:23 <rdieter> .bug 603202
14:25:25 <zodbot> rdieter: Bug 603202 kde-4.5 tracker - https://bugzilla.redhat.com/show_bug.cgi?id=603202
14:25:32 <rdieter> and see blockers ^^
14:25:44 <ltinkl> I volunteer to do the F13 builds, anyone for F12?
14:26:06 <rdieter> .bug 604768
14:26:08 <zodbot> rdieter: Bug 604768 qt-4.7 tracker - https://bugzilla.redhat.com/show_bug.cgi?id=604768
14:26:09 <rdieter> see also ^^
14:26:40 <rdieter> so, do we *really* want to unless qt-4.7.0-beta2 on f13  or revert to allow building against qt-4.6.3 again?
14:26:50 <rdieter> s/unless/unleash/
14:26:57 <jreznik> #info ltinkl to work on F13 builds
14:27:03 <ltinkl> guess not
14:27:04 <than> rdieter:  we have to revert it if we want to buil dit for F13
14:27:13 <Kevin_Kofler> We should build against 4.6.3.
14:27:25 <Kevin_Kofler> Shipping a beta Qt isn't a great idea.
14:27:26 <rdieter> than: ugh, that's why I didn't like you wanting qt-4.7.0
14:27:28 <than> qt-4.7-beta is nogo
14:27:41 <Kevin_Kofler> I hope 4.7.0 will be ready for F14!
14:27:42 <jreznik> when is qt going out?
14:28:02 <jreznik> Kevin_Kofler: and if not? revert to 4.6.3?
14:28:04 <than> jreznik: we don't know
14:28:19 <rdieter> maybe I didn't make my concerns clear enough back then, wanting to avoid this situation
14:28:20 <than> drop requires 4.7
14:29:01 <jreznik> rdieter: sorry, I didn't realize it...
14:29:35 <Kevin_Kofler> If 4.7 won't be ready for F14, I'm not sure what we'll do.
14:29:38 * rdieter thought he had mentioned this precise scenario, but oh well
14:29:55 <Kevin_Kofler> We've had 4.7 betas in pre-branch Rawhide for a while.
14:30:04 <Kevin_Kofler> So a lot of stuff is built against 4.7.
14:30:17 <rdieter> Kevin_Kofler: I think for f14 we're stuck with 4.7
14:30:21 * thomasj_ late here
14:30:21 <Kevin_Kofler> I guess the best we can do in such a case is to ship the latest git snapshot of 4.7 so at least we can get current fixes.
14:30:41 <Kevin_Kofler> But we shouldn't push 4.7 as an update to F13, let alone F12, before it is released.
14:31:46 <Kevin_Kofler> I see 9 open KDE 4.5 blockers.
14:31:58 <Kevin_Kofler> That's a lot, considering we haven't even started widespread testing.
14:32:22 <Kevin_Kofler> Usually a bunch of regressions shows up while the update is in updates-testing.
14:32:39 <than> Kevin_Kofler: we don't want to push 4.7 beta in f13 update
14:32:44 <jreznik> we should take a look to this blockers
14:32:54 <jreznik> than: of course not
14:33:01 <rdieter> I know, I think we should either resolve or make progress on existing blockers before considering for f13 updates (much less f14 final release)
14:33:01 <Kevin_Kofler> than: I think we all agree on that. :-)
14:33:18 <jreznik> rdieter: +1 to solve blockers first
14:33:45 <jreznik> f13 can wait (as we have kde-unstable repo for brave people)
14:34:33 <Kevin_Kofler> If we have open regressions, people will complain about our "destabilizing" updates and actually have a reason to complain. :-(
14:35:19 <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=615651 (the printer-applet crash) – isn't that fixed in 4.5.0?
14:35:44 <rdieter> esp since the boards' updates vision contains the language "updates should... only fix bugs and security issues"  (which I'm hoping to get ammended with less-strict language)
14:35:56 <rdieter> Kevin_Kofler: yes
14:37:16 <jreznik> f14 is now priority, first let's fix blockers, f12/13 can wait
14:37:37 <jreznik> I wanted to test alpha KDE but TC1, TC2 and RC1 wasn't installable
14:37:46 <Kevin_Kofler> rdieter: So we have only 8 blockers left. :-)
14:37:47 <jreznik> and RC2 does not work because of systemd
14:38:27 <rdieter> jreznik: lovely, still not resolved?
14:39:50 <rdieter> anyway, I think we have a plan to squash blockers, move on?
14:40:06 <ltinkl> ye
14:40:34 <rdieter> and revert hard BR: qt-devel >= 4.7.0 dep
14:40:53 <Kevin_Kofler> Right.
14:41:08 <jreznik> #info to work on 4.5 blockers
14:41:22 <jreznik> #info to revert  hard BR: qt-devel >= 4.7.0 dep
14:41:48 <jreznik> and we need backup plan for qt 4.7 in F14 (BR 4.6.3 is one step)
14:42:09 <Kevin_Kofler> Unfortunately, reverting Qt in F14 isn't very feasible.
14:42:18 <Kevin_Kofler> We'd have to rebuild everything built against 4.7.
14:42:28 <Kevin_Kofler> (in addition to Epoch-bumping qt)
14:42:55 <Kevin_Kofler> Is there any info when 4.7.0 will be out?
14:42:58 <jreznik> Kevin_Kofler: but on the other hand - broken Qt as base component is bad thing :( but I'm using beta on all systems and seems to be quite stable...
14:43:29 <Kevin_Kofler> 4.7 was supposed to be a release with a shorter cycle, but now it's taking ages, they added a second beta and it's still not in RC stage. :-(
14:43:38 <jreznik> Following the Qt 4.7 Beta II release, we will make release candidates of both Qt 4.7 and Qt Creator 2.1 available during the summer, with the final releases several weeks thereafter.
14:43:59 <jreznik> would be great to have at least RC
14:43:59 <Kevin_Kofler> The summer is almost over, where's the RC? :-)
14:44:19 <Kevin_Kofler> Hopefully they don't mean summer in Brisbane. ^^
14:44:22 <rdieter> we were hoping for a standalone qtwebkit release too
14:44:43 <Kevin_Kofler> rdieter: Yeah right, what happened of that one?
14:44:46 * rdieter has worked a little on packaging a qtwebkit snapshot for review
14:45:15 <rdieter> Kevin_Kofler: last I heard was developers were wanting to rebase their work on a newer webkit snapshot
14:45:42 <rdieter> but no updated roadmap, release plan that I'm aware of
14:46:09 <rdieter> the original plan was for a release in May/June.  :(
14:48:32 <rdieter> let's move on, I want to here more about other stuff (git). :)
14:48:48 <rdieter> and qch docs
14:49:17 <Kevin_Kofler> We should really discuss the QCH docs now.
14:49:46 <jreznik> ok
14:50:10 <jreznik> what's more important now? git workflow or QCH?
14:50:37 <jreznik> #topic QCH apidocs
14:50:48 <jreznik> we can talk about GIT on #fedora-kde
14:50:49 <Kevin_Kofler> So I've looked at how KDevelop handles docs.
14:51:10 <Kevin_Kofler> Apparently all we need is to install them into %{_qt4_docdir}/qch/
14:51:23 <Kevin_Kofler> KDevelop will load all the docs in the same dir as qt.qch.
14:51:37 <rdieter> cool!
14:51:46 <Kevin_Kofler> Right now we ship both HTML and QCH apidocs for Qt, in the same subpackage, that's lame.
14:51:57 <Kevin_Kofler> The current Qt Assistant only uses the QCH.
14:52:15 <rdieter> I just question the idea of shipping these separately, would rather keep things simple
14:52:34 <Kevin_Kofler> I propose to build QCH docs at least for kdelibs, kdepimlibs and (depending on how easy it is) soprano, and to put it into separate subpackages.
14:52:34 <rdieter> but don't feel strongly about that
14:52:45 <Kevin_Kofler> For Qt, I'm not sure what to do.
14:52:58 <Kevin_Kofler> I'd also consider shipping only the QCH.
14:53:04 <jreznik> rdieter: you don't need both - so subpackage could be good idea
14:53:25 <Kevin_Kofler> It works in both Qt Assistant and KDevelop.
14:53:44 <Kevin_Kofler> And it doesn't bloat the repository metadata (filelist).
14:54:21 <Kevin_Kofler> rdieter: The reason why I want to separate the formats (or ship only one) is that those docs are huge and there's usually no reason to download them twice.
14:54:53 <Kevin_Kofler> For Qt, I'm a bit worried about the upgrade path though.
14:54:58 <Kevin_Kofler> (if I split the docs)
14:55:38 <rdieter> anyone else with an opinion ?
14:55:53 <rdieter> are the qch docs about the same size as html ones?  less?
14:56:07 <Kevin_Kofler> They're the HTML ones in some archive.
14:56:18 <Kevin_Kofler> I think they're about the same to download, but less to store.
14:57:32 <jreznik> Kevin_Kofler: that's why I don't understand why shipping both
14:57:42 <Kevin_Kofler> Looking at the qt-doc size, the HTML is about 3 times larger, and that's not counting file system slack (space wasted due to small files being rounded up to the next block size).
14:58:00 <Kevin_Kofler> jreznik: So you think we should be shipping only the QCH?
14:58:14 <rdieter> jreznik: qch is easier to use in qt/kde apps, and html is more easily accessible (via any browser)
14:58:24 <jreznik> rdieter: indeed
14:59:11 <jreznik> that's why I don't have an opinion - I like accessibility but we're shipping one thing twice
15:00:20 <Kevin_Kofler> Well, right now we're doing it only for Qt.
15:00:41 <Kevin_Kofler> But we really want QCH docs for the other Qt-based stuff, for both KDevelop and Qt Assistant.
15:00:45 <jreznik> ah, sorry... we're out of time -> #fedora-kde
15:01:01 <jreznik> #endmeeting