14:03:26 <Kevin_Kofler> #startmeeting KDE SIG Meeting - https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-10-20
14:03:26 <zodbot> Meeting started Tue Oct 20 14:03:26 2009 UTC.  The chair is Kevin_Kofler. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:51 <Kevin_Kofler> #chair than rdieter svahl SMParrish
14:04:51 <zodbot> Current chairs: Kevin_Kofler SMParrish rdieter svahl than
14:04:58 <Kevin_Kofler> So, who's present?
14:05:07 <svahl> present
14:05:12 <Kevin_Kofler> I pinged ltinkl and jreznik on #fedora-kde.
14:05:15 <rdieter> here
14:05:16 <SMParrish> here
14:07:21 <Kevin_Kofler> #topic Agenda
14:07:31 <Kevin_Kofler> So our agenda right now is quite blank...
14:08:18 <Kevin_Kofler> I suggested Eigen2 (2.0.x vs. 2.1 snapshots, updating to current).
14:09:09 <Kevin_Kofler> We could also discuss the NM applet saga again.
14:09:47 <Kevin_Kofler> Does anybody have any other topics to discuss?
14:10:03 <rdieter> virtuoso/soprano status
14:10:15 <Kevin_Kofler> Good point.
14:10:33 <SMParrish> bug triage changes coming
14:11:13 <rdieter> if we have time, phonon/trunk , PA-integration work/testing
14:11:38 <Kevin_Kofler> OK, that'll be enough...
14:11:49 <Kevin_Kofler> #topic virtuoso/soprano status
14:12:03 <Kevin_Kofler> I suggest we start with this one.
14:12:05 <Kevin_Kofler> rdieter?
14:12:29 <rdieter> saw this today, http://vizzzion.org/blog/2009/10/virtuoso-here-i-come/
14:12:50 <rdieter> so, found new virtuoso and libiodbc releases to work on (for updates)
14:13:17 <rdieter> got test builds going now.  should have something to try out soonish
14:13:53 <Kevin_Kofler> Great.
14:14:02 <Kevin_Kofler> I'd like us to ship that stuff ASAP.
14:14:14 <Kevin_Kofler> Nepomuk is basically useless as we ship it now.
14:14:45 <Kevin_Kofler> Anything else on that topic? Or should we move on?
14:14:51 <Kevin_Kofler> #chair jreznik
14:14:51 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik rdieter svahl than
14:14:53 <rdieter> I'll put things into kde/testing repo when builds are available
14:14:59 <rdieter> that's it, move on
14:15:02 * than is present
14:15:17 <Kevin_Kofler> #topic Eigen2 (2.0.x vs. 2.1 snapshots, updating to current)
14:15:34 <Kevin_Kofler> As than has brought to my attention, F12 Rawhide is shipping a 4-month-old snapshot of 2.1, I have no idea when 2.1 is supposed to get released, F10/F11 updates have 2.0.3, current is 2.0.6.
14:15:45 <Kevin_Kofler> So where do we go from there?
14:16:27 <than> i think we will do update 2.0.6 for F10/F11
14:16:37 <rdieter> I've got updates prepared here too, both 2.0.6 and 2.0.90 (snapshot), but how best to handle F-12 ?
14:17:24 <Kevin_Kofler> I'd go for the 2.0.90 snapshot for F12, I don't like going backwards.
14:17:42 <jreznik> isn't it too old for F12? any problems with snapshot? but I don't like snapshots in stable release...
14:18:02 <than> i think it's safe to use the stable release
14:18:10 <than> but we can ask upstream
14:18:11 <Kevin_Kofler> F12 has a 20090622 snapshot at the moment.
14:18:26 <rdieter> I think the only thing that needed 2.1 snapshots, was earlier koffice2 builds, but recent 2.0's are fine now too
14:18:49 <Kevin_Kofler> Yeah, they backported the needed stuff to the 2.0 branch (of course, a few days after we moved to 2.1 snapshots :-( ).
14:18:53 <than> rdieter: if so, there's no problem to switch back to 2.0.6
14:18:54 <Kevin_Kofler> What I'd like to know is when 2.1 is supposed to be out.
14:19:09 <rdieter> than: so, epoch ?
14:19:20 <than> rdieter: yes
14:19:26 <Kevin_Kofler> 2.1 has some new features.
14:19:36 <rdieter> ok
14:19:50 <Kevin_Kofler> Some non-KDE stuff might want to have those features.
14:19:54 <rdieter> I'll leave devel/ branch for the newest snapshot
14:20:23 <rdieter> the only non-kde pkg using eigen2 is avogadro
14:20:29 <than> rdieter: yes, it doesn't make sense to switch back tp 2.0.8 in rawhide
14:20:45 <than> s/2.0.8/2.0.6
14:20:49 <rdieter> the other consumers include: kdeartwork, kdeedu, kdeplasma-addons
14:21:08 <Kevin_Kofler> Not all software is currently shipped in Fedora.
14:21:28 <Kevin_Kofler> But of course, what is not packaged yet isn't important for deciding whether to revert or not.
14:21:35 <rdieter> since this is, in-effect, a static lib, if we do revert, I'd think we should rebuild those apps
14:21:51 <Kevin_Kofler> Right, I was about to point that out.
14:22:13 <Kevin_Kofler> It's a header-only library.
14:22:24 <rdieter> ok, I'll do that, revert to 2.0.6 and rebuild the depending pkgs
14:22:37 <than> rdieter: thanks
14:23:03 <Kevin_Kofler> But isn't reverting going to reduce performance of some stuff?
14:23:17 <Kevin_Kofler> Part of the 2.1 features is also performance optimizations.
14:24:00 <rdieter> we'll get 2.1 soon enough (hopefully), we'll benefit from that when the time comes
14:24:20 <Kevin_Kofler> I'm just not a fan of reverting things when there are no concrete reasons.
14:24:28 <Kevin_Kofler> Nobody had any complaints about the 2.1 snapshot.
14:25:01 <Kevin_Kofler> But it's also mostly an accident that we ended up with it in the first place.
14:25:05 <Kevin_Kofler> #chair ltinkl
14:25:05 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter svahl than
14:25:28 <rdieter> Kevin_Kofler: I could ask upstream if you want, but I have a pretty good idea what they will say.
14:25:42 <SMParrish> IMO we should talk to upstream.  If 2.1 is close then keep the snapshot.  If we are still looking at months then maybe revert
14:25:53 <rdieter> i'm not a fan of reverting either (epochs are evil and all that)
14:26:32 <than> rdieter: it's great if you could ask upstream
14:26:34 <svahl> SMParrish: +1
14:26:39 <Kevin_Kofler> Upstreams will almost always say "don't ship snapshots". They'd call things stable if they were happy with them.
14:26:45 <rdieter> OK, I'll ask, and we can go on their recommendation(s)
14:26:53 <than> rdieter: yes
14:27:26 <than> Kevin_Kofler: you already know the answer :)
14:28:14 <Kevin_Kofler> #action rdieter will consult upstream on how to proceed. Current plans are 2.0.6 for F10/F11/F12 (i.e. revert F12), new 2.0.90 snapshot for F13.
14:28:34 <Kevin_Kofler> #topic NM applet (GNOME nm-applet vs. knetworkmanager)
14:28:54 <Kevin_Kofler> So this is the next topic. I think we all agree we shouldn't stay with the GNOME nm-applet forever, the question is when to make the switch.
14:29:11 <Kevin_Kofler> I propose we switch to knetworkmanager by default NOW, in time for F12 Final.
14:29:26 <Kevin_Kofler> People are reporting it is working just fine in current F12.
14:29:27 <than> Kevin_Kofler: how stable is knetworkmanager ?
14:29:53 <rdieter> it's pretty good, works ok for many people and usecases.
14:29:59 <SMParrish> +1 on that.  I've been using it reliably for several weeks.  For both secure and unsecure network connections
14:30:13 <Kevin_Kofler> (I think we screwed up by not making the switch for the Beta. :-( When we decided to ship nm-applet in the Alpha, I said we should retry KNM for the Beta, but we forgot to follow up on that, and I'll also take part of the blame there.)
14:30:20 <zodbot> Announcement from my owner (stickster): Fedora 12 Beta is released! To download: http://fedoraproject.org/get-prerelease || Read more: http://bit.ly/fEtqX
14:30:21 <rdieter> however, it's too late to make a change like this, imo
14:30:51 <jreznik> rdieter: it is... sorry I forgot too...
14:31:16 <Kevin_Kofler> IMHO it's not too late.
14:31:30 <jreznik> we really need fine grained feature pages... I'm working on it to track what we want and what we are doing - to track it
14:31:35 <Kevin_Kofler> It's never too late to kick out GNOME stuff from the KDE spin.
14:32:19 <rdieter> Kevin_Kofler: true, in general, but network accessibility is not something to take lightly
14:33:05 <jreznik> kubuntu lost reputation because of broken nm plasmoid
14:33:06 <rdieter> and considering the app(let) is still under heavy development, doesn't ease my concerns either
14:33:53 <jreznik> not saying nm-applet is any better
14:34:56 <Kevin_Kofler> That's true, we don't know if we don't end up in a corner again like with the kde-plasma-nm in F11 GA which had serious issues, but no clear upgrade path for months until the new monolithic knm came out (and the plasmoid version is still there, but completely broken).
14:35:17 <Kevin_Kofler> If they do another big refactoring, we may end up with a mess again. :-(
14:35:33 <Kevin_Kofler> On the other hand, I'd hope they're done refactoring by now!
14:36:04 <rdieter> right, it's getting good, and in a pretty testable state now, but that's about it, for now
14:36:12 <jreznik> I they don't then we have to write our own because it takes too long...
14:36:26 <rdieter> wicd! :)
14:36:35 <rdieter> (or whatever that other thing is called)
14:36:52 <Kevin_Kofler> svahl: Any opinion here?
14:37:05 <Kevin_Kofler> You're ultimately the one accountable for the decision, as the live CD maintainer.
14:37:36 <svahl> I can workaround the size issues due to the gnome bits. And I would prefer the more stable app
14:37:52 <Kevin_Kofler> We could also call for a vote, but I think I'm already seeing which way it goes...
14:38:15 * thomasj very late here
14:38:44 <rdieter> Kevin_Kofler: voting's ok, get's people on record, adds transparency (and all that fun).
14:38:52 <than> Kevin_Kofler: you can still ttry :)
14:39:04 <Kevin_Kofler> So let's vote:
14:39:06 <svahl> we've had the knm discussion many times now but we've had always to revert to nm-applet
14:39:07 <Kevin_Kofler> +1 switch to KNM now
14:39:10 <jreznik> Kevin_Kofler: I remember your devconf experience with nm applets :D
14:39:28 <than> -1 switch to KNM now
14:39:45 <SMParrish> +1
14:39:45 <Kevin_Kofler> jreznik: That was an old snapshot of kde-plasma-nm, not the codebase we discuss now.
14:39:51 <ltinkl> I'm a bit undecided
14:39:57 <rdieter> -1
14:39:58 <svahl> -1 switch to KNM now
14:40:05 <ltinkl> is it a switch for f12?
14:40:13 <Kevin_Kofler> ltinkl: Yes, for F12 final.
14:40:15 <than> ltinkl: yes
14:40:22 <ltinkl> then -1
14:40:39 <ltinkl> I think it's really too late, we can try in rawhide
14:40:47 <jreznik> Kevin_Kofler: I know... but I have no opportunity to test it
14:40:59 <jreznik> (the new one)
14:41:15 <jreznik> but some people says it's ok for them
14:41:16 <Kevin_Kofler> And heck, even that old snapshot actually works for me most of the time, but it is fairly buggy (and it doesn't work on F11+).
14:41:32 <Kevin_Kofler> I haven't actually tried the new codebase yet either.
14:42:03 <jreznik> and it's true that nm applet crashed a lot in rawhide... but seems now it's more stable
14:42:15 <Kevin_Kofler> OK, so counterproposal: switch to KNM in Rawhide after F12 is out and try to stick with it this time.
14:42:27 <jreznik> Kevin_Kofler: +1
14:42:31 <Kevin_Kofler> +1 to that (I'd have preferred switching for F12, but as that was voted down...)
14:42:39 <rdieter> Kevin_Kofler: that's a gimme, +1
14:43:01 <than> +1
14:43:02 <rdieter> (heck, can make the switch in comps-f13 now, no need to wait)
14:43:14 <SMParrish> +1
14:43:59 <jreznik> I prepare feature page to track it (pk-qt is ready, I'd like to start on fingerprint support in f13)... I think F13 is going to be really KDE starring release
14:44:20 <ltinkl> +1
14:44:29 <Kevin_Kofler> #agreed We will stay with nm-applet for F12 as it is too late in F12's release cycle to switch. We will switch to knetworkmanager for F13 / the next Rawhide.
14:44:59 <svahl> (late) +1
14:45:14 <Kevin_Kofler> Unanimous decisions are always great. :-)
14:45:18 <Kevin_Kofler> #topic bug triage changes coming
14:45:21 <Kevin_Kofler> SMParrish?
14:45:52 <SMParrish> Starting with F13 we are going to start using the keyword Triaged to indicate a bug has been triaged
14:46:13 <Kevin_Kofler> So the abuse of ASSIGNED will stop? :-)
14:46:25 <SMParrish> the consensus among the bugzappers is that we would leave the status as NEW and let the maintainer control it
14:46:39 <Kevin_Kofler> Will we go back to using ASSIGNED when working on bugs instead of ON_DEV?
14:46:45 <Kevin_Kofler> Or should we stick with ON_DEV for now?
14:47:09 <SMParrish> That is up to you as the dev to decide
14:47:41 <Kevin_Kofler> I'd suggest staying with ON_DEV for the moment, otherwise we'd have to mass-un-ASSIGN all the pre-F13 bugs.
14:48:02 <rdieter> sensible
14:48:07 <SMParrish> IMO I would change it to assigned once you have read it and accept that it is something you will handle and then ON_DEV once you start the actual work
14:48:38 <Kevin_Kofler> In any case, mass changes are an annoyance I'd prefer avoiding. :-)
14:49:01 <rdieter> SMParrish: yeah, I like that too
14:49:05 <than> SMParrish: +1
14:49:20 <SMParrish> Yes that is why it was decided to wait until F13 so it would not mess up any existing BRs
14:50:30 <Kevin_Kofler> #info The triage team will be using the keyword Triaged instead of the ASSIGNED status to indicate triaged bugs from F13 on.
14:51:39 <Kevin_Kofler> So, do we have any consensus yet on how we'll use ASSIGNED or should we wait until the triage changes happen to see how things materialize?
14:51:45 <Kevin_Kofler> I'd suggest the latter.
14:51:48 <jreznik> I like it
14:52:42 <rdieter> meh, as long as the bikeshed stays blue
14:53:13 <Kevin_Kofler> What do you like? The suggested workflow where things go from NEW to NEW+Triaged (triaging), to ASSIGNED+Triaged (acceptance as valid by a developer) to ON_DEV+Triaged (start of work by a developer)?
14:54:01 <jreznik> Kevin_Kofler: NEW+triaged, when developers accept it to be fixed - ASSIGNED and ON_DEV when working on it...
14:54:33 <Kevin_Kofler> What's the difference then? ON_DEV for old bugs, ASSIGNED for new ones?
14:54:39 <jreznik> I have to admin I don't like assigning bugs if I'm not sure I'm going to work on it soon but I'd like to let user know, that I read it at least
14:55:00 <Kevin_Kofler> I think we should keep using ON_DEV for now until we don't have tons of bugs sitting in ASSIGNED status.
14:55:48 <Kevin_Kofler> As for the proposed workflow with the extra step, I think that's sensible, but we should be careful not to overengineer processes or we end up spending more time changing bug statuses than actually fixing things.
14:56:02 <Kevin_Kofler> We already often skip ON_DEV and MODIFIED for simple fixes.
14:57:09 <Kevin_Kofler> I think we can continue discussing this when the changes on the triage end actually happen.
14:57:16 <Kevin_Kofler> #topic phonon/trunk , PA-integration work/testing
14:57:23 <Kevin_Kofler> Last topic, rdieter?
14:58:02 <rdieter> put a phonon/trunk snapshot into devel/ branch, tested it out a bit myself, worked surprisingly well (in many respects, better than phonon-4.3.1)
14:58:25 <Kevin_Kofler> But trunk doesn't have Colin Guthrie's PA stuff yet, does it?
14:58:41 <rdieter> no, not yet, but it gets us closer to testing out the PA-integration work of colin guthrie @ mandriva
14:58:48 <Kevin_Kofler> We need his Phonon patches, and also the module-device-manager stuff in PA itself.
14:58:50 <rdieter> his work, and patches are all against trunk
14:58:55 <rdieter> right
14:59:36 <Kevin_Kofler> There's also a patch to kdebase-runtime to remove the code duplication for device selection in the Phonon KCM, otherwise all the PA patches would have to be duplicated there too.
14:59:58 <Kevin_Kofler> (The Phonon patch exports the code as an API instead. They should have done that right from the start!)
15:00:18 <than> rdieter: is there any plan when the colin patches will be commited in trunk?
15:00:30 <Kevin_Kofler> Have you talked to Lennart about committing the PA patch yet?
15:00:45 <rdieter> no plan or taking yet, from me anyway
15:00:53 <rdieter> Kevin_Kofler: you seem to be pretty on top of developments, would you be interested in leading the effort?
15:01:01 <rdieter> or helping lead anyway
15:01:04 <Kevin_Kofler> Yes.
15:01:32 <rdieter> awesome
15:01:41 <Kevin_Kofler> #info rdieter imported a Phonon trunk snapshot into the devel branch.
15:02:00 <Kevin_Kofler> #action Kevin_Kofler is going to look into getting PA integration into devel/Rawhide++/F13.
15:02:15 <Kevin_Kofler> #topic Open discussion
15:02:27 <Kevin_Kofler> OK, that's all for the agenda, we're already over time, anything important to add?
15:02:29 <rdieter> we'll have to be careful here, since a lot of those changes may end up being f13+ only
15:02:51 <SMParrish> kpackagekit official 0.5.0 released yesterday.  building for F12 and rawhide in a bit
15:03:00 <rdieter> SMParrish: woo
15:03:05 <Kevin_Kofler> Well, we can discuss backporting the PA patch once it's working in Rawhide.
15:04:06 <Kevin_Kofler> I'm good at backporting stuff, I'd do the work if Lennart allows it.
15:04:10 <ltinkl> SMParrish: we should get that into F12
15:04:20 <Kevin_Kofler> ltinkl: +1
15:04:35 <Kevin_Kofler> Stable releases are always a good thing. :-)
15:04:46 <SMParrish> ltinkl: Yes we should since its only a git snapshot atm.  will request override tag once its built and tested locally
15:05:03 <Kevin_Kofler> You want a freeze override there, not an override tag.
15:05:14 <Kevin_Kofler> Override tags are for buildroot overrides.
15:05:22 <SMParrish> Kevin_Kofler: your right  bad wording there
15:05:25 <Kevin_Kofler> Freeze overrides use regular tags. :-)
15:06:19 <Kevin_Kofler> #action SMParrish is building KPackageKit 0.5.0 (official release, released yesterday) for F12 and devel/F13.
15:06:35 <Kevin_Kofler> I guess that's all for today, thanks for attending!
15:06:37 <Kevin_Kofler> #endmeeting