16:05:26 <Kevin_Kofler> #startmeeting KDE SIG Meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-30
16:06:13 <Kevin_Kofler> #chair than rdieter Kevin_Kofler ltinkl
16:06:24 <than> do we have somthings on agenda?
16:06:32 <Kevin_Kofler> So, who's present?
16:06:35 <rdieter> here
16:06:38 * ltinkl is here
16:06:39 <Kevin_Kofler> than: Yes. :-)
16:06:54 * maxamillion is here
16:07:04 * SMParrish here
16:07:05 <than> need to add kde-4.3rc1 status on agenda
16:07:30 <than> and ktron/kbattleship status
16:07:31 <Kevin_Kofler> than: OK, I'm adding it.
16:08:06 <Kevin_Kofler> That one's easy, I haven't done the patch yet, I'll do it ASAP (should be before we push 4.1 out to stable releases).
16:09:57 <Kevin_Kofler> #topic adding KDE to the critical path of packages
16:10:14 <Kevin_Kofler> See http://fedoraproject.org/wiki/Critical_Path_Packages_Proposal && https://fedoraproject.org/wiki/User:Arxs/CPCL
16:10:21 <than> Kevin_Kofler, if it will take much time we should drop both for F10 and F11 in th emeantime
16:10:32 <Kevin_Kofler> than: No.
16:10:39 <Kevin_Kofler> Just plain no.
16:10:49 <Kevin_Kofler> KTron is in kdegames3 in F10 and F11 and is already renamed.
16:11:03 <Kevin_Kofler> And we've been shipping KBattleShip for ages.
16:11:07 <Kevin_Kofler> Since 4.0 at least.
16:11:09 <than> Kevin_Kofler, it's a trademark issue
16:11:20 <than> it could cause a problem for us
16:11:32 <Kevin_Kofler> It's a potential trademark issue and we shouldn't remove features for it, it can wait the few days I need to fix it.
16:11:37 <Kevin_Kofler> And we already shipped F10/F11 with that.
16:11:53 <Kevin_Kofler> It won't take much time.
16:12:14 <than> i don't want that we get trouble here
16:12:49 <rdieter> than's right, this is rawhide, there's no harm to removing anything in the interim
16:12:52 <than> do you think you will get the patch ready this week?
16:13:05 <Kevin_Kofler> rdieter: He wants to remove KBattleShip also in the stable releases, which is what I'm objecting to.
16:13:24 * rdieter removes foot from mouth
16:13:25 <Kevin_Kofler> than: Yes, I think that's doable.
16:13:44 <rdieter> rawhide yes, stable releases I'd advocate waiting for 4.3 to land
16:13:59 <than> spot, ping
16:14:22 <rdieter> unless there's a legal spank involved. :)
16:14:53 <than> we have to ask spot
16:15:22 <Kevin_Kofler> Well, then I propose we wait for a reply and go back to the topic which is actually first on the agenda. :-)
16:15:42 <rdieter> I'll ask for the level of legal urgeny in the relevant bug.
16:16:13 <than> rdieter, yes please
16:16:53 <rdieter> sorry, agenda is good... :)   critical path items...  I'm torn, but I'd think it worthwhile to at least consider:   logging in... and updates for kde
16:17:10 <rdieter> that includes:   kdm, kdebase-workspace (core, may need additional splitting?), kpackagekit
16:17:53 <Kevin_Kofler> I don't like the whole concept, but unfortunately I was overwhelmingly outvoted at FESCo. :-(
16:17:58 <rdieter> If we're going walk the walk, and talk the talk of an official fedora spin, then that's what needs to happen
16:18:28 <Kevin_Kofler> Yeah, having a list of critical path packages which doesn't include KDE kinda makes it a farce.
16:18:44 <SMParrish> I agree with rdieter, the proposal sounded good at FAD and if we want to be on an even footing with gnome we need to be included
16:18:54 <Kevin_Kofler> I'm not really happy of having to work with the crappy bureaucracy, but at least we won't be alone.
16:19:08 <Kevin_Kofler> "patch" as a critical package, WTF?!
16:19:12 <rdieter> Kevin_Kofler: QA/testing counts as beureaucracy?   :)
16:19:18 <wwoods> we can't build anything without patch
16:19:33 <Kevin_Kofler> Forced QA which requires approval for every single build is bureaucracy.
16:19:45 <wwoods> it doesn't require approval for builds
16:19:48 <wwoods> just updates
16:19:51 <Kevin_Kofler> As if the security team approval for security updates wasn't already enough of a PITA.
16:20:04 <Kevin_Kofler> wwoods: There are people who suggested using that approval process even for Rawhide.
16:20:05 <wwoods> yes, quality is hard
16:20:07 <wwoods> let's ride bikes
16:20:23 <rdieter> Kevin_Kofler: just chill out, if problems/delays arise, let's deal with it then.  otherwise, it's just panic-talk
16:20:34 <wwoods> also the critical path isn't supposed to include *any* DE
16:20:41 <wwoods> neither KDE nor GNOME
16:21:03 <SMParrish> wwoods: but if you include the login managers ie (gdm,kdm) parts of the DE will get pulled in
16:21:04 <Kevin_Kofler> So you technically can log in, but your desktop crashes as soon as you entered your password???
16:21:05 <wwoods> just the basic platform stuff that we need to do anything like installs
16:21:08 <Kevin_Kofler> How useful is that?
16:21:14 <wwoods> Kevin_Kofler: that's outside the scope of the exercise
16:21:24 <rdieter> wwoods: ok, thanks for the clarification
16:21:25 <wwoods> obviously that other stuff should be tested
16:21:25 <Kevin_Kofler> This makes no sense whatsoever.
16:21:34 <wwoods> nobody's saying "we aren't going to test anything past here"
16:21:35 <rdieter> looks like that's that then, move on? ;)
16:21:46 <Kevin_Kofler> If you consider login critical, you must also consider it critical to actually log into a working system.
16:21:49 <wwoods> we're just suggesting that maybe the packages that *everything else* is built on top of
16:21:54 <wwoods> should actually get some extra attention
16:22:01 <Kevin_Kofler> rdieter: Not really, there's at least KDM which is "login".
16:22:29 <rdieter> Kevin_Kofler: if wwoods says it doesn't count, ... what... you want to argue?
16:22:38 <Kevin_Kofler> And as it's built from the same SRPM as kdebase-workspace, incidentally, it implies kdebase-workspace would be on the QA hitlist anyway.
16:22:57 <SMParrish> wwoods: if I am not mistaken seth's list includes the login managers, and even he stated at the FAD you should get to a basic desktop
16:22:57 <Kevin_Kofler> rdieter, wwoods: So, should gdm also be taken off the list?
16:23:19 <wwoods> no
16:23:28 <Kevin_Kofler> So we should also add KDM.
16:23:31 <wwoods> no.
16:23:35 <Kevin_Kofler> People installing from the KDE live CD have KDM.
16:23:38 <Kevin_Kofler> They don't have GDM.
16:23:42 <Kevin_Kofler> It's not even installed.
16:23:44 <wwoods> gdm is the default provider for the login manager.
16:23:49 * rdieter is confused.
16:23:53 <wwoods> that's the KDE spin's problem then, isn't it?
16:24:02 <abadger1999> wwoods: Err... no.
16:24:03 <wwoods> I mean if you're going to deviate from the defaults then you need to keep an eye on the stuff you're replacing
16:24:06 <Kevin_Kofler> So you're discriminating against KDE once again.
16:24:18 <rdieter> wwoods: I'd argue login managers of any/all official spins should be considered here.
16:24:34 <rdieter> Kevin_Kofler: let's frame this differently, please.
16:24:38 <wwoods> fine - just agree that you're willing to take responsibility for testing 'em
16:25:08 <rdieter> wwoods: is that what the proposal as-is includes?  spin producers have the responsibility for all testing?
16:25:11 <wwoods> no
16:25:21 * rdieter is more confused
16:25:32 <wwoods> 99% of the packages on the critical path list should be common to every spin
16:25:42 <rdieter> agreed
16:26:01 <Kevin_Kofler> Saying 99% implies there are at least 100 critical path packages.
16:26:04 <Kevin_Kofler> That sounds like a lot.
16:26:09 <wwoods> there are
16:26:14 <wwoods> consider all the deps of all the packages listed
16:26:34 <wwoods> last time we depsolved out a proposed list it was something around 100 packages
16:26:38 <Kevin_Kofler> That's most of GNOME for the current GDM.
16:26:43 <wwoods> and that was a much shorter list
16:26:47 <wwoods> ...
16:26:48 <wwoods> you know what
16:26:50 <SMParrish> wwoods: you can't just say that only those items that effect the default spin are critical items
16:26:55 <Kevin_Kofler> I think GDM drags in a lot of stuff we don't ship on the KDE live image.
16:27:10 <wwoods> SMParrish: no, I just said that the critical items make up the base platform for all spins
16:27:24 <wwoods> I'm not the one who put GDM on the list
16:27:33 <wwoods> if that's the only package you're going to argue about let's just drop it
16:27:41 <rdieter> chill out please, I don't want to hear mention of gnome/gdm/kde/kdm at all for a few minutes, pretty please?
16:28:25 <than> next topic please
16:28:34 <wwoods> I'm perfectly willing to suggest that the login managers should be dropped
16:28:39 <wwoods> that's the sense I'm getting here
16:28:41 <rdieter> all I'm saying, is that if the "login" use-case happens to get included, I would consider it important that loginmanager of all official spins be considered for inclusion, that's all
16:28:49 <Kevin_Kofler> So what should I log as the conclusion for this topic?
16:28:51 <wwoods> and they add a ridiculous amount of stuff to the list
16:28:55 <than> we can discuss it on #fedora-kde
16:29:04 <Kevin_Kofler> wwoods: Indeed.
16:29:18 <Kevin_Kofler> Plus, making sure *DM works doesn't make much sense without making sure it logs into a working desktop too.
16:29:19 <wwoods> rdieter: I think the login use-case is outside the scope of the critical path / base platform
16:29:22 <Kevin_Kofler> So that'd add even more stuff.
16:29:30 <rdieter> wwoods: and that's fine with me.
16:29:33 <rdieter> :) move on
16:29:36 <wwoods> indeed
16:30:08 <Kevin_Kofler> #agreed login managers should not be critical path packages (also agreed on with wwoods)
16:30:33 <Kevin_Kofler> #topic kde-plasma-networkmanagement status
16:30:42 <wwoods> (note that's not to say they shouldn't be tested - but that they're complex enough to deserve their own test plans)
16:31:46 <Kevin_Kofler> So kde-plasma-nm is the next big topic.
16:31:57 <Kevin_Kofler> I was going to flip the switch in Rawhide when the WPA regressions came up.
16:32:11 <Kevin_Kofler> (reportedly working in F10, broken in F11 with the same kde-plasma-nm snapshot)
16:32:15 <Kevin_Kofler> Now I'm not sure what to do.
16:32:44 <rdieter> it's rawhide, flipping the switch is still ok, that'll get more testing/exposure
16:32:49 <Kevin_Kofler> Plus, NM 0.8 is coming soon and its backwards compatibility status is unknown (FESCo has asked for details on this as part of the feature process).
16:33:09 <rdieter> but as upstream is still in playground, and closeness to a "release" is unclear... *shrug*
16:33:45 <Kevin_Kofler> And what we're shipping is not the current upstream, its shippable status is unclear (since the big refactoring during the hackfest).
16:34:17 <Kevin_Kofler> But I do think we need to switch to it in Rawhide soon if we want it to be the default in F12.
16:34:22 <rdieter> but that's only part of it, solid elsehwere uses NM too (so that's relavent to the FESCo/feature process)
16:34:38 <than> Kevin_Kofler, it's ok for rawhide
16:35:19 <than> we cannot make it as default for F12 if it doesn't work as expected
16:35:38 <rdieter> I'd tend to agree with than, the only chance of using it for F12, is to start serious testing asap
16:35:38 <Kevin_Kofler> than: Indeed, but we can always change back if the Rawhide feedback is overwhelmingly negative.
16:35:48 <rdieter> that too
16:35:54 <Kevin_Kofler> Serious testing = switching it on in Rawhide, right? :-)
16:36:00 <than> yes
16:36:13 <Kevin_Kofler> #agreed kde-plasma-networkmanagement will be made the default in Rawhide ASAP
16:36:24 <rdieter> to be clear, switch on = what exactly?
16:36:25 <Kevin_Kofler> #action Kevin_Kofler will flip the switch on kde-plasma-networkmanagement in Rawhide
16:37:00 <Kevin_Kofler> rdieter: comps (default package set), kdebase-workspace (default Plasma setup for new users)
16:37:20 <rdieter> ok, good, that's all I can think of too. :)
16:37:36 <Kevin_Kofler> Upgraders will have to switch manually (so that's a 3rd place to edit, the release notes :-) ).
16:38:45 <Kevin_Kofler> #topic KDE 4.3 RC1 status
16:39:06 <Kevin_Kofler> than has started importing 4.3 RC1 (4.2.95) into Rawhide.
16:39:19 <than> kde-4.3 build is already done for rawhide
16:39:34 <than> i'm starting to build kde-l10n
16:39:44 <than> it's the last one
16:39:54 <Kevin_Kofler> OK, that's great.
16:40:37 <Kevin_Kofler> #info 4.3 RC1 is done in Rawhide, than is working on kde-l10n
16:42:17 * rdieter will get to work on kde-redhat/unstable pkgs then too.
16:42:41 <Kevin_Kofler> #info rdieter will get to work on kde-redhat/unstable pkgs
16:42:43 <than> rdieter, it's great, so we will get more feedbacks
16:42:49 <Kevin_Kofler> Yeah.
16:43:33 <Kevin_Kofler> Should I put up the trademark stuff again or should we move on directly to the recent bugs?
16:44:09 <than> we can discuss the trademark stuff later on other channel
16:44:12 <rdieter> I'd say move on
16:44:23 <than> move on please
16:45:09 <Kevin_Kofler> #topic recent bugs: moving Lokalize to a subpackage
16:45:19 <Kevin_Kofler> #link https://bugzilla.redhat.com/show_bug.cgi?id=501215
16:45:21 <buggbot> Bug 501215: medium, low, ---, than, ASSIGNED, subpackage lokalize for translators
16:45:32 <Kevin_Kofler> It's currently part of kdesdk.
16:45:58 <rdieter> I'd be happy to work on this, it'll give our translators a better experience
16:46:06 <Kevin_Kofler> The i18n folks have asked us whether we can split it to a subpackage so they don't have to install all of kdesdk.
16:46:23 <rdieter> may even split 'kate' too, that's the next thing that gets asked about the most
16:46:26 <than> it's fine with me to split it
16:46:40 <Kevin_Kofler> I'm not a big fan of subpackage explosion and the resulting maintenance overhead, but I do get the point.
16:46:59 <SMParrish> +1 to the split
16:47:01 * Kevin_Kofler thinks Kompare is the most important part of kdesdk. ;-)
16:47:16 <rdieter> I can split kompare too if you want. :)
16:47:55 <Kevin_Kofler> The thing is, once we start splitting stuff, people will ask us to split everything else too.
16:48:13 <Kevin_Kofler> At the end, we'll end up with every package having around a dozen subpackages.
16:48:23 <than> that is what we have to avoid
16:48:24 <Kevin_Kofler> Just look at e.g. openSUSE to see what we'd end up with.
16:48:27 <SMParrish> just because they ask does not me we have to.  in this case it just makes sense
16:48:33 <rdieter> shrug, we'll continue doing as we have, consider it on a case-by-case basis, and only do it where it makes sense
16:48:46 <than> we only split if it really makes sense
16:50:33 <than> size of kdesdk package is only 6,8M
16:50:35 <rdieter> I always try to use it as a motivation to get more contributors and comaintainers.  ie, if you want split pkgs so much, why not help make it happen?  (usually quiets folks well)
16:51:48 <Kevin_Kofler> So how do we proceed?
16:51:52 <than> it doesn't take much places, so spliting won't make sense here
16:52:00 <Kevin_Kofler> Do we want to do the split or do we want to close it NOTABUG?
16:52:19 <than> it would say close as notabug
16:52:30 <than> s/it/i
16:52:31 <rdieter> split it, if for nothing else of additional goodwill of our fedora translator brothers (and sisters).
16:52:51 <SMParrish> split it
16:53:12 <than> rdieter, it doesn't make sense for me
16:53:19 <than> to split it
16:53:44 <Kevin_Kofler> I don't care strongly about this particular one, but I'd say don't split it or we'll get flooded with more split requests.
16:54:00 <Kevin_Kofler> ltinkl: Any opinion?
16:54:04 * rdieter doesn't care about slippery-slop scare-mongering
16:54:24 * ltinkl is quiet today
16:54:58 <ltinkl> what Rex said, split only if the need is justified
16:55:10 <rdieter> what I care about is that our own i18n team asked for something, it's not *that* hard or much work to deliver, I'm willing to do the work, we should deliver
16:55:15 <SMParrish> I don't see where this put any large burden on us and helps out the translators who in the long run are helping us and the rest of Fedora
16:55:34 <ltinkl> imho it also makes sense for Kate
16:55:54 <than> it's a question wether it makes sense to split
16:56:00 <rdieter> don't kid yourself, it will be an additional maintainance burden going forward, but I can accept that here
16:56:05 <than> the kdesdk is not big
16:56:14 <than> it's only 6.1M
16:56:36 <rdieter> umm... my kdesdk pkg installed is ~21mb
16:56:51 <Kevin_Kofler> That's installed vs. RPM size.
16:56:54 <rdieter> are you looking at compressed rpm?
16:57:07 <than> rdieter, yes
16:57:08 <Kevin_Kofler> 21 MB of installed size is not much.
16:57:23 <than> Kevin_Kofler, +1
16:57:38 <rdieter> I agree the technical matters are of little importance here, I still think it a good (albeit political, whatever) move.
16:58:35 <rdieter> let's discuss more after meeting... time it getting short, I don't want to monopolize what time is left on this
16:59:11 <Kevin_Kofler> #agreed deferred for further discussion (on #fedora-kde)
16:59:17 <Kevin_Kofler> #topic open discussion
16:59:31 <Kevin_Kofler> That was it for the agenda, now we have a few seconds left until the hour.
16:59:42 <Kevin_Kofler> Anything else to discuss?
17:00:43 <Kevin_Kofler> Who'll do the summary today? Or are we going to use the bot's stuff only?
17:01:46 <Kevin_Kofler> I don't see much enthousiasm...
17:01:51 <spot> Kevin_Kofler: I would like you to remove the trademark infringing items in the next set of stable updates
17:02:08 <spot> you don't have to do an update just for that issue, but it should be picked up with the next update
17:02:15 <Kevin_Kofler> spot: The next stable update for kdegames will most likely be 4.3.0.
17:02:22 <spot> Kevin_Kofler: that's fine.
17:02:33 <spot> just go ahead and commit the change to cvs nowish so we don't forget
17:02:43 <than> spot, great, thank
17:03:09 <Kevin_Kofler> OK
17:04:01 <Kevin_Kofler> #agreed The kdegames trademark issues (ktron (in 4.3), kbattleship) will be handled in the next stable kdegames update (should be kdegames-4.3.0).
17:04:44 <Kevin_Kofler> We'll discuss the summary stuff on #fedora-kde.
17:04:47 <Kevin_Kofler> #endmeeting