13:59:07 <rdieter> #startmeeting kde-sig meeting -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-03-30
13:59:08 <zodbot> Meeting started Tue Mar 30 13:59:07 2010 UTC.  The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:59:13 <rdieter> #meetingname kde-sig
13:59:14 <zodbot> The meeting name has been set to 'kde-sig'
13:59:32 <rdieter> #chair Kevin_Kofler than_ jreznik SMParrish
13:59:33 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik rdieter than_
13:59:39 <rdieter> #topic roll call
13:59:45 <rdieter> who's present today?
13:59:50 * jreznik is here
14:00:35 <Kevin_Kofler> Present.
14:00:46 * ltinkl is here
14:00:59 * SMParrish here
14:01:24 <rdieter> #chair ltinkl
14:01:24 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter than_
14:01:31 <rdieter> alrighty
14:01:38 <rdieter> #topic kde-4.4.2
14:02:03 <jreznik> ltinkl has been uploading 4.4.2
14:02:04 <rdieter> ltinkl: you committed a bunch yesterday, where are we now?
14:02:20 <ltinkl> CVS is done, I will start building it for rawhide today
14:02:53 <ltinkl> once we get it successfully building, I'll backport it to F-1?
14:02:57 <rdieter> yes
14:03:12 <Kevin_Kofler> So will we get a dist-f*-kde442?
14:03:21 <Kevin_Kofler> Should we reuse (abuse) the kde441 tag?
14:03:21 <rdieter> ltinkl: make sure you have the respun kdebindings tarball
14:03:32 <rdieter> may as well abuse kde441 for now
14:03:37 <ltinkl> I have, I already uploaded the newer one
14:03:40 <Kevin_Kofler> Or should we ask for generic dist-f*-kde tags?
14:03:42 <jreznik> Kevin_Kofler: abuse or ask for fedora-update tag
14:03:56 <SMParrish> are we going to push this to F11 or just F12+
14:03:57 <jreznik> fedora-kde
14:04:11 <Kevin_Kofler> jreznik: They need to be per release.
14:04:19 <rdieter> SMParrish: F11 too (unless we can come up with some reason not to)
14:04:19 <Kevin_Kofler> So it would be dist-f1[123]-kde.
14:04:20 <jreznik> SMParrish: we haven't agreed on policy yet
14:04:42 <Kevin_Kofler> This is a bugfix release, so I don't see why it wouldn't be pushed to F11.
14:04:45 <Kevin_Kofler> It's not EOL yet.
14:04:50 <Kevin_Kofler> So we're supposed to fix bugs there.
14:04:54 <jreznik> Kevin_Kofler: I know - I just don't want to write whole tag name :D
14:04:59 <SMParrish> works for me
14:05:09 <ltinkl> yup, I'd go with F11 too
14:05:13 <jreznik> it's minor update, so for F11 for sure
14:05:31 <jreznik> stability policy is about x in 4.x.y
14:05:41 <SMParrish> yep
14:06:15 <rdieter> anything else wrt 4.4.2 ?  (move on?)
14:06:27 <jreznik> so - do we want to ask for dist-fx-kde tag?
14:06:45 <rdieter> jreznik: probably, I'll ask about it
14:07:10 <jreznik> and if it will take a time, we can abuse kde441 tag
14:07:33 <rdieter> abuse for this time, sure.
14:08:22 <rdieter> #topic f13-beta : issues, blockers?
14:08:36 <rdieter> f13-beta is looming, anything we should be worrying about?
14:08:50 <rdieter> not sure if pk/kpk is all sorted out yet or not.
14:08:57 <Kevin_Kofler> It should be fine now.
14:09:02 <jreznik> anyone already running f13?
14:09:14 <Kevin_Kofler> We should check that we meet the live image size target.
14:09:27 <Kevin_Kofler> If we want to be 700 MB, it shouldn't be 720 MB.
14:09:48 <rdieter> ok, anyone volunteer to try latest daily live image, checking sizes and sanity ?
14:09:52 <Kevin_Kofler> (We may get away with e.g. 701 with overburn, but nothing drastic.)
14:10:10 <Kevin_Kofler> We should also run adamw's desktop testcases on the KDE spin.
14:10:18 <jreznik> yes, we should
14:10:35 <Kevin_Kofler> We're really supposed to pass all of these, but who knows what's looming.
14:10:52 <rdieter> http://alt.fedoraproject.org/pub/alt/nightly-composes/kde/
14:11:01 <rdieter> by the looks of it, we are indeed oversize a bit
14:11:02 <jreznik> I was working on rhel testcases - we should use it for fedora too
14:11:39 <Kevin_Kofler> 707/709 might be overburnable, but it's not very safe.
14:12:00 <jreznik> it's too much
14:12:02 <Kevin_Kofler> We should get to 700 MiB.
14:12:30 <Kevin_Kofler> jreznik: Want me to try to overburn those to see if it works? :-)
14:12:40 <Kevin_Kofler> But it depends on the media and probably also on the burner.
14:12:44 <Kevin_Kofler> It's not very safe.
14:12:44 <jreznik> Kevin_Kofler: it depends on media
14:12:45 <rdieter> jreznik: I worked on some basic test cases on the wiki too last week, having trouble finding them atm though
14:13:06 <jreznik> I'm not using CD-R anymore
14:13:14 <jreznik> not DVD-R
14:13:21 <jreznik> it's just last century technology :D
14:13:28 <rdieter> nvm, it was just koffice
14:13:38 <rdieter> http://fedoraproject.org/wiki/SIGs/KDE/KOffice_test_plan
14:13:41 <jreznik> rdieter: I saw koffice test case
14:13:45 <rdieter> ok
14:13:58 <jreznik> we should have some system for test plans
14:14:04 <rdieter> we indeed should flesh that out to include more major or important parts of our spin
14:14:09 <rdieter> :)
14:14:33 <rdieter> #topic test plans
14:14:50 <jreznik> no one is using f13 and we hope, it's ok :) not a good release plan
14:14:59 <Kevin_Kofler> https://fedoraproject.org/wiki/Test_Results:Fedora_13_Beta_RC1_Desktop
14:15:03 <rdieter> how about a test plan template, to making writing new ones easier
14:15:09 <Kevin_Kofler> These are adamw's test plans.
14:15:38 <rdieter> ah, nice.  let's try to build on that then
14:16:01 <rdieter> I can certainly help to do that.
14:16:13 <Kevin_Kofler> We should at least test those.
14:16:28 <jreznik> we have quite detailed test plan for plasma desktop + some important parts of desktop
14:16:49 <jreznik> these tests are really very generic
14:16:55 <rdieter> yes, except no one has offered to actually do any testing, except say that it's a good idea so far
14:16:59 <Kevin_Kofler> For Alpha, we didn't even get around to test those, the only result was my apriori report of KPackageKit breakage (without actual testing, I just knew it couldn't possibly work as shipped).
14:16:59 <jreznik> like try to boot and observe
14:17:15 <rdieter> I'll try to do it, but won't have much time today
14:17:41 <jreznik> I can do it tmrw - new bigger hdd for my workstation -> reinstall
14:17:46 <jreznik> we should eat our dog wood
14:17:47 <jreznik> food
14:18:00 <rdieter> excellent, in the meantime, get what you have on the wiki asap too.
14:18:08 <jreznik> ok
14:18:35 <jreznik> and we should have test plan not only for new releases but for updates too
14:18:56 <Kevin_Kofler> 713404	/var/tmp/nightly-composes/kde/kde-x86_64-20100324.21.iso
14:18:56 <Kevin_Kofler> 726732	/var/tmp/nightly-composes/kde/kde-x86_64-20100326.17.iso
14:19:05 <jreznik> and do not push updates before someone clicks over all test cases
14:19:13 <Kevin_Kofler> Hmmm, 13 MiB bloat between March 24 and March 26.
14:19:22 <Kevin_Kofler> What happened?
14:20:04 <Kevin_Kofler> Though it went down by about that between March 22 and 23, so it may just have been some missing dependency or something.
14:21:47 <Kevin_Kofler> jreznik: I think that for bugfix releases, that's way overkill.
14:22:21 <Kevin_Kofler> (I'm also unhappy about the FESCo decision to make KDE updates, among others, require extra scrutiny.)
14:22:32 <jreznik> Kevin_Kofler: for bugfix releases some limited test is enough - mostly target on bugs fixed in bodhi
14:22:42 <Kevin_Kofler> We're already doing our job in a way which makes sense.
14:23:11 <jreznik> what's required?
14:23:43 <Kevin_Kofler> At least +1 karma from a tester in a group to be defined later.
14:24:01 <Kevin_Kofler> The proposal which was voted was vague on that.
14:24:03 <jreznik> Kevin_Kofler: but that's what we really need
14:24:18 <rdieter> I have no problem with requiring tester verification
14:24:32 <rdieter> frankly, we do that informally already
14:24:43 <jreznik> of course, we should have some intruder there :D
14:24:54 <Kevin_Kofler> I've queued one or the other kdelibs update directly to stable with no testing. :-)
14:25:22 <Kevin_Kofler> And it always ended up working. If I have any doubts about that, I will ask for it to be tested. :-)
14:25:40 <Kevin_Kofler> I think all this focus on testing is overrated, it will drag developer time away from actually fixing things.
14:25:42 <rdieter> Kevin_Kofler: you're playing russian roullete, of course
14:26:51 <Kevin_Kofler> Especially in SIGs like ours where there's a chronic lack of testers.
14:26:52 <rdieter> let's move on
14:27:09 <jreznik> if we define what we want to test...
14:27:10 <Kevin_Kofler> I tried to get some KDE QA team organized, but I didn't really get anywhere.
14:27:24 <jreznik> Kevin_Kofler: we don't need QA team
14:27:44 <jreznik> just some kind of process and rules to set up what has to be done
14:27:44 <rdieter> #topic open discussion
14:27:52 <Kevin_Kofler> The people who were interested were overwhelmed by the bureaucracy of joining Fedora QA and KDE SIG and weren't willing to spend time on IRC to be reachable when we need testing.
14:28:07 <jreznik> I remember that time
14:28:46 <Kevin_Kofler> We need dedicated testers if we don't want testing to take time away from development.
14:29:02 <rdieter> Kevin_Kofler: yes, it's a work in progress
14:29:27 <rdieter> similarly about bugs and triaging
14:29:45 <Kevin_Kofler> Well, for triaging, SMParrish is doing good work.
14:30:02 <Kevin_Kofler> I guess he'd probably appreciate more helping hands, but at least we have somebody. :-)
14:30:05 <rdieter> agreed, except for "some" who suggest that triagers need to do more.
14:30:31 <jreznik> and packagers too
14:30:51 <rdieter> ie, recent "kde-sig upstreaming" flamage
14:30:54 <Kevin_Kofler> It's the user's job to report bugs upstream.
14:31:09 <Kevin_Kofler> Middlemen just make communication harder.
14:31:25 <Kevin_Kofler> Having some triager, packager or whatever upstream the bug is generally unhelpful.
14:31:28 <rdieter> there are exceptions of course.
14:31:46 <SMParrish> this topic comes up about every 6 months.  Going to put the process we use on the wiki so when it comes up again we can point them to it
14:31:51 <rdieter> important or reproducible bugs, are cases where we can help take an active role
14:32:03 <Kevin_Kofler> Those crash reports with clear backtraces, especially if the packager can reproduce them, are probably better understood by the packager than the reporter.
14:32:13 <rdieter> SMParrish: thank you
14:32:26 <Kevin_Kofler> But often the reporter knows a lot more about the bug than the packager.
14:32:56 <rdieter> SMParrish: ping us onlist when you have things documented, for feedback
14:32:58 <Kevin_Kofler> The problem with ABRT crash reports is that they're just too many.
14:33:12 <Kevin_Kofler> And we only see the tip of the iceberg in KDE thanks to DrKonqi catching most stuff.
14:33:51 <SMParrish> what I would like to suggest is we stop putting ABRT on the KDE images until such time as ABRT reports directly to bugs.kde.org and just rely on DrKonqi
14:33:57 <rdieter> except when things get restarted with --nocrashhandler
14:34:00 <rdieter> :)
14:34:00 <Kevin_Kofler> ABRT only gets things which slip through DrKonqi, either because they're in GUI-less daemons (KCrash is part of kdeui) or because they're repeated crashes in something like Plasma which uses --nocrashhandler after the first crash.
14:34:28 <Kevin_Kofler> SMParrish: +1, I already proposed that.
14:34:38 <jreznik> I think we should know about crashes, even dr. konqui ones
14:34:39 <Kevin_Kofler> But it has been shot down.
14:35:05 <Kevin_Kofler> jreznik: I think crashes belong upstream, like all bugs.
14:35:23 <Kevin_Kofler> Almost all bugs are with the upstream software.
14:35:32 <Kevin_Kofler> Only few issues are distro-specific.
14:36:05 <Kevin_Kofler> Normally upstream can identify those fairly quickly.
14:36:34 <Kevin_Kofler> They tend to know what their code does and why it doesn't work, even if the why isn't their fault.
14:36:36 <jreznik> yes, but at least we should know that something is crashing more often and do "something" more
14:37:02 <jreznik> like kpixmapcache - we knew that's the problem, we were checking upstream bz... testing fix...
14:38:00 <rdieter> obviously the high-level goal is to make fedora better.
14:38:38 <rdieter> any short (or even long-term) suggestions on how to adapt bug-handling to help achieve that?
14:39:33 <SMParrish> guess it going to come down to me filing the bugs upstream if the reporter does not
14:39:36 <Kevin_Kofler> Maybe we can set up some autoforwarder which forwards the bugs to bugs.kde.org, and somehow forwards any replies back to the CC list of the Fedora bug.
14:40:17 <Kevin_Kofler> It might be possible to programmatically do that, if we set up e.g. fedora-bug-forwarder@some.domain.example.com.
14:40:19 <rdieter> SMParrish: I'd say do so only in limited cases... say 1. it's an important/serious bug (vague, yes)  2. it's reproducible
14:40:36 <Kevin_Kofler> And a KDE BZ account with that.
14:40:38 <rdieter> and *maybe* also if reporter's backtrace clearly highlights a problem
14:40:50 <rdieter> but that's harder to do
14:40:53 <Kevin_Kofler> It'd just have to keep track of the ID matchup between KDE bug and Fedora bug.
14:40:58 <SMParrish> rdieter: That would work for me
14:46:11 <rdieter> #action SMParrish to work on documenting kde bug triage policy/procedure, including cases were kde-sig will upstream bugs on behalf of reporters
14:46:58 <Kevin_Kofler> Another thing I'd like to ask:
14:47:21 <Kevin_Kofler> KMid 2 tarballs are now named kmid-2.* instead of kmid2-0.* by upstream.
14:47:40 <Kevin_Kofler> So should I get the package renamed back to kmid (and ask for another rename review, I guess :-/ )?
14:47:45 <Kevin_Kofler> Or should I just keep using kmid2?
14:48:21 <rdieter> up to you, I'd ask upstream what they'd prefer the package to be called and whether the kmid name is something that's going to stay or change anytime soon. :)
14:48:38 <Kevin_Kofler> Asking upstream sounds like a good idea, I can do that.
14:48:55 <rdieter> but offhand, renaming back to kmid is going to be the likely result, imo
14:49:28 <Kevin_Kofler> I guess I really jumped too early on the KMid 2 bandwagon (because the KMid snapshot we were shipping was just crap), it was a big PITA:
14:49:38 <Kevin_Kofler> * new review for kmid2 to replace kmid
14:49:42 <Kevin_Kofler> * new review for aseqmm
14:49:53 <Kevin_Kofler> * rename review for drumstick (formerly aseqmm)
14:50:18 <ltinkl> btw, what happened to rosegarden, is it still being developed?
14:50:21 <Kevin_Kofler> * some fun patching drumstick to the correct SVN revision for a kmid2 release with no matching drumstick release (no, I wasn't going to use the bundled copy)
14:50:38 <Kevin_Kofler> * and now I guess a rename review for kmid2 back to kmid
14:50:53 <Kevin_Kofler> ltinkl: It is, as a Qt (4) only app. :-(
14:51:02 <Kevin_Kofler> They dropped all the KDE integration instead of porting it to KDE 4.
14:51:19 <Kevin_Kofler> The code is also full of WTFs.
14:52:19 <Kevin_Kofler> They also default to nonstandard UI styling (but at least they allow to disable that stuff in the preferences).
14:53:25 <Kevin_Kofler> But ask oget if you want to know more about Rosegarden, I don't package or use it.
14:53:45 <Kevin_Kofler> I just curiously looked at the code and was quite disgusted.
14:55:29 <Kevin_Kofler> But I don't think this is material for a KDE SIG meeting. ;-)
14:56:00 <rdieter> alright, I think we're out of topics and time for today, thanks everyone
14:56:07 <Kevin_Kofler> One more thing: I started looking at packaging Kivio from KOffice 1 separately.
14:56:07 <rdieter> #endmeeting