15:02:19 <rdieter_work> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-12-21
15:02:19 <zodbot> Meeting started Tue Dec 21 15:02:19 2010 UTC.  The chair is rdieter_work. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:24 <rdieter_work> #meetingname kde-sig
15:02:24 <zodbot> The meeting name has been set to 'kde-sig'
15:02:32 <rdieter_work> #topic roll call
15:02:36 <rdieter_work> who's present today?
15:03:08 <Kevin_Kofler> Present.
15:04:12 <rdieter_work> hmm... may be a quick meeting. :)
15:05:12 <thomasj> present now
15:05:49 * ltinkl just arrived
15:06:05 <rdieter_work> #info Kevin_Kofler thomasj ltinkl present
15:06:11 <rdieter_work> #char Kevin_Kofler thomasj ltinkl
15:06:16 <rdieter_work> #chair Kevin_Kofler  thomasj ltinkl
15:06:16 <zodbot> Current chairs: Kevin_Kofler ltinkl rdieter_work thomasj
15:06:18 <rdieter_work> even
15:07:09 <rdieter_work> #topic agenda
15:07:23 <rdieter_work> I tentatively added the kde46 feature, anything else to discuss today?
15:07:34 <ltinkl> oxygen-gtk anyone?
15:07:45 <ltinkl> the current status, etc.
15:07:58 <rdieter_work> ok
15:09:20 <thomasj> qtcurve-gtk3 will be ready for our release. I just need to package it over the holidays.  (forgot to report that last week.. busy busy busy)
15:09:27 <ltinkl> oh and the quick libreoffice-kde intro/status
15:09:53 * jreznik_n900 is here but from cell phone, in the city
15:10:03 <rdieter_work> thomasj: that's good news
15:10:14 <rdieter_work> #info jreznik_n900 present too
15:10:47 <rdieter_work> #topic qtcurve-gtk3 status
15:11:09 <rdieter_work> #info thomasj reports qtcurve-gtk3 will be ready for f15 release
15:11:13 <Kevin_Kofler> So they're already working on the new theming API?
15:11:14 <rdieter_work> just so it gets in the minutes
15:11:18 <thomasj> Yup :)
15:11:22 <rdieter_work> coolness
15:11:53 <Kevin_Kofler> I guess we should look at the diff of the changes, to see if we can port oxygen-gtk too if nobody else cares…
15:12:06 <Kevin_Kofler> (and bluecurve-gtk :-) )
15:12:12 <rdieter_work> thomasj: anything else qtcurve-related?
15:12:41 <thomasj> rdieter_work, nope, sorry. Developer is very active, but that's it for now.
15:12:53 <rdieter_work> ok, just wanted to make sure before moving on.
15:12:59 <rdieter_work> #topic oxygen-gtk status
15:13:08 <rdieter_work> .bug 663092
15:13:10 <zodbot> rdieter_work: Bug 663092 Review Request: oxygen-gtk - Oxygen GTK theme - https://bugzilla.redhat.com/show_bug.cgi?id=663092
15:13:14 <rdieter_work> I submitted this for review
15:13:39 <rdieter_work> and it's in kde-testing repo for feedback/testing
15:13:40 <ltinkl> great
15:13:53 <ltinkl> I just noticed they recently released 1.0 version
15:14:10 <rdieter_work> yep, that's what we packaged up
15:14:32 <rdieter_work> that's about it, reviews welcome
15:14:52 <rdieter_work> #info oxygen-gtk submitted for pkg review
15:15:16 <rdieter_work> #topic libreoffic-kde intro/status
15:15:18 <rdieter_work> ltinkl: ?
15:15:28 <ltinkl> short :)
15:15:29 <rdieter_work> (modulo my typos)
15:15:57 <ltinkl> I've been granted commit access to the libreoffice module, so I will start working on the libreoffice-kde subpackage after the xmas
15:16:19 <thomasj> whooo
15:16:37 <Kevin_Kofler> Great!
15:17:16 <ltinkl> I will shout if I need help, don't worry :)
15:17:27 <thomasj> hehe
15:17:56 <Kevin_Kofler> OK, next topic? :-)
15:18:18 <rdieter_work> #info ltinkl has been granted commit access to libreoffice module to work on -kde subpkg
15:18:37 <rdieter_work> #topic https://fedoraproject.org/wiki/Features/KDE46
15:18:54 <rdieter_work> our favorite, since we have nothing better yet to do. :)
15:19:06 <Kevin_Kofler> So what do we do about kdepim 4.6?
15:19:14 <Kevin_Kofler> It's getting delayed… yet again! :-(
15:19:40 * ltinkl just found out that his Novell/openSUSE build service account is still valid :D
15:19:45 <rdieter_work> good question.  I think we need to revert to kdepim-4.4.x for now, but I'm open to other suggestions
15:19:56 <Kevin_Kofler> My proposal: try for 4.6; if it isn't ready in time, bump Epoch and revert when F15 branches, as we did for F14.
15:20:09 <ltinkl> I'm against
15:20:18 <Kevin_Kofler> Against what?
15:20:41 <ltinkl> kdepim maintainer strongly advised against packaging kdepim 4.6 in its current state
15:20:51 <Kevin_Kofler> (Rationale for my proposal: At this time we need to bump Epoch anyway if we revert.)
15:21:10 <Kevin_Kofler> (So we can just as well keep the current stuff in Rawhide.)
15:21:23 <Kevin_Kofler> (Getting things tested is what Rawhide is for. If the testing fails, we revert.)
15:21:50 <jreznik_n900> for now, yea
15:21:56 <Kevin_Kofler> There's still some time until the F15 release.
15:22:08 <jreznik_n900> but we have to revert prior branching
15:22:29 <Kevin_Kofler> When do you propose to make the decision?
15:23:14 <jreznik_n900> now, until upstream says ship it
15:23:38 <Kevin_Kofler> So you propose to revert it now in Rawhide?
15:23:45 <jreznik_n900> not now
15:23:52 <rdieter_work> I think we need to wait until 4.4.9 lands before doing anything
15:24:04 <rdieter_work> that's what was said should work ok against kde-4.6
15:24:12 <Kevin_Kofler> Yeah, 4.4.8 is reported not to work so great with kdepimlibs 4.6.
15:24:29 <ltinkl> yup, wait for 4.4.9
15:24:32 <jreznik_n900> in rawhide we can watch the state
15:24:32 <rdieter_work> not sure how akonadi fits in here, whether that will require reverting or not (I'll ask for clarification)
15:24:48 <Kevin_Kofler> rdieter_work: AFAIK, we need the new Akonadi for the new kdepimlibs.
15:24:57 <ltinkl> but then again, I'd like to go the safer way here, eg. package kdepim 4.6 only when the upstream says so
15:25:09 <rdieter_work> ltinkl: agreed 100%
15:25:18 <Kevin_Kofler> I'd like to let Rawhide be Rawhide, and package prereleases as we ALWAYS do in Rawhide.
15:25:35 <ltinkl> yup, we need a newer akonadi tho, in either case
15:25:38 <ltinkl> for kdepimlibs
15:25:45 <Kevin_Kofler> So far there's no evidence that the release will not be in time for F15.
15:25:55 <Kevin_Kofler> (F15 releases later than KDE 4.6.0.)
15:26:14 <Kevin_Kofler> (That said, there's also no evidence that it WILL be in time. :-( )
15:26:21 <rdieter_work> Kevin_Kofler: sure, that's presuming: 1. what's in rawhide is testable/usable 2. a final/supportable release is available near f15 release
15:27:11 <rdieter_work> #info will revert rawhide to kdepim-4.4.9, when it's available
15:27:30 <Kevin_Kofler> I'm worried that if we revert now, we may end up 1. bumping Epoch for no good reason and 2. having to make a decision on whether to release a poorly-tested (by us) 4.6.x or a deprecated by upstream 4.4.9.
15:27:44 <rdieter_work> I forget when git branching occurs, we'll have to keep a kdepim-4.6.x branch or history around somewhere
15:28:02 <Kevin_Kofler> They won't be supporting 4.4.x forever. If they get 4.6.x working, they'll stop updating 4.4.x.
15:28:36 <Kevin_Kofler> I don't think we agreed on reverting Rawhide to 4.4.9 as soon as it's available…
15:28:43 <Kevin_Kofler> I'm against that proposal, in any case.
15:29:36 <Kevin_Kofler> I propose to revert in the F15 branch just after it branches, IF AND ONLY IF it's clear at that time that the first 4.6.x release will not be in time for us and the betas are not shippable.
15:29:54 <thomasj> +1 fwiw
15:30:08 <Kevin_Kofler> thomasj: +1 to what? To my proposal?
15:30:08 <ltinkl> they won't stop supporting 4.4
15:30:13 <thomasj> Kevin_Kofler, yes
15:30:59 <ltinkl> most of the kdepim devels work for KDAB and they have a contract with the german governement to support the kdepim 4.4 series
15:31:20 <Kevin_Kofler> The 4.4 series? Or enterprise4?
15:31:31 <thomasj> Should be enterprise 4
15:31:52 <Kevin_Kofler> Enterprise4 is more like 4.3 than 4.4!
15:31:52 <Kevin_Kofler> 4.4 has a partial Akonadi conversion (KAddressBook, in particular), enterprise4 has no Akonadi at all.
15:32:08 <ltinkl> so no, don't worry they will stop once kdepim 4.6 gets released
15:32:37 <Kevin_Kofler> (FWIW, we should have shipped at least KAddressBook from enterprise4, but it's too late for that now, downgrading is not really supported.)
15:32:38 <thomasj> Does it hurt us to wait with the epoch bump and reverting back?
15:32:53 <Kevin_Kofler> (KAddressBook from 4.4 sucks, 4.6 would be much better there!)
15:35:01 * Kevin_Kofler thinks we're getting way too conservative, misses the Fedora 9 era. :-(
15:35:35 <ltinkl> I am conservative about my mail :)
15:36:02 <Kevin_Kofler> We need to have some cool stuff so GNOME 3 doesn't get all the show. :-)
15:36:26 <thomasj> Well, it will get the show anyways
15:36:59 <Kevin_Kofler> If inbetween all the articles complaining about GNOME 3 breaking the desktop, there's one about KMail 2 eating all the reviewer's mail, we at least get some attention. ^^
15:37:13 <thomasj> lol
15:37:56 <rdieter_work> Kevin_Kofler: have you tried using kdepim-4.6.x stuff ?
15:38:15 <rdieter_work> (if not, I suggest you do, it may affect your opinion)
15:39:04 <thomasj> I would ship 4.6.x kdepim only when it's in a good shape (everything working as expected.
15:39:17 <thomasj> Currently it's not, not even close.
15:39:17 <Kevin_Kofler> I take it that your impression is that it's about at the state KDE 4.0 was in when we did F8?
15:39:30 <Kevin_Kofler> (i.e. no way it'll be ready in time)
15:39:40 <thomasj> But maybe they get it working in time. The only reason i say lets wait a bit.
15:40:11 <Kevin_Kofler> I also think that it's early to make a decision to revert.
15:40:15 <Kevin_Kofler> It may still get working.
15:40:27 <Kevin_Kofler> At this stage of F9 development, KDE 4.0 was very broken.
15:40:35 <Kevin_Kofler> We managed to ship it in a basically working state.
15:40:53 <rdieter_work> I tried using kdepim-4.6 a couple of times, never got it to work (at all). :(
15:41:13 <thomasj> FWIW, i have it 2working" but it hurts me often.
15:41:42 <rdieter_work> akonadi/nepomuk ground for several hours, but then I gave up
15:42:12 <thomasj> knode freezing while it's trying to get new news messages from gmane
15:42:24 <thomasj> kmail not really working well
15:42:35 * thomasj uses TB meanwhile
15:42:39 <rdieter_work> yeah, I'm speaking mostly about kmail here, other parts worked well
15:42:44 <Kevin_Kofler> Looks like quite broken…
15:43:04 <rdieter_work> Kevin_Kofler: now you know why some us are so keen on reverting. :)
15:43:04 <Kevin_Kofler> The big question is: How long do we expect upstream to take to fix this mess?
15:43:21 <Kevin_Kofler> Is there any chance it will be sorted out by the F15 release?
15:43:41 * rdieter_work is doubtful, but would be happy to be surprised
15:44:23 <thomasj> They seem to work hard on it. but obviously not enough manpower.
15:44:27 <Kevin_Kofler> Well, Rawhide not working at all was quite common during the KDE 3.9x.x period. ^^
15:44:55 <Kevin_Kofler> thomasj: Yeah, they keep slipping and slipping. :-(
15:45:02 <Kevin_Kofler> They just cannot make the targeted timeframes.
15:46:01 <Kevin_Kofler> And they call stuff "beta" which is at best of alpha quality.
15:46:17 <ltinkl> I definitely appreciate their self-criticism :)
15:46:31 <thomasj> yep
15:46:34 <ltinkl> better than releasing broken stuff and pretend everything is ok
15:46:46 <Kevin_Kofler> You mean like KDE 4.0.0? :-)
15:47:00 <Kevin_Kofler> It took until 4.0.3 or 4.0.4 to have something mostly working…
15:47:05 <ltinkl> their = kdepim devels, but ye, got the point :o)
15:47:36 <rdieter_work> one last thing, I just want to clarify our intent and support for 2 things:
15:47:42 <rdieter_work> 1.  increasing our spin size
15:47:48 <ltinkl> the 4.0.x series should have never gotten released imho
15:48:01 <ltinkl> (just a sidenote, personal opinion)
15:48:11 <Kevin_Kofler> Re increasing spin size: any news on the LZMA SquashFS front?
15:48:13 <thomasj> increasing spin size: +1000
15:48:13 <rdieter_work> 2.  switching default phonon backend to gstreamer (or vlc if it is ready/tested in time)
15:48:17 <Kevin_Kofler> Because IMHO that should affect our decision.
15:48:30 <Kevin_Kofler> We should only bump the spin size if it's really necessary.
15:49:02 <rdieter_work> Kevin_Kofler: I'll believe lzma when I see it, in the meantime, we will continue to maintain a kickstart file for a cd-sized image
15:49:19 <rdieter_work> (which we can switch to, if it comes to that)
15:49:21 <ltinkl> imho, everyone has a DVD drive these days, and those who don't (subnotebooks) can install from USB flash drives
15:49:28 <Kevin_Kofler> If we still don't get the LZMA stuff, we'll have little other choice than to bump the size.
15:49:29 <thomasj> Do we care about Dragon Player and it's special xine functions? If not vlc/gstreamer ftw
15:49:41 <ltinkl> so increasing the size shouldn't affect anyone
15:49:58 <rdieter_work> thomasj: dragon's xine stuff should be removed (or not required) anymore.
15:50:05 <thomasj> cool
15:50:15 <rdieter_work> apachelogger worked on making dragon+gst dvd playing work right
15:50:19 <Kevin_Kofler> Re Phonon, IMHO we should give GStreamer another try.
15:50:26 <thomasj> wooo
15:50:33 <rdieter_work> ok, I'll update the feature page accordingly
15:51:01 <Kevin_Kofler> The showstopper back then was PulseAudio-related breakage, this should be addressed now with the upstream PulseAudio integration.
15:51:04 <rdieter_work> secondary issue: we currently ship both xine/gst backends , should we continue that?
15:51:19 * rdieter_work is tempted to say no
15:51:26 <Kevin_Kofler> (I never got my old hacks to work reliably with Phonon-GStreamer, but they aren't needed anymore.)
15:51:48 <thomasj> If we switch to gst, get rid of xine
15:51:52 <Kevin_Kofler> rdieter_work: If we can build Dragon Player without xine-lib without losing features, then let's get xine-lib off the spin.
15:52:14 <rdieter_work> nod, agreed then.
15:52:16 <Kevin_Kofler> (I guess that also means we can't ship Kaffeine on the spin, but we aren't currently shipping it anyway.)
15:52:32 <rdieter_work> alright, any final thoughts before we wrap up?
15:52:54 <rdieter_work> #info confirm intent to ship ~1gb kde spin
15:52:54 <thomasj> Besides that you guys rock? Nope
15:53:19 <rdieter_work> #info confirm intent to switch to phonon-backend-gstreamer default
15:53:26 <Kevin_Kofler> Question about the spin size: What about targeting 800 MB? Rationale:
15:53:37 <Kevin_Kofler> 1. on 1 GiB USB sticks, you have room left for an overlay and
15:53:52 <rdieter_work> ok, let's shoot for 800mb is see how it goes.
15:53:57 <Kevin_Kofler> 2. there are oversized 800 MB CD-Rs (at least in Vienna there are places to buy them)
15:54:08 <rdieter_work> it's always easier to go bigger and add stuff, much harder to go the other way
15:54:41 <rdieter_work> #info clarification, first target a ~800mb size kde spin
15:54:54 <drago01> (<rant> some shops even sell this things called DVDs </rant>)
15:55:05 <Kevin_Kofler> If we ship a full GiB, you need at least a 2 GiB USB stick to have room for an overlay.
15:56:02 <rdieter_work> drago01: duly noted
15:56:27 <Kevin_Kofler> But if the consensus is to use 1 GiB, we'll do with that…
15:56:58 <rdieter_work> thanks everyone
15:56:58 <Kevin_Kofler> (But at that point I see little benefit over, say, 1.6-1.8 GiB, i.e. 2 GiB minus overlay, and fits equally well on a DVD.)
15:57:07 <rdieter_work> #endmeeting