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