14:00:21 <rdieter> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-13 14:00:21 <zodbot> Meeting started Tue Jul 13 14:00:21 2010 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:27 <rdieter> #meetingname kde-sig 14:00:27 <zodbot> The meeting name has been set to 'kde-sig' 14:00:36 <rdieter> #topic roll call 14:00:39 <rdieter> who's present today? 14:00:51 * rnovacek here 14:01:02 <rdieter> than, ltinkl, jreznik, Kevin_Kofler, smparrish, kde*foo : ping 14:01:02 * smparrish here 14:01:03 * jreznik is here 14:01:08 * ltinkl is here 14:01:14 * than is present 14:01:46 <Kevin_Kofler> Present. 14:01:51 <rdieter> #info rdieter rnovacek smparrish jreznik ltinkl than Kevin_Kofler present 14:01:57 <rdieter> #chair rnovacek smparrish jreznik ltinkl than Kevin_Kofler 14:01:57 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rdieter rnovacek smparrish than 14:02:12 <rdieter> #topic agenda 14:02:20 <rdieter> http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-07-13#Agenda 14:02:29 <rdieter> anything to add to the agenda for today? 14:02:46 <rdieter> (otherwise, looks like we'll have plenty to discuss) 14:03:04 <ltinkl> yes, first point: welcome rnovacek :) 14:03:16 * cwickert is here too 14:03:21 <rnovacek> ltinkl: thank you 14:03:52 <rdieter> #info cwickert present 14:04:12 <rdieter> #topic kde-sig welcomes rnovacek 14:04:20 * maxamillion is kinda here 14:04:21 <rdieter> rnovacek: indeed, welcome 14:04:39 <rdieter> #info maxamillion (kinda) present :) 14:04:50 <Kevin_Kofler> Welcome rnovacek! :-) 14:04:52 <maxamillion> rdieter: rnovacek the one the "who the hell is <name I forgot>?" email was about? 14:04:58 <rdieter> maxamillion: yes 14:05:02 <maxamillion> awesome! 14:05:03 <smparrish> rnovacek: Welcome 14:05:06 <maxamillion> rnovacek: welcome!! :) 14:05:15 <rnovacek> thanks to you all ;) 14:05:23 <than> rnovacek: welcome 14:05:38 <rdieter> rnovacek: thanks already for the bz triage, earned our gratitude already. 14:05:40 <jreznik> rnovacek is already helping us a lot, just in the shadow ;-) 14:06:11 <rnovacek> rdieter: I'm not finished with it yet :) 14:06:48 <rdieter> alright, let's get started on the juicy stuff 14:06:53 <smparrish> rnovacek: Yes BIG thanks on that, my time for it has been scarce these past few weeks 14:07:19 <rdieter> #topic http://fedoraproject.org/wiki/Features/KDE45 14:08:06 <rdieter> Not too thrilling, but please look over the kde45 feature page, in case there's anything obviously wrong or missing 14:08:18 <ltinkl> thanks to Rex who has initially copied over the KDE44 feature as a template 14:08:25 <cwickert> erm, do we follow the agenda from top to bottom? is kdepim a topic of it's own? 14:08:34 * rdieter has mad copy-n-paste skillz 14:08:40 <ltinkl> cwickert: will come next :) 14:08:55 <cwickert> ok 14:09:00 <rdieter> sorry, I took the liberty of ordering (what I consider to be) import stuff first 14:09:11 <ltinkl> ** kde-plasma-networkmanagement by default 14:09:20 <Kevin_Kofler> Well, I put kdepim first because I consider it more important. ;-) But whatever. 14:09:23 <ltinkl> have we agreed on that already? 14:09:36 <Kevin_Kofler> ltinkl: IMHO it's obvious. 14:09:36 <rdieter> ltinkl: yes (I thought so) 14:09:39 <Kevin_Kofler> knetworkmanager is deprecated. 14:09:46 <Kevin_Kofler> The plasmoid is the way to go now. 14:09:52 <ltinkl> I mean, default as in replace nm-applet 14:09:52 <Kevin_Kofler> So let's default to the plasmoid from now on. 14:10:00 <Kevin_Kofler> We already replaced nm-applet in F13. 14:10:05 <ltinkl> (not that I'm against it) 14:10:33 <maxamillion> +1 for the plasmoid, knetworkmanager is kinda crufty 14:10:37 <ltinkl> umm, on LiveCD only? 14:10:48 <Kevin_Kofler> On KDE installs. 14:11:03 <Kevin_Kofler> Also nm-applet does not by default autostart in KDE if installed (since F13). 14:11:10 <ltinkl> I still have the nm-applet here as the default :) 14:11:13 * ltinkl wonders why 14:11:22 <rdieter> ok, one related question there, for f14+ do we even want to ship monolithic knetworkmanager at all? 14:11:31 <ltinkl> rdieter: I'd say not 14:11:44 <Kevin_Kofler> I'd say ship it, but disable autostart by default. 14:11:45 <ltinkl> rdieter: can it be left out at compile stage? 14:11:58 <Kevin_Kofler> And don't put it on the live CD, only ship it in the repo. 14:12:07 <rdieter> besides, there's currenlty a problem missing kde45's dbusmenu-qt and knm anyway 14:12:07 <poelcat> /win move 5 14:12:10 <ltinkl> sounds ok 14:12:19 <rdieter> s/missing/with/ meh 14:12:41 <rdieter> it can be left out or autostart disabled. 14:12:43 <Kevin_Kofler> But if you want to discontinue it entirely, I guess we can do that, too. 14:12:55 <ltinkl> anyone against making the applet default? jreznik, than, rnovacek? 14:12:56 <smparrish> I would say leave it out entirely 14:12:57 <Kevin_Kofler> Upstream seems to have decided that the plasmoid is the way to go these days. 14:13:01 <rdieter> I'd tend to provide it for those who want/need it (agreeing with Kevin_Kofler) 14:13:14 <rdieter> but meh. 14:13:18 <rnovacek> I'm for applet 14:13:31 <Kevin_Kofler> I also think shipping knm as a non-default option in the repo can't hurt. 14:13:34 <rdieter> how about this, ask upstream. if they truely want knm deprecated, then omit it 14:13:40 <Kevin_Kofler> But the plasmoid is the way to go for default. 14:13:43 <Kevin_Kofler> rdieter: Good idea. 14:13:48 <ltinkl> yup 14:14:16 <rdieter> #action rdieter to consult knm upstream about future of monolithic client 14:14:18 <than> we should ask upstream first 14:14:25 <than> before makinf decision 14:14:41 <rdieter> anything else wrt kde45 feature? 14:14:53 <ltinkl> anything else to add? 14:15:12 <rdieter> not sure if it's worth mentiong qt47 here, it's not required by kde45 14:15:26 <ltinkl> but we will base KDE on it, right? 14:15:39 <rdieter> it could almost be mentioned as a separate feature, <shrug> 14:15:52 <rdieter> so, may as well include it here I guess 14:15:52 <ltinkl> btw, what is the state of phonon-vlc? 14:16:15 <jreznik> rdieter: it can be combined in one feature page 14:16:15 <Kevin_Kofler> Unlikely to make F14, I'm afraid. 14:16:17 <jreznik> today is deadline 14:16:33 <rdieter> ltinkl: still largely experimental (support for vlc-1.1 is still evolving anyway) 14:16:40 <Kevin_Kofler> Phonon-VLC is not ready for production upstream, nor is our VLC packaging going along for Fedora. 14:16:46 <rdieter> Kevin_Kofler: +1 14:17:14 <ltinkl> ye I thought the legal issues with packaging might be a problem 14:17:31 <Kevin_Kofler> ltinkl: That, and also the usability of phonon-vlc itself. 14:17:38 <Kevin_Kofler> Sho_ says there are crashes. 14:17:38 <rdieter> ltinkl: the legal blockers are resolved, just the pkg review is moving a bit slowly 14:18:02 <ltinkl> k, let's move onto kdepim 14:18:05 <rdieter> kwizart's attention/focus is getting vlc-1.1.x in shape for rpmfusion 14:18:06 <Kevin_Kofler> rdieter: Another thing is that phonon-vlc should not depend on vlc the app, only the libs. 14:18:14 <Kevin_Kofler> So vlc should get split properly according to that as well. 14:18:31 <rdieter> Kevin_Kofler: that too, though it only pulls in vlc-core atm, not vlc itself 14:18:49 <rdieter> alright, let's move on 14:18:56 <Kevin_Kofler> Also, kwizart absolutely wants libva support in vlc 1.1, and libva has been blocked under FE-LEGAL for a while. 14:19:02 <Kevin_Kofler> Now he's getting libva into RPM Fusion. 14:19:15 <Kevin_Kofler> But that means he won't like having to build vlc without libva to move it into Fedora. :-( 14:19:25 <rdieter> ok, that's definitely a related problem, not sure if that affects the core library, or just plugins 14:19:46 <rdieter> :( alright 14:19:48 <Kevin_Kofler> He's not updating vlc in RPM Fusion before he has libva. 14:19:54 <rdieter> #topic kdepim 4.5 in Rawhide 14:20:02 <Kevin_Kofler> I think we could do fine without libva. 14:20:53 <rdieter> ok, kdepim-4.5 beta/prereleases for rawhide, who's topic is this? 14:21:03 <Kevin_Kofler> Well, I put it on the schedule. 14:21:15 <Kevin_Kofler> This is really an important decision. 14:21:23 <cwickert> IMO rawhide is not the question, the question is about F14 14:21:27 <Kevin_Kofler> Do we want to ship kdepim 4.5 in F14? 14:21:39 <Kevin_Kofler> cwickert: Well, if we want it in F14, we'll need to import it into Rawhide ASAP. 14:21:47 <rdieter> excellent question alright. 14:21:53 <Kevin_Kofler> If we don't want it in F14, then we should only import it after F14 branches. 14:21:54 <cwickert> and if not, what do we do in the F14 cycle? 14:22:07 <cwickert> we cannot update it during the release because of the stable release vision 14:22:10 <Kevin_Kofler> IMHO, we should put 4.5 into F14. 14:22:13 <cwickert> +1 14:22:23 <cwickert> this means having it in rawhide ASAP 14:22:28 <Kevin_Kofler> If upstream doesn't release the final version on time, we ship whatever prerelease is there. 14:22:32 <cwickert> +1 14:22:37 <ltinkl> I'm not sure if kdepim 4.5 stabilizes enough for F14 14:22:38 <Kevin_Kofler> As we did for other stuff. 14:22:48 <cwickert> ltinkl: upstream says yes 14:22:49 <rdieter> ltinkl: that's my concern too 14:23:07 <Kevin_Kofler> We already have something in devel CVS, we should put it into Rawhide now. 14:23:13 <ltinkl> cwickert: they can't say yes, that is nonsense :) nobody has a crystal ball 14:23:18 <Kevin_Kofler> Then track the prereleases from now until the F14 release. 14:23:40 <rdieter> I'd propose something similar as in the knm case, someone take the task to consult with kdepim upstream on their opinion on it's readiness in time for f14 development cycle 14:23:42 <cwickert> ltinkl: it's not magic, they are working on it very hard 14:23:51 <than> it's to early to have kdepim 4.5 in f14 14:23:56 <Kevin_Kofler> And if we don't have a final release by the F14 release, we should be able to push it as an update, it's clearly a bugfix, so I don't think anybody will complain, new update policies or not. 14:23:58 <ltinkl> cwickert: I'm not saying they aren't 14:24:06 <than> how stable is it` 14:24:15 <Kevin_Kofler> (a bugfix compared to the prereleases, I mean) 14:24:20 <ltinkl> than: right now pretty unfinished 14:24:36 <Kevin_Kofler> rdieter: We don't have much time. 14:24:49 <Kevin_Kofler> cwickert says we should write a feature page, the deadline for that is today. 14:24:50 <ltinkl> remember even upstream can change their plans in 1 month or 2 14:24:50 <smparrish> I would like to see it in F14, but concerned about stability and testing time 14:24:55 <Kevin_Kofler> And feature freeze is in 2 weeks. 14:25:02 <Kevin_Kofler> I think that if we want it, we should import it NOW. 14:25:04 <than> ltinkl: i'm strong against shipping kdepim 4.5 in f14 14:25:05 <cwickert> than: the big question is: what if we don't ship it in F14 and then it comes with KDE 4.5.1 or 4.5.2 do we want to build kdepim 4.4 again? 14:25:28 <rdieter> cwickert: the anwer to that question is yes, stick with 4.4 14:25:37 <rdieter> answer 14:25:49 <Kevin_Kofler> cwickert: Yeah, plus, 4.4 is a pretty much temporary migration release, in the middle of the Akonadi migration. 14:25:50 <cwickert> but this will slow down the KDE 4.5.x updates 14:25:58 <Kevin_Kofler> So there's KAddressBook using Akonadi and the rest not. 14:26:05 <jreznik> than: +1 14:26:10 <cwickert> +1 Kevin_Kofler, I doubt 4.5 will be worse than 4.4 14:26:11 <rdieter> cwickert: how so? 14:26:20 <rnovacek> I think usage pim is crucial for most users 14:26:47 <rnovacek> so I'm +1 for stick with 4.4 14:26:49 <cwickert> rdieter: I#am afraid it will require extra work. what is kdepim 4.4. doesn't build with 4.5 libs? 14:26:55 <rdieter> anyway, how about we not get ahead of ourselves, with second guessing on if it'll be ready for us or not. 14:26:56 * ltinkl sees a voting inevitable :) 14:27:06 <Kevin_Kofler> I'm for putting kdepim 4.5 (back) into Rawhide and kde-unstable ASAP and shipping whatever prerelease will be current at release time in F14. 14:27:10 <rdieter> cwickert: devs have said they are committed to kdepim-4.4.x being compat with kde-4.5 runtime 14:27:14 <rnovacek> and have 4.5 in kde-redhat for deeper testing... 14:27:26 <jreznik> ltinkl: it's about voting - even upstream is scared from data migration issues 14:27:32 <jreznik> and PIM is all about DATA 14:27:42 <Kevin_Kofler> I'm also worried about the KDE 4.6 update, which I'm sure we'll provide one way or the other. 14:27:47 <cwickert> rdieter: only the e5 branch, not head 14:27:51 <ltinkl> exactly for that reason I am strongly against kdepim 4.5 in F14 14:28:01 <rdieter> cwickert: that's not the message I got 14:28:02 <Kevin_Kofler> (be it in updates, "updates-features" or whatever it will be called, kde-redhat stable or wherever) 14:28:23 <ltinkl> we can try to build kdepim 4.5 in the kde-redhat repos for testing 14:28:23 <Kevin_Kofler> Upgrading kdepim from 4.4 to 4.6 mid-release might cause a lot of disruption. 14:28:31 <cwickert> rdieter: I'm sitting next to many people, so I consider my info up to date 14:28:34 <Kevin_Kofler> 4.5 to 4.6 is going to be a much smaller change. 14:28:54 <rdieter> cwickert: ok, I'm going off the mails sent to the kde release team from winterz 14:29:08 <Kevin_Kofler> It'll be much simpler to upgrade to 4.6 from 4.5 than from 4.4. 14:29:19 <rdieter> I'll try pinging him (or other kdepim devs) after meeting to get their take on whether we should include it. 14:29:31 <rdieter> any objections? (or counter-proposals)? 14:29:42 <jreznik> Kevin_Kofler: but then mayby data migration will work in time of 4.6 14:29:59 <Kevin_Kofler> cwickert: You're confused. 14:30:02 <cwickert> as long as it's not a feature of it's own, we don't need to decide today 14:30:07 <Kevin_Kofler> 4.4 is neither e5 nor head. 14:30:08 <cwickert> Kevin_Kofler: ? 14:30:24 <Kevin_Kofler> e5, 4.5 and trunk are all Akonadi-based. 14:30:25 <cwickert> Kevin_Kofler: I know 14:30:29 <Kevin_Kofler> 4.4 is the last non-Akonadi branch. 14:30:33 <cwickert> yes 14:30:46 <Kevin_Kofler> The compatibility question here is about kdepim 4.4 and KDE 4.5 libs. 14:30:57 <cwickert> right, that's what I said 14:30:57 <Kevin_Kofler> This should fall under library backwards compatibility. 14:31:01 <Kevin_Kofler> i.e. of course it's compatible. 14:31:12 <Kevin_Kofler> If not, it's a bug in kdelibs or kdepimlibs. 14:31:25 <cwickert> I don't think they will work on the 4.4 branch later in order to vierfy it still builds 14:31:27 <Kevin_Kofler> The libs are expected to be compatible with older apps. 14:31:39 <ltinkl> cwickert: it will build 14:31:53 <ltinkl> kdelibs stay BC 14:32:25 <cwickert> anyway, we cannot complain about kdepim lagging behind all the rest of KDE and not providing testing. 14:32:28 <Kevin_Kofler> Building 4.4 forever is not what I'm worried about. 14:32:48 <Kevin_Kofler> Having the choice between being stuck on 4.4 forever or forcing a scary update on users is what I'm worried about. 14:33:08 <Kevin_Kofler> 4.5 leaves users with a straight upgrade path to newer Akonadi-based releases. 14:33:08 <ltinkl> Kevin_Kofler: not forever, life doesn't end with F14 14:33:18 <cwickert> kdepim is now in a state where it can be tested, by october it will be in a state where it can be deployed to people. having it in F14 is a great chance of getting more testers 14:33:31 <Kevin_Kofler> ltinkl: "forever" in the context of F14, i.e. until its EOL. 14:33:56 <Kevin_Kofler> Plus, I'm worried that we'll get burned by other distros again as for K3b. 14:34:06 <ltinkl> you can't tell it will be ready by October... 14:34:06 <Kevin_Kofler> One of our core objectives is to be the first ones to ship new stuff. 14:34:29 <ltinkl> k3b is different... and much smaller 14:34:50 <Kevin_Kofler> ltinkl: Do you know what other distros are planning to do re kdepim? 14:35:00 <ltinkl> kdepim is very complex and has a large source code base, lots of apps are interconnected, etc... 14:35:03 * rdieter ping'd winterz in #kontact for his opinion 14:35:18 <rnovacek> there is no migration problem with k3b, so it's different 14:35:27 <cwickert> ltinkl: F14 will be supported until november 2011 which is KDE 4.7.something. you really think that kdepim 4.4 will still build then? 14:35:41 <ltinkl> yes, that as well: k3b doesn't need to migrate (important!) data 14:36:14 <ltinkl> cwickert: yes, against 4.5 14:36:17 <Kevin_Kofler> Migration being troublesome is exactly why it's better to have 4.5 in F14. 14:36:22 <than> Kevin_Kofler: k3b was small kde apps and is easy to update 14:36:37 <cwickert> ltinkl: this basically means we don't ship any more updates for F14, correct? 14:36:38 <Kevin_Kofler> Because then there's no migration to worry about for users when going to 4.6+. 14:36:40 <than> kdepim is core component in KDE 14:37:06 <jreznik> Kevin_Kofler: I'm not sure they finnish it before 4.6 14:37:13 <ltinkl> I thought we have learned from the KDE 3 -> KDE 4 disaster in kdepim... 14:37:18 <than> i think we need to vote for kdepim 14:37:26 <jreznik> it's not stuff for 4.5.x 14:37:27 <ltinkl> this is a similar situation 14:37:29 <than> please let start to vote 14:37:34 <Kevin_Kofler> ltinkl: Disaster? F9 was a success! 14:37:42 <jreznik> than: I don't think it's time to vote now 14:37:43 <Kevin_Kofler> We were the first ones to ship KDE 4 and we did it well. 14:37:51 <jreznik> we need clear message from upstream first 14:37:53 <cwickert> ltinkl: I don't think we have learned, learning IMHO means that we understand it needs wider testing 14:37:53 <than> Kevin_Kofler: i did not see so 14:37:53 <rdieter> I'd propose we defer voting at least until we get feedback from upstream, on their opinion if it'll be shippable in time for f14 14:38:02 <ltinkl> please... the first couple of kdepim releases were completely unusable... 14:38:03 <cwickert> rdieter: +1 14:38:03 <than> it's disaster for me too 14:38:07 <Kevin_Kofler> We should be bold like that again, not start getting wimpy like some other distros. 14:38:13 <jreznik> rdieter: +1 14:38:25 <cwickert> ltinkl: because nobody cared to test them... 14:38:31 <than> rdieter: +1 14:38:36 <cwickert> anyway, lets delay the vote by one week 14:38:42 <Kevin_Kofler> Wait a minuteā¦ There's an upstream person here now. 14:38:46 <tmcguire> can someone paste the last few lines of backlog to pastebin please? 14:38:48 <ltinkl> cwickert: not true, look at KDE bugzilla first please 14:38:49 <Kevin_Kofler> tmcguire: Hi! :-) 14:38:56 <rdieter> #agreed delay kdepim-4.5 decision/voting pending feedback from upstream 14:39:00 <ltinkl> tmcguire: hello 14:39:10 <Kevin_Kofler> tmcguire: Meetbot logs everything, let me dig up the running txt. 14:39:36 <rdieter> tmcguire: http://fpaste.org/3dTN/ 14:39:48 * ltinkl brb 14:39:52 <Kevin_Kofler> OK, that works too. :-) 14:40:15 <Kevin_Kofler> Re delaying, I think there's not much time to delay stuff. 14:40:32 <Kevin_Kofler> This really needs to go in ASAP. 14:40:51 <Kevin_Kofler> We need all the testing time we can get. 14:41:23 <rdieter> moving on then 14:41:27 <rdieter> #topic kde-4.4.5 updates status 14:41:30 <cwickert> Kevin_Kofler: if we don't declare it a feature of it's own, we don't need to vote today 14:41:53 <Kevin_Kofler> cwickert: But we only have 2 weeks until feature freeze, and the release is coming close. 14:42:06 <Kevin_Kofler> All the time we lose delaying is time we miss for testing. 14:42:09 <rdieter> I was a bonehead and missed including libmsn in the latest f14 push, otherwise, I think 4.4.5 is good 14:42:10 <tmcguire> so next fedora version is released in october? 14:42:16 <rdieter> tmcguire: yes 14:42:19 <winterz> rdieter: hi 14:42:41 <rdieter> tmcguire (and winterz) : http://fedoraproject.org/wiki/Releases/14/Schedule 14:42:44 <winterz> the first possible chance for a kdepim4.5 would be early Sep 14:42:45 <rdieter> winterz: hi, 14:43:05 <winterz> that's about when KDE SC 4.5.1 will be released 14:43:25 <rdieter> winterz: that's doable, I think, provided no more suprises or sipages. :) 14:43:30 <winterz> but i'm doubtful 14:43:35 <cwickert> winterz, tmcguire: do you think that kdepim will be usable by october 26 without data loss? 14:43:55 <Kevin_Kofler> Sep 7 is when things should in principle go in, but up to Oct 11 is possible. 14:43:57 <tmcguire> My private opinion, which is known to be different from the opinion of others from the kdepim team, is that kdepim at that time will not be stable enough. 14:44:23 <Kevin_Kofler> cwickert: Oct 11 please. We can't stuff in things in the last 2 weeks before release because rel-eng needs time to compose the spins. 14:44:24 <ltinkl> tmcguire: by september or october? 14:44:47 <Kevin_Kofler> But of course the Fedora schedule MIGHT slip. But we shouldn't rely on that. 14:44:51 <jreznik> tmcguire: what we need is clear statement from kdepim team... we will (have to) believe you :) 14:44:56 <cwickert> Kevin_Kofler: we can still ship a 0 day update, nobody will throw his mails into dhe version that is on the livecd 14:45:28 <jreznik> cwickert: sorry, that's not a good idea to use 0 day update for this 14:45:44 * smparrish agrees with jreznik 14:45:47 <tmcguire> by september/october, kdepim will probably be useable, and migration will work in most cases, but I doubt it will be a joy for users. again, my private opinion. 14:45:51 <cwickert> jreznik: I have to admit that it's abusing the freeze 14:46:04 <rdieter> tmcguire: a joy in general, or compared to kdepim-4.4.x ? 14:46:09 <ltinkl> winterz: what is your opinion? :) 14:46:26 <tmcguire> rdieter: compared to kdepim 4.4.x 14:46:31 <Kevin_Kofler> Well, if the version on the spin is almost final, shipping a 0-day (or even non-0-day) update to final looks fine to me. 14:46:32 <rdieter> ok 14:47:28 <Kevin_Kofler> Of course, if it's something like KDE 3.96.0 (the KDE 4 prerelease which was current when F8 released), it'd be a different story. 14:47:41 <Kevin_Kofler> (Yes, even I think it was right not to ship F8 with that. ;-) ) 14:47:55 <Kevin_Kofler> But F9's 4.0.3 was fine, IMHO. 14:48:15 <than> it sounds for me we should stay with kdepim-4.4 14:48:21 <rdieter> alright, I've heard enough I think, both winterz and tmcguire have reservations and doubts. than, +1 14:48:26 * ltinkl nods 14:48:32 <winterz> yes. too bad 14:48:46 <rdieter> winterz, tmcguire : thanks for stopping by 14:49:09 <winterz> ok 14:49:10 <than> tmcguire, winterz: thanks for your infos 14:49:17 <ltinkl> nothing stops the more adventurous souls from testing kdepim 4.5, either by compiling from source or from the kde-redhat repos 14:49:19 <smparrish> +1 to not ship in F14 8-( 14:49:20 * Kevin_Kofler votes -1 to than 14:49:32 <Kevin_Kofler> (i.e. +1 for 4.5) 14:49:50 <rdieter> now, that doesn't mean we can't continue to build/test kdepim-4.5.x for testing and feedback (we can figure out the logistics of doing that later) 14:49:53 <tmcguire> you could also provide packages for kdepim 4.5, not installed by default, for adventerous users 14:49:54 <ltinkl> I just don't think it's wise to release something unstable onto the masses 14:49:54 <Kevin_Kofler> We're going to let some other distro steal our show again like for K3b. 14:50:26 <rdieter> tmcguire: we can't ship anything that can't be parallel installable (without great pain and suffering anyway), is that possible? 14:50:27 <jreznik> than: +1 14:50:52 <smparrish> Kevin_Kofler: I would rather someone else deal with user headaches, especially on something as important as this 14:50:57 <tmcguire> rdieter: Oh, it is not parallel installable, right. I thought installed it instead the other package. 14:50:58 <jreznik> Kevin_Kofler: it's not about show, we still have kde sf repo with hot stuff 14:51:02 <Kevin_Kofler> And our users are going to be stuck with either an outdated kdepim or a painful migration for the whole life of F14. 14:51:43 <than> rdieter: we could upload kdepim 4.5 to kde-redhat 14:51:44 <Kevin_Kofler> rdieter: Well, we could put it into kde-unstable or something. 14:51:53 <rdieter> than, Kevin_Kofler : ye 14:51:54 <rdieter> yes 14:51:57 <tmcguire> btw, I don't know how well Fedora packages work in general, but I'd really like to see Akonadi and GPG working out of the box. 14:52:05 <tmcguire> We made a Readme.packagers file for that 14:52:11 <Kevin_Kofler> smparrish: What happened to our "First" objective? 14:52:24 <Kevin_Kofler> Fedora is not about letting other distros deal with the problems. 14:52:30 <Kevin_Kofler> We're supposed to lead the innovation, not trail it. 14:52:43 <rdieter> Kevin_Kofler: first doesn't mean stupid/unwise, not listening to upstream 14:52:57 <ltinkl> Kevin_Kofler: rawhide fullfills that I think more than enough :) 14:52:58 <than> Kevin_Kofler: we should listen to upstream 14:53:05 <Kevin_Kofler> rdieter: Undoubtedly some distro WILL ship this thing! 14:53:10 <rdieter> anyway, we're running real short on time, let's move along 14:53:12 <Kevin_Kofler> And so we'll be late. 14:53:23 <Kevin_Kofler> And everyone will complain that we're not shipping the new stuff Distro XYZ ships. 14:53:33 <rdieter> wrt kde-4.4.5, anyone of the opinion we should push this stable yet? or wait a bit more? 14:53:41 <ltinkl> silly argument, sorry Kevin :) 14:53:44 * Kevin_Kofler misses the Fedora 9 times where we actually had the balls to ship current software. 14:53:53 <ltinkl> we shouldn't do something just because others do it as well 14:53:59 <Kevin_Kofler> (KDE 4.0 was only one of the scary things in F9, BTW.) 14:54:49 <rdieter> no opinions on kde-4.4.5 ? bueller? 14:54:51 <Kevin_Kofler> ltinkl: But Rawhide doesn't have kdepim 4.5 yet because you (plural) just refused to put it in now targeting F14. 14:55:14 <Kevin_Kofler> No objections to pushing KDE 4.4.5 to stable from me. 14:55:31 <ltinkl> Kevin_Kofler: we can put it in rawhide as soon as KDE 4.5 gets released (and F14 branched) 14:55:48 <cwickert> Kevin_Kofler: +1, I want Fedora to be leading edge again, it's getting worse and worse 14:56:01 <Kevin_Kofler> F14 will be branched on Jul 27 according to the schedule. 14:56:11 <Kevin_Kofler> cwickert: Yeah. 14:56:27 <ltinkl> cwickert: what prevents you from installing kdepim 4.5 from kde-redhat or even compiling from source? that IS bleeding edge approach 14:56:29 <Kevin_Kofler> It's visible from the changes to update policies and many other things. 14:56:35 <Kevin_Kofler> We're becoming more and more like another Ubuntu. 14:56:46 <Kevin_Kofler> ltinkl: Ubuntu users can do that too. 14:57:09 <Kevin_Kofler> We're losing our most distinctive feature if we stop being the first to ship new stuff. 14:57:18 <jreznik> Kevin_Kofler: if kdepim people says they make it, then no problem for me... but if we hear they can't make it, it's clear for me 14:57:27 <Kevin_Kofler> People who want boring old stuff should use RHEL or CentOS. 14:57:34 <Kevin_Kofler> Or Debian or Ubuntu or whatever. 14:57:36 <Kevin_Kofler> But not Fedora. 14:57:36 <jreznik> shipping unfinished product killing users data - that's bad marketing 14:57:55 <cwickert> ltinkl: it's not about me but about my colleges that are doing the QA and desperately need more testers than me and the people here 14:58:06 <jreznik> shipping brand new Plasma desktop (even not ready) - it was OK for me and I still think it was a good idea 14:58:27 <Kevin_Kofler> cwickert: Yeah, nobody tests stuff if nobody ships it. 14:58:39 <rdieter> cwickert: we'll get you testers, it just may not end up being the whole f14 userbase. 14:58:41 <Kevin_Kofler> That's exactly why a bold Fedora is also valuable for upstream. 14:58:43 <jreznik> Kevin_Kofler: but you can't ask everyone to test it 14:59:17 <rdieter> alright, we're up for time today. 14:59:24 <rdieter> let's continue on in #fedora-kde 14:59:26 <Kevin_Kofler> jreznik: But we can FORCE everyone to test it. :-) 14:59:29 <rdieter> any last words ? 14:59:37 * ltinkl is melting 14:59:39 <cwickert> delay by a week 14:59:59 <rdieter> cwickert: we can revisit the issue, sure, esp if there's any new information to consider 15:00:28 <Kevin_Kofler> Re the next agenda topic, "Desktop validation testing expansion", I thought we already agreed to take that up on the ML? 15:00:40 <rnovacek> I would give it a try if it would be in kde-redhat 15:00:45 <Kevin_Kofler> And since QA now sent a mail (bad bad me for not doing it before they did), let's just discuss it there. 15:01:55 <rdieter> Kevin_Kofler: right, ml is fine 15:02:03 <rdieter> #endmeeting