14:08:02 <Kevin_Kofler> #startmeeting KDE SIG Meeting - https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-09-29
14:08:02 <zodbot> Meeting started Tue Sep 29 14:08:02 2009 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:08:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:08:28 <Kevin_Kofler> #chair than rdieter ltinkl jreznik SMParrish mathstuf
14:08:28 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl mathstuf rdieter than
14:08:45 <Kevin_Kofler> So, who's present? Me obviously. ;-) Who else?
14:08:52 * jreznik is here
14:08:53 * SMParrish here
14:08:58 * mefoster is here today ...
14:09:23 * ltinkl is here
14:09:39 <Kevin_Kofler> #chair mefoster
14:09:39 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl mathstuf mefoster rdieter than
14:09:41 * than is here
14:10:04 <Kevin_Kofler> What happened to rdieter? He was here a few minutes ago...
14:10:24 <ltinkl> dunno, I suppose some last-minute work issue
14:10:51 <Kevin_Kofler> Let's get started then?
14:11:05 <than> yes please
14:11:10 <Kevin_Kofler> #topic kde-sig steering committee
14:11:34 * thomasj is here
14:12:13 <Kevin_Kofler> So we had some discussion earlier on #fedora-kde about forming a formal steering committee to take contentious decisions so we know who exactly should be voting in such cases.
14:12:43 <Kevin_Kofler> The suggestion was to have a committee of 7 people, and a list of 7 was circulated.
14:13:27 <Kevin_Kofler> The problems are: how to legitimate the initial steering committee? And what should be the succession rules?
14:13:51 <than> i don't see the need for this.
14:14:15 <Kevin_Kofler> And should the initial people be allowed to keep their position as long as they want? What if we have many new contributors?
14:15:09 <than> imo it just complicates the desition
14:15:40 <Kevin_Kofler> than: Well, the reason this came up is that we have been unable to reach a decision on how to proceed with Phonon for something like 3 weeks, we're officially already frozen now, so we need a decision quickly.
14:15:51 <Kevin_Kofler> We need a way to make timely decisions and not defer them forever.
14:16:52 <Kevin_Kofler> But somehow I get a feeling that we won't be able to get a decision on this one either.
14:17:26 <Kevin_Kofler> For legitimation, I supposed I could get the list in front of FESCo and see if they approve it.
14:17:27 <jreznik> I understand why, but I don't have any clue how to solve this issues
14:17:53 <thomasj> A committee of 7 should get a decision ;)
14:18:10 <SMParrish> Dont think FESCo needs to get involved.  we should be able to govern ourselves
14:18:13 <jreznik> maybe leader, who will be pushing to decide things in time would be enough
14:18:19 <Kevin_Kofler> But going to FESCo is something we should only do once we can show that we all agree with the idea and just want it officialized.
14:18:37 * ltinkl doesn't see the need for FESCO's aproval either
14:19:07 <than> Kevin_Kofler,  FESCo doesn't have to do with the dicision in KD
14:19:12 <than> s/KD/KDE
14:19:49 <Kevin_Kofler> OK, so let's forget I brought up the F word. ;-)
14:20:12 <ltinkl> did you? :)
14:20:20 <jreznik> fkdesco :D
14:21:03 <than> i don't see the need to make the desition now, every user cann alway switch to xine-backend if the want
14:21:03 <Kevin_Kofler> I think one person taking decisions isn't going to make people happy.
14:21:24 <rdieter> sorry, got roped into an emergency staff meeting, back now.
14:21:37 <Kevin_Kofler> I mean, I'd volunteer to be the Kofler Dictator Emperor (KDE), but I think we need a more democratic approach. ;-)
14:21:48 <jreznik> Kevin_Kofler: not doing decision but pushing people to decide on time
14:21:53 <SMParrish> I think a steering committee is a good idea, creates a stucture for deciding issues, and gives new contributors an idea of who does what
14:22:02 <ltinkl> SMParrish: +1
14:22:39 <jreznik> SMParrish: but then you need rules for decision process
14:22:41 <jreznik> too
14:22:47 <ltinkl> than: we're not talking only about the Phonon issue, such decision making needs to be standardized for the future as well
14:23:07 <Kevin_Kofler> There's also the K3b/KOffice issue right now, and others may come up in the future.
14:23:13 <rdieter> ltinkl: indeed, phonon just highlights the need for it
14:23:28 <ltinkl> yup
14:23:29 <Kevin_Kofler> In the past, we had the default menu issue, that one was basically decided by an ad-hoc vote.
14:23:42 <Kevin_Kofler> Which ended up pretty close (1 vote).
14:23:52 <ltinkl> such issues that need decisions come pretty often imo
14:24:09 <Kevin_Kofler> And Phonon is similar now, so it's important to know who should be allowed to vote if we go for voting.
14:24:19 <Kevin_Kofler> And if not, I'd like to hear your suggestions for an alternate procedure.
14:24:39 <Kevin_Kofler> And I really don't think one of us deciding alone is going to be the solution.
14:24:51 <Kevin_Kofler> We all make mistakes.
14:24:57 <ltinkl> there is no better alternative imho :)
14:25:13 <than> Kevin_Kofler, i agree with you :)
14:25:26 <than> if we really need a steering committee, we should limt to 5 users on the list
14:25:34 <SMParrish> and we cant have a dictatorship or anarchy,  so voting is the only way
14:26:24 <SMParrish> i like Kevin's proposal  of 7   3 RH 4 Community
14:27:00 <rdieter> seems we've mostly agreed for the need here, bikeshedding on size next.    either 5 or 7 is ok with me, honestly, 7 seems a better fit, based on who we have as good candidates right now
14:27:47 <than> who will be on the list?
14:28:05 <jreznik> SMParrish: hh, there are even not 3 RH people working officially on KDE :)
14:28:05 <Kevin_Kofler> The 3 RH members are kinda obvious: than, ltinkl, jreznik
14:28:19 <than> me, lukas, jaroslav, rex, kevin and ?
14:28:30 <Kevin_Kofler> For the 4 community ones, I've suggested rdieter, svahl, SMParrish and myself.
14:29:02 <Kevin_Kofler> svahl as the live CD maintainer and SMParrish as the main triager and maintainer of kpackagekit and a few other packages.
14:29:24 <jreznik> +1 for svahl and SMParrish
14:29:42 <ltinkl> I agree on this list
14:29:57 <rdieter> agreed here too
14:30:19 <SMParrish> I do as well.  its a good well rounded list
14:30:51 <than> than, ltinkl, jreznik, svahl , SMParrish, kevin and rex are on the lis
14:30:52 <Kevin_Kofler> I hope mathstuf won't be angry for being left out. rdieter suggested him too, but 8 members would mean we could end up with 4:4 stalemates, so that's no good, and I think those 7 really need to be on there.
14:30:53 <jreznik> the list was fairly easy - but now issues - what next - how to nominate new member?
14:31:19 <mathstuf> Kevin_Kofler: no hard feelings; time squeeze lately anyways
14:31:42 <rdieter> jreznik: in the packaging committee we pretty much self-nominate (remaining committee members vote), we could do similar
14:31:47 <Kevin_Kofler> mathstuf: OK :-)
14:32:32 <Kevin_Kofler> rdieter: Agreed, I think an FPC-style approach is going to be the best solution.
14:32:50 <Kevin_Kofler> Elections aren't going to work without a clear way to define who's allowed to vote.
14:33:26 <Kevin_Kofler> So the FPC's self-renewing approach is probably the best at this point.
14:33:34 <jreznik> and how to make free space for nominated member? or we're going to grow to even numbers?
14:34:39 <rdieter> we can tackle that when the time comes.  For now, I'd recommend sticking with 7 and not growing.  meaning, someone would have to resign (or get kicked out) in order to add a new member
14:34:43 <than> jreznik, do we really need it?
14:35:06 <than> more people on the list will complicate the decition
14:35:20 <than> imo it doesn't make sense
14:36:49 <ltinkl> so we have the list of "deputies", let's move on? :)
14:36:51 <jreznik> how many votes do we need to accept decision?
14:36:59 <ltinkl> simple majority
14:37:09 <than> ltinkl, yes
14:37:13 <Kevin_Kofler> 7 members, so we need 4 +1 votes to pass a decision.
14:37:35 <ltinkl> but
14:37:50 <Kevin_Kofler> I guess we'll want to make things like in most Fedora committees where you need 4 votes even if people are missing.
14:37:58 <jreznik> and how many votes to be valid? at least 2/3 of members?
14:37:59 <ltinkl> what if there are only 4 members present in the voting? would 3 votes still be sufficient?
14:38:08 <rdieter> ltinkl: no
14:38:17 <ltinkl> ok :) that was my main concern
14:38:26 <rdieter> well, we could consider that, but I'd recommend against it, imo
14:38:33 <Kevin_Kofler> People who are not present can vote per e-mail, preferably before the meeting.
14:38:35 <jreznik> maybe we should vote by email - so even people not attending meeting can vote
14:38:59 <rdieter> either way is fine, let's be flexible
14:39:01 <Kevin_Kofler> Just do it like in FESCo: folks normally vote in the meeting, but you can vote per e-mail beforehand if you know you'll be missing.
14:39:21 <rdieter> we're trying to make decision making easier, not harder.  :)
14:39:26 <Kevin_Kofler> Of course if we can get to +4 by e-mails already, we don't have to bring the issue up in the meeting. :-)
14:39:26 <than> rdieter, +1
14:40:10 <Kevin_Kofler> For a vote to be valid, there need to be 4 +1 votes, period. If only 4 people are there, they can only pass decisions unanimously. If only 3 people are there, no voting can be held.
14:40:21 <jreznik> Kevin_Kofler: so that's I don't like voting before - the meeting is to talk about issue
14:40:46 <mathstuf> off to class
14:40:54 <Kevin_Kofler> But of course that's only where voting is actually necessary. We don't want to make decision making harder than now, we can still have our usual consensus decisions.
14:41:14 <Kevin_Kofler> Only if somebody calls for a vote, we need to have one.
14:41:29 <rdieter> I think we have some good groundwork set, can we move on now?
14:41:57 <Kevin_Kofler> jreznik: Voting before the meeting is only a fallback if you know you'll be missing.
14:42:11 <Kevin_Kofler> We can also take votes afterwards if we don't have enough votes during the meeting to decide either way.
14:42:24 <Kevin_Kofler> So you can read the log and base your mail-in vote on that.
14:43:43 <Kevin_Kofler> We just need to get 4 votes for one or the other solution in in some way.
14:44:02 <jreznik> ok, could someone summarize it somewhere to accept rules and let's move
14:44:19 <rdieter> jreznik: after meeting ok?
14:44:33 <rdieter> or did you want the summary now?
14:44:57 <jreznik> rdieter: probably after meeting - mailing list?
14:45:42 <Kevin_Kofler> #agreed The KDE SIG Steering Committee will be formed by (in alphabetical order): jreznik, Kevin_Kofler, ltinkl, rdieter, SMParrish, svahl, than.
14:46:03 <rdieter> cool, I can do that (eventually I can, unless someone beats me to it)
14:46:26 <Kevin_Kofler> #agreed 4 votes will be required to pass decisions where a vote is called for.
14:46:37 <jreznik> rdieter: yes please, some skilled guidelines writer should take care :D
14:46:59 <Kevin_Kofler> #action rdieter will summarize the exact rules.
14:47:09 * rdieter looks around for the mysterious referenced skilled writer  :)
14:47:30 * ltinkl stares back at rdieter :))
14:47:50 * rdieter concedes defeat
14:47:55 * Kevin_Kofler thinks we really need to move on. :-)
14:48:01 <rdieter> moveon++
14:48:05 <Kevin_Kofler> #topic k3b/koffice reverts, recommended by upstreams
14:48:25 <Kevin_Kofler> #link http://rdieter.livejournal.com/15770.html
14:48:33 <Kevin_Kofler> Some background there.
14:49:01 <Kevin_Kofler> This is a bit of a contentious decision, and it's needed really soon as F12 is theoretically already frozen.
14:49:20 <Kevin_Kofler> In the comments of that blog post, I brought up some reasons not to revert.
14:49:21 <rdieter> (sorry I blogged before having a thorough discussion)
14:49:43 <Kevin_Kofler> But there are also arguments in favor of a reversion.
14:49:48 <rdieter> having to make last minute decisions always suck
14:50:40 * jreznik does not use k3b anymore, so does not know the current state of it
14:50:48 <Kevin_Kofler> For K3b, Kubuntu appears to be shipping 1.66 alpha2 in Karmic too, and it seems to be fairly stable. There's a crash with ripping, but I think I already have a fix for that.
14:51:37 <Kevin_Kofler> For KOffice 2.1, it's already beta, not alpha, we've shipped other betas in the past, and in fact we're only on a beta in the first place because we decided not to ship 2.0.x (and that was probably the right decision).
14:51:54 <than> Kevin_Kofler, we are nit sure how stable the 1.66 really
14:52:01 <Kevin_Kofler> KOffice 2 is missing some apps, but we can ship a koffice1 SRPM with just those apps (which wouldn't be on the live CD).
14:52:16 <ltinkl> the k3b is not very stable from what I saw
14:52:19 <jreznik> KOffice developers are still saying that it's not ready for serious work
14:52:26 <ltinkl> same for KOffice
14:52:31 <underscores> indeed
14:52:31 <Kevin_Kofler> The main KOffice apps are all in 2.1 and we'd ship the latest version.
14:53:03 * ltinkl will brb
14:53:27 * thomasj uses the beta for work.. cant say if it's serious work.. but for his business
14:53:30 <Kevin_Kofler> All the work on things like better ODF compatibility across all programs, improving KFormula etc. is all focused on 2.x, 1.6 is a dead codebase.
14:54:36 <jreznik> there's one reason why to ship ko2 for me - krita
14:54:56 <Kevin_Kofler> On the other hand, I'll admit I did exactly zero testing of the new K3b and KOffice.
14:55:16 <Kevin_Kofler> jreznik: Yeah, that one has improved a lot too.
14:55:43 <rdieter> running short on time, I'd call for voting on these items (separately?)
14:55:57 <jreznik> separately
14:56:04 <jreznik> but I'm not sure how to vote
14:56:24 <SMParrish> FYI 3 k3b bugs in rawhide  but 2 are related to genisoimage and k3b itself
14:56:33 <Kevin_Kofler> The problem with separate votes is that the benefit of not reverting is lower if we don't keep both KDE 4 versions.
14:56:45 <than> sebastian knows very well the current state of k3b if he means k3b-1.66 is not ready for consumption
14:56:45 <Kevin_Kofler> (We'd still drag in the KDE 3 stuff onto the live image.)
14:57:01 <than> it's unstable
14:57:03 <rdieter> Proposal for vote:  revert to (kde3) k3b-1.0.x and koffice-1.6.x for F-12
14:57:24 * rdieter doubts anyone voting would do so differently for each, but if so, please comment
14:57:28 <than> it's not good to  ship this version in F12 release
14:57:31 <Kevin_Kofler> -1, for the reasons already detailed
14:57:35 <rdieter> +1
14:57:47 <ltinkl> +1 (revert
14:57:50 <Kevin_Kofler> than: I assume that's a +1 to reverting?
14:58:03 <than> +1 to reverting
14:58:35 <ltinkl> SMParrish, jreznik: ?
14:59:01 <SMParrish> -1  if there are issues no one is filing bugs about them
14:59:31 <ltinkl> jreznik: it's in your hands :)
14:59:43 <Kevin_Kofler> Yeah, why should we revert based on fictional bugs nobody runs into?
15:00:04 <Kevin_Kofler> And do we really want to ship an older K3b than Kubuntu?
15:00:05 * jreznik is not sure - does not use it...
15:00:31 <than> Kevin_Kofler, the most users still use the stable k3b
15:00:50 <jreznik> I'd like to see new KO2 but as developers says it's not ready... last time I had something in my hands - I've tested it...
15:00:51 * rdieter thinks upstream developers know best, better than we can conjecture about
15:01:00 <than> it's no wonder why there's no report in bugzilla
15:01:02 <thomasj> Can i open files created with KO2 in KO1?
15:01:03 <Kevin_Kofler> Kubuntu Karmic will apparently be shipping 1.66 only, Mandriva seems to be already shipping it.
15:01:22 <jreznik> but with policy - we do what upstream says +1 to revert
15:01:27 <Kevin_Kofler> thomasj: For the stuff which uses ODF, yes, but formatting may be broken.
15:01:29 <rdieter> thomasj: good question
15:01:31 <Kevin_Kofler> For Krita, I don't know.
15:01:37 <thomasj> I use KO2 for my business
15:01:47 <thomasj> Well, no F12 for me then
15:01:56 <than> Kevin_Kofler, we don't have to do what Mandrake does
15:01:56 <thomasj> No big deal
15:01:57 <rdieter> thomasj: don't worry,we'll continue to provide ko2 at least unofficially
15:02:05 <thomasj> rdieter, ok, thanks
15:02:06 <jreznik> thomasj: redhat-kde repo
15:02:30 <ltinkl> rdieter: we have a winrar :)
15:02:33 <than> Kevin_Kofler,  It's not what sebasian wants
15:02:40 <rdieter> ok, looks like proposal passes, move on?  (though we're close to out of time)
15:03:13 <Kevin_Kofler> Well, I don't think we have any intention to change our votes, so that'd mean it passes 4:2.
15:03:27 <Kevin_Kofler> We could solicit svahl's opinion by e-mail for the record, but it won't change the outcome.
15:04:26 <Kevin_Kofler> But he told us he already has a plan to make room on the live image for kdelibs3, so we need not worry about that.
15:04:39 <rdieter> bugzappers, yell at us to clear out if you're ready (sorry)
15:04:41 <Kevin_Kofler> I still think it's a missed opportunity not to go pure KDE 4 now, but the majority has spoken.
15:04:46 * jreznik would like to see kdelibs3 free image...
15:05:07 <Kevin_Kofler> #agreed F12 will revert to (kde3) k3b-1.0.x and koffice-1.6.x for F-12 (passed 4:2).
15:05:12 <ltinkl> yup me too but ppl should realize there is life after F12
15:05:19 <Kevin_Kofler> jreznik: Are you changing your vote then?
15:05:25 <ltinkl> Kevin_Kofler: :)))
15:05:30 <than> Kevin_Kofler, :)
15:05:43 <jreznik> Kevin_Kofler: but we have fedora-kde repo, we can concentrate on more stable system - even with kdelibs3
15:05:43 <ltinkl> he isn't changing his vote, move on :DD
15:06:04 <jreznik> sorry redhat-kde repo
15:06:08 <Kevin_Kofler> #topic future of Phonon
15:06:16 <Kevin_Kofler> #info upstream (sandsmark) recommends building/packaging phonon from qt, and building/packaging backends separately
15:06:20 <ltinkl> do we have time for this discussion here? :)
15:06:27 <Kevin_Kofler> #info mandriva developments integrating pulseaudio support (and improving gstreamer backend)
15:06:32 <Kevin_Kofler> #link http://mail.kde.org/pipermail/phonon-backends/2009-September/000304.html
15:06:34 <jreznik> Kevin_Kofler: -> fedora-devel mailing list
15:06:35 <ltinkl> or should we move back to our channel
15:06:50 <Kevin_Kofler> #link http://colin.guthr.ie/git/phonon/log/?h=pulse
15:06:57 <jreznik> I've just sent it there (after rdieter approval)
15:07:06 * ltinkl somehow feels this will be lengthy and painful
15:07:24 <rdieter> there's really no time to wait, honestly, we need a decision, like yesterday
15:07:52 <rdieter> I'd propose a slightly different tack, esp based on recent phonon list developments,
15:08:48 <rdieter> well, I was about to suggest going back to kde/phonon completely, would allow us to more easily benefit from and cherry pick from mandriva's ongoing work
15:08:49 <Kevin_Kofler> Proposal: revert to the F11 style of Phonon packaging: standalone Phonon, phonon-backend-xine by default, but build Qt against GStreamer so qtconfig-qt4 can set up Phonon-GStreamer. (We have both GStreamer and xine-lib on the live image anyway.)
15:09:05 <Kevin_Kofler> rdieter: Yeah, that's my proposal too.
15:09:09 <rdieter> ok
15:09:26 <Kevin_Kofler> A standalone Phonon SRPM allows us to ship whatever Phonon we want or need to ship, without relying on what Qt ships.
15:09:32 <rdieter> +1
15:09:38 <than> -1
15:09:39 <Kevin_Kofler> +1 from me obviously
15:10:02 <SMParrish> +1
15:10:24 <ltinkl> a standalone phonon seems ok to me, esp, given the benefits of putting in mandriva's work
15:10:35 <ltinkl> but I'd go with gstreamer as the default backend
15:10:46 <ltinkl> (I've stated the reasons many times before)
15:10:51 * jreznik agrees with ltinkl
15:11:07 <Kevin_Kofler> That makes +3 -3.
15:11:27 <Kevin_Kofler> Ask svahl by mail for the deciding vote?
15:11:42 <ltinkl> Kevin_Kofler: where do you take those numbers from :)
15:11:43 <rdieter> ok, I think we can consider the standalone part of the proposal a success, the default backend hinging on svahl's vote
15:12:00 <ltinkl> yup
15:12:02 <Kevin_Kofler> rdieter: Right.
15:12:32 <Kevin_Kofler> #agreed We will move back to building a standalone phonon SRPM.
15:13:01 <Kevin_Kofler> #info The vote for the default backend is split 3:3, needs the 7th vote from svahl.
15:13:28 <than> Kevin_Kofler, does it we drop phonon part from qt?
15:13:40 <than> s/does it/ does it mean
15:13:50 <Kevin_Kofler> Yes, like we did in the past.
15:13:56 <Kevin_Kofler> The real upstream for Phonon is not Qt.
15:13:58 <than> it's bad
15:14:18 <Kevin_Kofler> It's good because it allows us to switch to any Phonon branch, like the Mandriva one, or upstream trunk.
15:14:28 <Kevin_Kofler> We don't have to wait for Qt to switch or use a huge patch.
15:14:39 <than> the qt/phonon upstreamer recommend to use the part in qt
15:14:52 <than> why do we drop it?
15:15:02 <rdieter> than: that was the lesser of his recommendations honestly (xine being the stronger one)
15:15:35 <Kevin_Kofler> And he also recommended building both backends from the Phonon tarball, even the GStreamer one.
15:16:19 <jreznik> more alive stack is better - question is backward compatibility for Qt only apps
15:16:21 <Kevin_Kofler> At that point, I think we can just as well use the Phonon tarball throughout, that way the library will always match the backends and we can more easily switch to another branch.
15:16:26 <than> rdieter, which GStreamer-backend will be dropped?
15:16:42 <rdieter> nothing will be dropped
15:17:01 <than> we wil have 2 phonon gstreamer-backend?
15:17:05 <Kevin_Kofler> The GStreamer backend in the Phonon tarball is the same one as the one in qt.
15:17:26 <Kevin_Kofler> Except it seems to be a newer version, at least in phonon trunk.
15:17:28 <rdieter> oh, phonon-backend-gstreamer will be dropped from qt packaging, yes
15:17:35 <rdieter> added back to phonon packaging
15:17:40 <Kevin_Kofler> We'll just ship the version from phonon.
15:17:43 <than> Kevin_Kofler, i know, why do  we have to use the one in phonon/KDE
15:17:47 <rdieter> let's clear out , we're over time
15:17:58 <Kevin_Kofler> Because that's what upstream recommended.
15:18:07 <than> it's easier to add the gstreamer patches to Qt
15:18:07 <Kevin_Kofler> And because it's newer and has features KDE 4.4 will need.
15:18:32 <than> but not Trolltech
15:18:32 <Kevin_Kofler> Why would we patch the copy in Qt with a huge patch as opposed to just packaging the tarball which already has the correct version?
15:19:25 <ltinkl> I think it's really easier to take the Phonon tarballs from KDE, esp. since that's where the development happens
15:19:45 <than> Kevin_Kofler, using the phonon snapshot is not good idea
15:19:53 <than> it could break the Qt
15:20:29 <Kevin_Kofler> We don't use a snapshot in F12, we use the stable tarball.
15:20:45 <Kevin_Kofler> But for F13, we're going to consider the Mandriva branch for sure.
15:21:06 <than> Kevin_Kofler, it's better to use Qt part in this case
15:21:12 <Kevin_Kofler> They're working on PulseAudio integration in both backends and they may also have some GStreamer backend bugfixes there.
15:21:46 <adamw> any end in sight, guys? btw, I vote for whatever colin guthrie does =)
15:21:54 <ltinkl> lol
15:22:04 <adamw> dude's good
15:22:27 <ltinkl> ye, it seems he's done a pile of impressive work there
15:22:29 <Kevin_Kofler> adamw: We really want to ship his Phonon branch, but not in F12 as it's under heavy development and F12 is in feature freeze. ;-)
15:23:16 <Kevin_Kofler> He's working on having PulseAudio sources/sinks show up in Phonon as devices instead of the one "PulseAudio" device which goes to the default sink.
15:23:22 <adamw> ah, right.
15:23:30 <adamw> but yeah, bz is waiting for the channel...sorry to rush you
15:23:54 <rdieter> yes, we're *way* over time, we should clear out, Kevin_Kofler, end meeting please
15:24:03 <Kevin_Kofler> I think we have made our decisions, for any followups, please see #fedora-kde!
15:24:07 <Kevin_Kofler> Or the fedora-kde ML.
15:24:14 <Kevin_Kofler> #endmeeting