fedora-meeting
LOGS

16:04:54 <rdieter> #startmeeting - KDE SIG Meeting -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-06-23
16:05:21 <rdieter> who's present today?
16:05:28 <Kevin_Kofler> Present.
16:05:46 * SMParrish_ here
16:05:51 <than> Kevin_Kofler, gratulaion!
16:06:09 * jreznik is here
16:06:20 * ltinkl present
16:06:20 * than is here
16:06:40 <rdieter> than: here afterall ?
16:06:52 <ltinkl> no, that is not than
16:06:55 <ltinkl> ^^
16:06:58 <than> i'm just half here
16:07:29 <rdieter> First, off, congratulations to Kevin_Kofler  for being elected to FESCo
16:07:40 <SMParrish_> aye, congrats
16:07:44 <jreznik> congrat!
16:07:49 <ltinkl> gratz from me as well Kevin
16:08:00 <rdieter> #info Kevin_Kofler elected to FESCo, any issues to bring up in the FESCo meeting?
16:08:21 <rdieter> I'll skip forward to the related item in the agenda.
16:08:56 <rdieter> #topic Kevin_Kofler elected to FESCo, any issues to bring up in the FESCo meeting?
16:08:58 <rdieter> there.
16:09:25 <Kevin_Kofler> FYI, the FESCo meeting is on Friday, so you have 3 days to think of stuff. :-)
16:10:10 <jreznik> I'd like to prepare another feature page for F12 and KDE 4.3, but there's lot of time before it reach FESCo meeting
16:10:23 <Kevin_Kofler> Don't worry, there will be more meetings. :-)
16:10:32 <jreznik> :)
16:11:17 <Kevin_Kofler> In any case, from the election results, it like quite some people are fed up with the GNOME tyranny.
16:11:49 <ltinkl> are the exact results out already?
16:12:09 <rdieter> now now, please focus on bringing people together, working together, collaboration.  that kind of talk is a wee bit divisive
16:12:11 <bpepple> Kevin_Kofler: not to jump in, but I think you've got your head up you ass with that statement.
16:12:19 <abadger1999> Yes, check fedora-announce
16:12:42 <Kevin_Kofler> Full results: https://www.redhat.com/archives/fedora-announce-list/2009-June/msg00015.html
16:13:55 <rdieter> bpepple: that's another way to put it.  point taken.
16:14:05 <Kevin_Kofler> I got 48% of the achievable score, or the equivalent of 148.09 people voting full points (which also means at least 149 people gave me a non-zero score).
16:14:33 <bpepple> rdieter: sorry to butt in, but I hate that see kind of KDe/GNOME sentiment.  gets my blood boiling. ;)
16:14:42 <bpepple> anyway, back to work,
16:14:43 <rdieter> bpepple: +1!
16:15:21 <jreznik> it's chance for us to be more involved in fedora development
16:15:22 <rdieter> next topic...
16:15:47 <rdieter> #topic RPM Macros for packaging, http://fedoraproject.org/wiki/SIGs/KDE/PackagingCleanup#Macros
16:16:19 <rdieter> initially, seems a bit over the top, macro'izing everything and the kitchen sink, but I think there's value to be had in there somewhere. :)
16:16:36 <Kevin_Kofler> I think we should have macros for the common directories.
16:17:01 <Kevin_Kofler> Especially because they might in principle change (though it's unlikely they will, due to backwards compatibility concerns).
16:17:19 <Kevin_Kofler> The list at the link comes from MathStuf.
16:17:40 <rdieter> I'm torn, yeah.  Now that things have stabilized, part of me wants to go the other direction, and try to minimize kde-specific macros.
16:18:14 <rdieter> anyway, how about we through this at the ml's, for further discussion, and see where it goes.
16:18:36 <Kevin_Kofler> For the KDE 3 mimelnk dir: "KDE3; why do KDE4 apps still use this" - I guess for those remaining kdelibs3 apps.
16:18:54 <rdieter> Yes, that's kde3 only
16:18:57 <ltinkl> having those macros in place is handy, alto it means a lot of work for us to clean up the .spec files
16:19:01 <Kevin_Kofler> But I don't think we have kdelibs3 file managers anymore now that Krusader is KDE 4.
16:19:26 <rdieter> ltinkl: that's a concern too.
16:19:53 <ltinkl> but I guess it's worth the effort in the end
16:21:11 <rdieter> I'll ask MathStuf to take it to the lists then, agreed?
16:21:56 <Kevin_Kofler> Yes.
16:21:57 <jreznik> ok
16:21:57 * ltinkl brb
16:22:24 <rdieter> #action MathStuf to take http://fedoraproject.org/wiki/SIGs/KDE/PackagingCleanup#Macros to mailing lists for further discussion
16:22:56 <rdieter> #topic critical path packages - does it affect us? should it? how?
16:23:08 <rdieter> fyi, http://skvidal.wordpress.com/2009/06/22/critical-path-packages/
16:23:34 <Kevin_Kofler> I've put this up after noticing KDE packages are notoriously absent from his list.
16:23:41 <rdieter> being at the FAD that came up with that idea, I'm naturally ok with it.
16:23:46 <Kevin_Kofler> So I wonder what our position on this should be.
16:24:06 <rdieter> the point is, these are pkg's that have higher scrutiny release, qa, testing -wise.
16:24:08 <jreznik> it should be great for lot of low level packages to avoid totally breakage like dbus issue
16:24:37 <rdieter> So, from a selfish point of view, not being on that list means less work. :)
16:24:37 <Kevin_Kofler> While I don't think we need more bureucracy hindering our updates, as history has shown it not to be needed, having GNOME on the list and KDE not means we're once against second-class citizens.
16:24:44 <Kevin_Kofler> So I have mixed feelings about this.
16:25:01 <ltinkl> well, Gnome packages shouldn't be part of that list imo
16:25:01 <SMParrish_> but I dont think we want kde on the list
16:25:33 <jreznik> we have lot of eyes on updates-testing
16:25:34 <rdieter> well, one of the "use case" items as part of the critical path was "login", "do updates"
16:25:45 <Kevin_Kofler> The rationale for including a GUI is that if the GUI is broken, end users are really stuck.
16:26:09 <Kevin_Kofler> It's not just that they don't necessarily know how to use the terminal, it's that they don't even know how to get to runlevel 3.
16:26:34 <jreznik> but we really want KDE SIG member in that group... so he can stop updates which are wounding us
16:26:50 <SMParrish_> jreznik:  +1
16:27:18 <rdieter> currenty, the signoff group includes releng and qa.  I'm in releng, if that makes anyone feel better.
16:27:45 <Kevin_Kofler> I think some work is really needed on GRUB usability. Our proprietary competition has ways to get to a command prompt or a "repair console" depending on the version, Fedora could easily offer that (it's what runlevel 3 is for).
16:28:01 <Kevin_Kofler> But that's outside of our (KDE SIG's) scope.
16:29:27 <Kevin_Kofler> A related topic is that we could really use a QA (as in testing - triaging is already covered by SMParrish_) volunteer.
16:29:48 <Kevin_Kofler> Right now, testing is done either by developers or by users who just step in to test something once.
16:29:54 <Kevin_Kofler> We don't have dedicated testers.
16:31:11 <rdieter> good idea.
16:32:15 <rdieter> #help volunteers to help qa kde-related items
16:32:46 <jreznik> but first we need to set what we want to test
16:33:02 <jreznik> list of MUST be checked etc...
16:34:14 <rdieter> any volunteers to start on such a checklist of qa items?  It can be a work-in-progress of course.
16:35:07 <jreznik> test plan would be nice for feature page test plan either
16:35:37 <Kevin_Kofler> Can we really come up with a systematic plan to test the entire KDE desktop?
16:35:41 <Kevin_Kofler> I don't think it's possible.
16:35:58 <ltinkl> that's a huge and long term task indeed
16:35:59 <Kevin_Kofler> Basic QA is just "try to use the desktop and report any breakage you notice".
16:36:00 <rdieter> It doesn't have to be exhaustive initially (or ever)
16:36:27 <rdieter> but at least targetting some common use-cases would be a good start
16:36:47 <jreznik> Kevin_Kofler: but there should be something like test this, this and this as these are crucial parts of desktop
16:36:55 <Kevin_Kofler> And usually there'll be something specific to test for the update (e.g. "does WPA in kde-plasma-nm work?" for a kde-plasma-nm update, "do Python plasmoids work without python-devel installed?" for my recent kdebindings fix etc.).
16:38:04 <rdieter> right, stuff fixed by updates, can include tests/checks for regressions
16:38:49 <rdieter> it'll be a (long) journey, with no real final destination.
16:39:11 <rdieter> alright, I'll bite this one, and come up with some initial ideas.
16:39:33 <rdieter> #topic sharing brand with upstream
16:39:37 <rdieter> jreznik: any news/progress?
16:40:25 <jreznik> rdieter: I talked to pinheiro
16:40:49 <jreznik> and sent some mails to fedora-kde/design list
16:41:00 <jreznik> mostly it's about sharing
16:41:04 <jreznik> not replacing fedora brand
16:41:13 <jreznik> but I'm skeptic about schedules... :(
16:41:23 <Kevin_Kofler> So far, the only feedback we got from the Fedora Design Team was from Máirín Duffy and it was negative.
16:41:45 <jreznik> Kevin_Kofler: and from Nicu and it was mostly negative
16:42:00 <jreznik> I asked pinheiro to contact them directly
16:42:04 <Kevin_Kofler> I haven't seen that one, I guess he only sent it to the design list, not the KDE one.
16:42:15 <jreznik> Kevin_Kofler: it's possible, check design list
16:42:20 <rdieter> I think the negatively is mostly in the form of not knowing exactly what the process will be yet
16:42:34 <jreznik> indeed
16:43:03 <rdieter> it'll be a learning process for everyone involved, but I (still) strongly believe it will be a worthwhile one
16:43:04 <Kevin_Kofler> Máirín's objections are basically 2: 1. they're worried about schedule pressure and 2. she doesn't like the idea of KDE-specific themes.
16:43:13 <jreznik> everyone switch to defence mode when you want more work from him :D
16:43:44 <Kevin_Kofler> The schedule issue is an open point of contention and it seems communication is also lacking.
16:43:47 <rdieter> 2.  is that really an issue?    The artwork team hasn't really helped make any kde themes to date, why is this any different?  am I missing something?
16:43:52 <jreznik> with new proposed schedules by martin sourada it seems more possible
16:44:20 <Kevin_Kofler> It seems the Design Team's position is that the schedules are fine, only F11 was particularly late, but the lateness in F7 to F10 was normal.
16:44:46 <Kevin_Kofler> On the other hand, we basically agreed in past meetings that we need their output much earlier.
16:44:46 <rdieter> interesting.  really?  normal?  ouchie.
16:45:19 <jreznik> we're are mostly on our own so any help from upstream is great for us I think
16:45:31 <rdieter> well, ok, once we have a Release name, and some initial theming ideas, I assume this process can start to move forward.
16:45:35 <jreznik> I'd like to try it even it means more work
16:45:41 <rdieter> jreznik: +1
16:46:12 <jreznik> opensuse and kubuntu are joining too
16:46:25 <rdieter> #action jreznik to continue as liason between fedora-art team and upsream kde art folks in "sharing branding"
16:46:53 <rdieter> #topic Fedora 12 KDE 4.3 feature page
16:47:19 <jreznik> ok, again for me - than asked me to prepare feature page
16:47:23 <rdieter> totally +1 for this, helps the marketing/qa machine, if nothing else.
16:47:33 <ltinkl> I guess jreznik with my help will create this page
16:47:42 <rdieter> thanks guys
16:47:45 <Kevin_Kofler> jreznik: About the artwork stuff: Sure that offloading work to upstream could in principle mean less work for us, but I'm not convinced that it will really mean that.
16:47:56 <jreznik> what we want to market as great feature for 4.3/12?
16:48:05 <Kevin_Kofler> I think it just means we'll have some stale KDE 4.3 look elements in our 4.4 and 4.5 updates. :-(
16:48:10 <ltinkl> 2 items worth mentioning: polkit-1 and Solid/DeviceKit
16:49:00 <Kevin_Kofler> About the 4.3 feature page: my main issue with those feature pages is that we advertise something as a "new feature" in F12 when it'll have been out as an F11 update for months already.
16:49:41 <rdieter> Kevin_Kofler: true in part, but it's still good for marketting, esp for the "new" items ltinkl mentioned
16:49:42 <Kevin_Kofler> ltinkl: The thing is, mentioning items with nobody working on implementing them is not of much use.
16:49:54 <ltinkl> ha :)
16:49:56 <rdieter> Kevin_Kofler: *we* are (well, ltinkl  and jreznik )
16:50:15 <Kevin_Kofler> Is anybody working on DeviceKit support in Solid yet?
16:50:22 <ltinkl> I already have a working Solid-DeviceKit
16:50:38 <ltinkl> http://websvn.kde.org/branches/work/solid-devicekit/
16:50:52 <ltinkl> and jreznik committed the polkit-1-qt port
16:50:53 <jreznik> I'm not sure it's time to mention polkit-qt-1... it's really first tryout
16:51:09 <jreznik> http://websvn.kde.org/branches/work/polkit-qt-1/
16:51:34 <ltinkl> so we should really advertise something we have worked hard on :)
16:52:34 <rdieter> I assume this work will be targetted for kde-4.4 ? (other?)
16:52:43 <ltinkl> yup, that's the plan
16:52:53 <rdieter> upstream kde-4.4 that is, we'll want to include/use it asap of course
16:53:00 <Kevin_Kofler> But we can backport it, we'll basically have to backport the PolicyKit stuff.
16:53:14 <ltinkl> once KDE 4.3 has been released, the trunk opens for 4.4 development and we merge our work branches back
16:53:29 <rdieter> coolness. anything else feature-page related?
16:53:30 <ltinkl> yup and we, as in Fedora-KDE, can backport it
16:53:31 <jreznik> I hope it's stuff for 4.4
16:53:34 <Kevin_Kofler> How well does Solid-DeviceKit work? And what kind of devices does it support?
16:53:50 <Kevin_Kofler> Long term, only the daemons for disks and power management are here to stay.
16:53:57 <ltinkl> Kevin_Kofler: works pretty fine, but supports only Disks and PowerManagement so far
16:54:00 <Kevin_Kofler> We're supposed to use libudev for tasks like device enumeration.
16:54:28 <ltinkl> Kevin_Kofler: not really, details after the meeting, long story :)
16:54:38 <Kevin_Kofler> The main (not -disks nor -power) DeviceKit daemon is deprecated (at least according to blog posts I found).
16:55:15 <Kevin_Kofler> So if we design for that one, we'll be stuck again. :-(
16:55:24 <Kevin_Kofler> But we can discuss this in #fedora-kde.
16:55:43 <ltinkl> yup
16:55:53 <rdieter> I think that's it for the agenda (unless I missed something).
16:56:00 <rdieter> #topic open discussion
16:56:15 <jreznik> gcds?
16:56:25 <jreznik> anyone going to gran canaria?
16:56:48 <ltinkl> http://www.grancanariadesktopsummit.org
16:56:49 <rdieter> sadly, not I this time.
16:57:22 <SMParrish_> rdieter: still doing FUDCon Berlin?
16:57:28 <jreznik> something what can I do for us there?
16:57:29 <rdieter> secondary issue, for any ev'er who *is* going, interesting is proxy'ing for me?
16:57:32 <ltinkl> jreznik is going, so direct any questions/queries towards KDE developers to him :)
16:57:38 <rdieter> SMParrish_: no
16:59:59 <rdieter> #topic gran caria summit
17:00:05 <rdieter> #link http://www.grancanariadesktopsummit.org
17:00:24 <rdieter> looks like time is out for today, thanks all
17:00:41 <rdieter> #endmeeting