kde-sig
LOGS
14:02:26 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-03-02
14:02:27 <zodbot> Meeting started Tue Mar  2 14:02:26 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:52 <rdieter> #chair Kevin_Kofler jreznik than
14:02:53 <zodbot> Current chairs: Kevin_Kofler jreznik rdieter than
14:02:56 <rdieter> #meetingname kde-sig
14:02:56 <zodbot> The meeting name has been set to 'kde-sig'
14:03:00 <rdieter> #topic roll call
14:03:07 <rdieter> who's present today?
14:03:14 * jreznik is here and ready
14:04:12 <Kevin_Kofler> Present.
14:04:22 <rdieter> SMParrish_mobile, than : ping
14:04:27 * than is present
14:05:13 <rdieter> alrighty, any last minute items for the agenda ?
14:05:25 * rdieter adds kdeedu-math-R subpkg item
14:05:41 <SMParrish_mobile> Here
14:06:55 <rdieter> lets start with kde-4.4.1 I guess
14:06:58 <rdieter> #topic kde-4.4.1 status
14:07:36 <rdieter> first off, 4.4.1 is (mostly) in devel/ already.  work to do other branches can get started in earnest today
14:07:52 <rdieter> how's kde-l10n-4.4.1 now?
14:08:10 <ltinkl> I'm updating the CVS for F11/F12/F13 at the moment
14:08:32 <ltinkl> once I'm done with it, I'll launch the builds
14:08:36 * jreznik has changed owning of serbian LC_MESSAGES today
14:08:45 <rdieter> is kde-l10n-4.4.1 built ?
14:08:59 <than> rdieter: it's still building in koji
14:09:13 <rdieter> ok, hopefully just a matter of time then.
14:09:34 <Kevin_Kofler> There were at least 2 file list issues, I fixed the first, than fixed another one, I hope it's OK now.
14:10:47 <rdieter> another 4.4.1-related item, Kevin_Kofler and I have been talking off and on over the past few days about splitting out a kdeedu-cantor-R subpkg
14:10:58 <rdieter> or whatever we want to call it.
14:10:58 <jreznik> one issue - sr@ijekavian and sr@ijekavianlatin should be owned by filesystem - ovasik added it today to rawhide... but as we're syncing it to 11, 12, 13... there's comment it should be unowned once F13 is eol
14:12:15 <rdieter> so, use kdeedu-math-cantor-R or kdeedu-cantor-R or <foo> ?
14:12:32 <rdieter> or not do it at all (and keep the big R dependency in kdeedu-math itself)?
14:13:11 <than> rdieter: is there any reason whe wha we need to split it?
14:13:12 <rdieter> my initial opinion had been to split cantor into it's own subpackaging, but keeping the core parts of it in -math is ok too.
14:13:27 <rdieter> than: just that the 'R' dependency is quite large
14:13:38 <Kevin_Kofler> than: The reason is that kdeedu-math (well, kdeedu in 4.4.0, but I fixed that now) is requiring R-core.
14:13:49 <Kevin_Kofler> Because Cantor's R backend is linked against the R library.
14:13:52 <rdieter> R-core = ~64mb
14:14:10 <than> ah ok, it's big
14:14:11 <Kevin_Kofler> (unlike Maxima and SAGE which just use external executables, so we get away with just omitting the dependency there)
14:15:16 <Kevin_Kofler> rdieter: And that's just R-core.
14:15:25 <Kevin_Kofler> If we actually required the recommended R metapackage, it'd be worse.
14:15:27 <rdieter> sure, there may be more to it
14:15:41 <Kevin_Kofler> (But I don't think we should do that, as Cantor will work just fine with just R-core.)
14:16:07 <rdieter> I think I agree, unless we find reason to believe otherwise
14:16:39 <than> Kevin_Kofler: does it mean we can drop R-dependency here?
14:16:39 <Kevin_Kofler> If we had soft dependencies, we could suggest R, but as it is now… :-/
14:16:45 <Kevin_Kofler> than: No.
14:16:52 <Kevin_Kofler> R-core will always be required.
14:17:04 <Kevin_Kofler> Either by kdeedu-math itself or by a subpackage.
14:17:16 <Kevin_Kofler> Because Cantor's R backend is linking a library from R-core.
14:17:30 <rdieter> who wants to work on this?  (and any opinions about calling it kdeedu-math-cantor-R vs kdeedu-cantor-R ?)
14:17:39 <than> how big is the whole the dependency?
14:18:09 <rdieter> R-core itself is the 64mb, not sure what else it pulls in
14:18:49 <rdieter> heh, R-core pulls in texlive too, if that matters. :)
14:19:03 <rdieter> and tk/tcl
14:19:06 <than> it's fine with me to split it in this case
14:19:13 <than> it does make sense
14:20:03 <Kevin_Kofler> I'll split it, so about the name?
14:20:05 <rdieter> anyone object to using kdeedu-cantor-R subpkg name here?  (offhand, injecting -math in there feels superfluous to me)
14:20:28 <Kevin_Kofler> I'd prefer having -math in there because it's really a subpackage of kdeedu-math.
14:20:42 <rdieter> true, it'll be more consistent
14:20:46 <rdieter> go with that then.
14:21:28 <rdieter> I'll poke rel-eng to see how long it would take to get the custom tags going, if it won't take long, we can use that when building 4.4.1 this time around
14:21:42 <nucleo> why not kdeedu-cantor like kdeedu-kstars?
14:21:56 <rdieter> nucleo: -cantor isn't split, it's in -math currently
14:22:20 <rdieter> -cantor itself isn't very big (iirc), so splitting it out makes less sense than -kstars, or -marble
14:22:32 * thomasj_ back from kindergarten..
14:22:58 <nucleo> rdieter: ok
14:23:50 <rdieter> so, anything else 4.4.1-related ?
14:24:31 <rdieter> moving on....
14:24:35 <rdieter> #topic KDE Release marketing materials for Fedora 13
14:24:51 <rdieter> superhero rrix has come up with, https://fedoraproject.org/wiki/KDE/F13_Talking_Points
14:26:18 <rdieter> I like those, I think it would be prudent to focus on the stuff that we helped to implement, particularly Kauth/polkit
14:26:55 <rdieter> libattica could probably be merged with the other "social desktop integration" item, imo.
14:27:25 <rdieter> new kwin features probably ought to be simplified/merged too
14:27:34 <rdieter> anyone else, comments?
14:28:55 <Kevin_Kofler> Ubuntu has no qualms advertising the stuff Fedora developed as "Ubuntu features".
14:29:04 <Kevin_Kofler> So why should we not do the same?
14:29:16 <rdieter> I didn't way otherwise, did I? :)
14:29:32 <rdieter> I only said I thought we should focus on what we helped with
14:30:39 <rdieter> ok, I guess let's move on...
14:30:56 <jreznik> depends on aim of talking points - from current f13 tp it looks it's more fedora only
14:30:57 <rdieter> #topic Board SWG questions for Spins Owners
14:31:11 <jreznik> did someone reply?
14:31:23 <rdieter> I don't think so (not I, anyway).
14:32:04 <jreznik> but we should - no to look silly - we're loud but if someone asks directly, we do not reply at all
14:32:28 <jreznik> not sure these questions are ok but...
14:32:44 <rdieter> sure
14:33:11 <rdieter> anyone want to own this topic, come up with a proposed response?
14:33:34 <jreznik> maybe we can discuss it in kde@fpo ml first
14:33:58 <rdieter> I said my piece in the spins sig meeting last week... it's just all still too hand-wavy and vague for me to grasp, honestly.
14:36:05 <Kevin_Kofler> Well, svahl would probably be the person who should own this, as the official spin maintainer. But he's not present (due to work).
14:36:30 <rdieter> ok, let's defer this for now.
14:37:08 <rdieter> #topic Wacom tablet does not work in Qt
14:37:13 <rdieter> https://bugzilla.redhat.com/show_bug.cgi?id=569132
14:37:24 <rdieter> .bug 569132
14:37:26 <zodbot> rdieter: Bug 569132 Wacom tablet does not work in Qt - https://bugzilla.redhat.com/show_bug.cgi?id=569132
14:37:48 <rdieter> we have some hints on how to fix this now, anyone want to work on it?
14:38:16 <rdieter> may be tricky for anyone without a tablet (ie, not be able to test)
14:38:51 <rdieter> it seems unfortunate for the wacom driver interface to change subtly like that to break stuff, but that's just my own naive interpretation of the situation.
14:39:00 <than> we need someone has hardware fot testing
14:39:03 <rdieter> either way, as it is, it doesn't work, so needs some love.
14:39:36 <than> i can take care of it
14:39:38 <Kevin_Kofler> Yeah, this kind of incompatible change really sucks.
14:39:58 <Kevin_Kofler> Apparently the people who did it weren't aware of the resulting Qt breakage.
14:40:00 <rdieter> LukasT/rrix both have tablets I think, they could help us test.
14:40:00 <jreznik> than: I can help, I know reported a little
14:40:04 <LukasT> hi
14:40:12 <jreznik> he's here :D
14:40:20 <than> jreznik: great, thanks
14:40:34 <rdieter> LukasT: we need folks with tablets to help us test fixes, can you help out?
14:40:54 <LukasT> rdieter: yes of course
14:41:01 <PPHman> hello, help me,        how can I get libmodex.so ?
14:41:17 <rdieter> #action than to work on qt/wacom fixes, folks with tablets handy can help test
14:41:22 <Kevin_Kofler> PPHman: Wrong chan, try #fedora.
14:41:24 <jreznik> PPHman: not a right channel
14:41:24 <thomasj_> PPHman, wrong channel, you want #fedora
14:41:43 <rdieter> moving on...
14:42:01 <rdieter> #topic http://fedoraproject.org/wiki/User:Rdieter/FUDCon_Toronto_KDE_F13_TODOs
14:42:31 <rdieter> I'd like to revisit this, esp considering all the recent kpk/pk-qt breakage.
14:42:37 <LukasT> rdieter: that's all?
14:42:46 <rdieter> LukasT: for now yes, thanks.
14:42:57 <LukasT> ok :)
14:43:05 <Kevin_Kofler> rdieter: kpk should be fixed now (at least for post-Alpha)!
14:43:05 <jreznik> for bt support - better times are coming, I'll recheck current issues
14:43:15 <rdieter> SMParrish_mobile: what's your take of the current situation?
14:43:20 <Kevin_Kofler> And kbluetooth is also basically fixed now, and has an active maintainer upstream now.
14:43:23 <rdieter> Kevin_Kofler: of course it should be fixed.
14:43:41 <rdieter> what I'm proposing still is a set of minimum standards for our default apps.
14:43:50 <Kevin_Kofler> "should" in the sense of "I think it is".
14:43:58 <rdieter> if those minimum standards cannot be met by what we have now, need to consider alternatives
14:44:21 <Kevin_Kofler> What we ship now is fine.
14:44:35 <Kevin_Kofler> And people are thanking us for finally shipping a pure KDE 4 without GTK+ or KDE 3 applets in there.
14:44:38 <rdieter> Kevin_Kofler: we've been on the kpk-is-broken-again roller coaster ride for the past 2 releases
14:45:06 <rdieter> frankly, I don't have a crap at all about any possiblity of a pure KDE4
14:45:10 <Kevin_Kofler> (at least if they don't have bugs bringing up ABRT or setroubleshoot ;-) )
14:45:14 <rdieter> don't give a crap
14:45:19 <thomasj_> kbluetooth is fine to ship, kpk is, well, the ugly little brother of pk-gnome
14:45:24 <SMParrish_mobile> Sorry on a work confernce call. I want to do some more testing but kpk may work out
14:45:32 <rdieter> that is, what I care about is shipping stuff that works, and is reliable
14:45:42 <jreznik> rdieter: +1
14:45:43 <SMParrish_mobile> Will know more tonight
14:46:29 <Kevin_Kofler> KDE 4 stuff is finally all mature now, with KNM having been the last missing piece, we really don't want to go back to temporary workarounds such as shipping GNOME stuff as part of our KDE setup.
14:46:34 <rdieter> so, per the FUDCon_Toronto_KDE_F13_TODOs wiki page, anything to add/remove/criticize about required minimal functionality ?
14:47:03 <Kevin_Kofler> My main critic is that this should not be "required minimal" functinonality, but "targets for fixing".
14:47:12 <rdieter> Kevin_Kofler: irrelavent, imo.  unless you're seriously suggesting it preferable to ship half-broken kde stuff vs. working app (using other toolkit)?
14:47:21 <Kevin_Kofler> Evaluating alternatives is only a last resort if the KDE app isn't working at all.
14:47:31 <Kevin_Kofler> Normally we want to prefer shipping the KDE app.
14:47:40 <rdieter> all things being equal, sure.
14:47:47 <rdieter> or even meeting minimal standards
14:48:17 <Kevin_Kofler> It's a KDE spin, not a "what works best" spin.
14:48:38 <Kevin_Kofler> The problem with "what works best" is that things may "work best" on their own, but don't work well together.
14:48:39 <rdieter> ok, there's at least 2 categories of specs here then
14:48:48 <rdieter> 1.  minimal standards and functionality
14:48:54 <rdieter> 2.  nice-to-have, things to fix stuff
14:49:04 <Kevin_Kofler> For example, GNOME Bluetooth stuff is based on gvfs, integrates with NM-gnome etc.
14:49:12 <Kevin_Kofler> The GNOME stuff is designed to work with other GNOME stuff.
14:49:19 <Kevin_Kofler> The KDE stuff is designed to work with other KDE stuff.
14:49:19 <rdieter> please don't get offtopic
14:49:28 <Kevin_Kofler> Mixing leads to a poorly integrated mess.
14:49:30 <rdieter> the topic at hand is *minimal standards*
14:49:31 <Kevin_Kofler> How's that off-topic.
14:49:57 <Kevin_Kofler> The point is that we can't require minimal standards when there's nothing we can do when they're not met.
14:50:02 <rdieter> for much of f12 release cycle, both kdebluetooth and kpk were ... for the most part, completely broken
14:50:05 <rdieter> nonfunctional.
14:50:09 <rdieter> I want to avoid that.
14:50:15 <Kevin_Kofler> And switching to GNOME stuff is a bad choice.
14:50:22 <rdieter> hell yes, there's something we can do.
14:50:29 <rdieter> use something that actually works.
14:50:37 <Kevin_Kofler> And integrates poorly with the rest of KDE?
14:50:42 <rdieter> I don't consider using tools that work... a bad choice.
14:50:55 <Kevin_Kofler> KPK is already fixed in F12, and for F13 I think it's also sorted out now, though more testing is needed.
14:50:57 <jreznik> it's better to loose some piece of integration instead of non working solution that sends users away to gnome...
14:51:16 <Kevin_Kofler> jreznik: So instead we want to ship GNOME and call it KDE?
14:51:17 <SMParrish_mobile> I want to avoid the f12 mess as well. So if kpk is not up to snuff we should not use it as the default
14:51:21 <rdieter> so, any comments on the minimal standards as I've proposed?
14:51:41 <rdieter> Kevin_Kofler: you suggested marking some items as "things to fix
14:51:44 <rdieter> like what?
14:52:03 <Kevin_Kofler> Pretty much all the stuff you listed as minimal.
14:52:17 <rdieter> Kevin_Kofler: heh, ok.  fair enough.
14:52:24 <Kevin_Kofler> Minimal should be: KPK can do signed updates from the repository.
14:52:32 <Kevin_Kofler> Even if it's just "pull all updates without any additional UI".
14:52:37 <Kevin_Kofler> That's minimum functionality.
14:52:40 <rdieter> so, you don't think an update notifier tool, should be able to actually do that ?
14:52:57 <jreznik> Kevin_Kofler: for example - I can live without nm, kpk... I don't need them - I use cli most of time but users can't go over issues so easily
14:53:18 <Kevin_Kofler> jreznik: See above.
14:53:21 <rdieter> doesn't matter I guess, you're welcome to your opinion.
14:53:39 <Kevin_Kofler> If you can't update at all with KPK, then there's a problem.
14:53:53 <rdieter> I guess I'll own this to take it to the next step, write up some test-cases for the functionality we require
14:53:54 <Kevin_Kofler> But as long as updating works, things like installing unsigned packages are not a blokcer.
14:53:57 <Kevin_Kofler> *blocker
14:54:11 <rdieter> perhaps next week, we can vote and agree on the minimal requirements, and go from there to start testing stuff
14:54:16 <Kevin_Kofler> Unsigned packages have been broken in KPK in many releases and we didn't care, why should we now?
14:55:04 <rdieter> I'll take it to ml one more time, we can discuss it further there.
14:55:06 <Kevin_Kofler> KNM minimum functionality is: connecting to wired and unencrypted wireless works.
14:55:18 <Kevin_Kofler> In reality we're far, far beyond that in actually working functionality.
14:55:28 <Kevin_Kofler> So I wonder why KNM is even getting considered there.
14:55:34 <Kevin_Kofler> It's clearly working.
14:56:01 <jreznik> Kevin_Kofler: it was minimum functionality 5 years ago...
14:56:02 <Kevin_Kofler> Works fine with WPA-PSK and WPA-EAP for me.
14:56:04 <rdieter> Kevin_Kofler: I'll adjust the wiki to clearly mark 1 vs 2 items (requirements vs nice-to-have)
14:56:19 <ltinkl> I just tried knm last week... connecting to our internal VPN made it crash immediately, I uninstalled it roght away
14:56:31 <rdieter> I agree knm likely does meet our minimum requirements, but that doesn't mean we shouldn't have them.
14:56:51 <rdieter> vpn is touchy
14:57:01 <ltinkl> minimum functionality varies a great deal for different people
14:57:01 <rdieter> moving on...
14:57:08 <rdieter> #topic https://fedoraproject.org/wiki/SIGs/KDE/Stability_Proposal
14:57:18 <thomasj_> Just think about the enduser experience and ship what works best.
14:57:27 <rdieter> similar as previous topic, the Stability proposal has seen little movement
14:57:31 <Kevin_Kofler> We should ship pure KDE stuff.
14:57:31 <rdieter> where do we go from here?
14:57:34 <rdieter> discuss more?
14:57:48 <ltinkl> Kevin_Kofler: preferably yes
14:57:59 <Kevin_Kofler> Re Stability, wait for a general Fedora policy.
14:58:01 <ltinkl> we just can't ship something that doesn't work
14:58:14 <ltinkl> ie. see above about my problem with knm + vpn
14:58:15 <Kevin_Kofler> It's not like 4.5 is coming tomorrow.
14:58:27 <ltinkl> how is the end user supposed to work with that?
14:58:29 <rdieter> ltinkl: right, it's important to clearly define what "doesn't work" means.
14:59:05 <Kevin_Kofler> ltinkl: There's no software with no bugs.
14:59:08 <Kevin_Kofler> NM-gnome also has bugs.
14:59:30 <ltinkl> I haven't hit one in the year I've been using it, YMMV tho
14:59:41 <Kevin_Kofler> If each time we run into a bug in KDE, we replace that component with a GNOME component, we'll end up with a GNOME spin fairly quickly. ^^
14:59:46 <rdieter> I don't think we need to wait on Fedora, to consider our own intentions wrt updates/stability.
15:00:02 <Kevin_Kofler> And I don't think we'd have fewer bugs then. ;-)
15:00:09 <rdieter> regardless, I think it's safe to say we'll still be more aggressive about that than a majority of other maintainers
15:00:31 <rdieter> Kevin_Kofler: if it's a deal-breaker bug, maybe.  it depends.
15:00:46 <rdieter> we need to help define what "deal-breakers" are
15:00:53 <rdieter> that's the whole point
15:01:02 <ltinkl> yup
15:01:20 <Kevin_Kofler> If we have a deal-breaker bug, we need to work on getting it fixed, not replace the software by GNOME stuff.
15:01:21 <thomasj_> IMHO something like ltinkl's example
15:01:22 <ltinkl> and disregard our ego a bit there, we are not the end users :)
15:01:45 <rdieter> Kevin_Kofler: of course.  the 2 actions are not mutually exclusive.
15:01:47 <Kevin_Kofler> Our end users expect KDE stuff on the KDE spin, not GNOME stuff!
15:02:05 <ltinkl> cmon
15:02:08 <rdieter> Kevin_Kofler: I get your opinion there, repeating it over and over doesn't change that.
15:02:09 <thomasj_> I think they expect in the first place working apps.
15:02:12 <jreznik> that's why I think spins are highway to hell...
15:02:13 <Kevin_Kofler> And 99.999% of our users won't give a darn about whether KNM works with RH's VPN or not. ;-)
15:02:23 <jreznik> we are over guys
15:02:28 <rdieter> yep.
15:02:34 <rdieter> good meeting. :)
15:02:44 <Kevin_Kofler> Re the stability proposal, I've already said several times why I'm against that one…
15:02:54 <rdieter> I'll brush up the wiki on those items, and take onlist for further discussion.
15:03:17 <rdieter> I hope that we can vote on proposals over the next week or 2.
15:03:22 <Kevin_Kofler> I'd call it "previous stable = second-class citizens" proposal.
15:03:22 <rdieter> #endmeeting