14:03:56 <jreznik> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-05-04
14:03:56 <zodbot> Meeting started Tue May  4 14:03:56 2010 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:23 <jreznik> #meetingname kde-sig
14:04:23 <zodbot> The meeting name has been set to 'kde-sig'
14:04:55 <jreznik> #chair Kevin_Kofler than ltinkl rdieter_work SMParrish
14:04:55 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik ltinkl rdieter_work than
14:05:03 <jreznik> #topic roll call
14:05:09 <jreznik> who's present"
14:05:11 <jreznik> ?
14:05:12 <Kevin_Kofler> Present.
14:05:14 * SMParrish here
14:05:18 * Sho_ waves
14:06:03 * than is half here, i have headache, will leave office earlier
14:06:07 <jreznik> let's wait few seconds for other guys
14:06:17 * ltinkl is here
14:06:38 <jreznik> than: ok, np... I'm actually pto with my eyes in pain :)
14:07:11 <Sho_> first topic: health of the kde sig members
14:07:12 <Sho_> ;)
14:07:39 * ltinkl coughs
14:07:40 <than> jreznik: we will try make short meeting tody
14:07:58 <jreznik> #info Kevin_Kofler than ltinkl SMParrish Sho_ present
14:08:06 <jreznik> #topic agenda
14:08:57 <jreznik> we have two topics now + kde 4.4.3 update status?
14:09:17 <Sho_> there's also a few packages where f12 is newer than f13 right now
14:09:21 <Sho_> arora and cmake ..
14:09:33 <Kevin_Kofler> (in kde-redhat)
14:09:37 <Kevin_Kofler> (not in official repos)
14:09:43 <Sho_> yep
14:10:11 * Kevin_Kofler wonders what happened to rdieter…
14:11:08 <than> jreznik: 1 topic?
14:11:16 <Kevin_Kofler> jreznik: I think that's all, let's please start.
14:11:22 <jreznik> Kevin_Kofler: ok
14:11:39 <jreznik> let's start with 4.4.3
14:11:45 <than> it seems kde-4.4.3 was built with wrong tag (i386)
14:11:46 <jreznik> #topic 4.4.3 update status
14:12:16 <Kevin_Kofler> We have built all our packages, but the special tag was misconfigured (rdieter created them for the first time and he forgot a step).
14:12:18 <than> we have to rebuilt it again with correct tag
14:12:25 <Kevin_Kofler> So now all the 32-bit pkgs are i386.
14:12:38 <Kevin_Kofler> We need to rebuild all the non-noarch packages (all kde*, only oxygen-icon-theme should be fine).
14:12:44 <than> is it affected only in f12?
14:12:51 <Kevin_Kofler> All 3.
14:12:59 <Kevin_Kofler> F11 should be i586, F12 and F13 should be i686.
14:13:04 * than is looking at f11
14:13:24 <ltinkl> how to fix this?
14:13:25 <than> it's affected in f11 too
14:13:26 <jreznik> #info kde-4.4.3 was built with wrong tag (i386)
14:14:33 <than> Kevin_Kofler: do you know if rex already fixed this tag issue?
14:14:55 <jreznik> really all 3
14:15:10 <Kevin_Kofler> than: He fixed the special tags.
14:15:17 <Kevin_Kofler> We need to rebuild the packages now, but we can start now.
14:15:20 <Kevin_Kofler> It should work now.
14:15:31 <than> Kevin_Kofler:  for f11/f12/f13?
14:15:36 <Kevin_Kofler> Yes.
14:15:39 <Kevin_Kofler> devel is fine.
14:15:53 <Kevin_Kofler> We should append .1 to all the Release tags and rebuild.
14:15:55 <than> ok, lukas, could you please take care of the rebuilt?
14:16:00 <ltinkl> ok
14:16:07 <than> ltinkl: thanks
14:16:09 <Kevin_Kofler> (e.g. Release: 1%{?dist}.1)
14:16:15 <ltinkl> all packages in all distros right?
14:16:21 <than> ltinkl: just bump the release and build again
14:16:23 <Kevin_Kofler> F11/F12/F13.
14:16:23 <ltinkl> F11/F12/F13
14:16:26 <Kevin_Kofler> No need to rebuild devel.
14:16:26 <ltinkl> yup
14:16:41 <than> no need to build noarch packages
14:16:47 <than> kde-l10n/oxygen
14:16:51 <ltinkl> no tagging required right?
14:17:20 <than> ltinkl: no
14:17:35 <jreznik> #action ltinkl to rebuild all arch dep. packages in F-11, F-12, F-13
14:18:12 <ltinkl> move on?
14:18:16 <than> ltinkl: you need dist-f11|f12|13-kde443
14:18:23 <than> by make build
14:18:24 <ltinkl> than: I know
14:19:05 <jreznik> ok, move on
14:19:10 <jreznik> #topic List of critical KDE packages for new update policy (requested by FESCo)
14:19:23 <Kevin_Kofler> So FESCo asked me to bring this up in our meeting.
14:19:45 <Kevin_Kofler> They want a list of packages we consider critical for updates so they can put extra bureaucracy on them. :-/
14:19:58 <jreznik> [] - empty list :)
14:20:04 <Kevin_Kofler> Mind you, all packages will get extra bureaucracy, but critical ones will get more of it.
14:20:37 <jreznik> I understand why but it's overdesigned and overbureaucracy
14:20:51 <Sho_> Isn't there a cliche about Austrians liking bureaucracy? ;)
14:21:04 <che> no thats germans
14:21:10 <Kevin_Kofler> che: +1 ^^
14:21:11 <che> and it only a myth
14:21:18 * che is german
14:21:26 <Sho_> nah, I'm pretty sure it was specifically about people living in Vienna actually
14:21:32 <Sho_> anyway, not meeting business obviously, sorry ;)
14:21:34 <che> a proper process != overhead
14:21:48 <Kevin_Kofler> In any case I'm also for the empty list.
14:22:05 <jreznik> let's take it seriously now ;-)
14:22:09 <jreznik> empty list is win
14:22:20 <che> if no one has objections id love to add my opinion
14:22:57 <jreznik> in case we are not allowed to have empty list - that means all kde could be in critical path as we have very few packages and all packages are connected/dependent...
14:23:19 <che> as a constant user of development packages/rawhide id see everything related to a bootup process in runlevel 3 as critical ;)
14:23:25 <SMParrish> While not everyone agrees with the direction FESCO is taking, we still have to work within the guidelines.  An empty list is not the answer, we need to give the a real list
14:23:47 <jreznik> SMParrish: yes, but real list = nearly whole KDE
14:24:31 <SMParrish> jreznik: why should it include it all.  I would say kdebase libs as a start
14:24:41 <Kevin_Kofler> How do you define what's critical?
14:24:45 <than> i would add  kdelibs/kdebase-workspace to the list
14:24:48 <Kevin_Kofler> IMHO it's impossible.
14:25:03 <than> it the enpty list is really not allowed
14:25:07 <Kevin_Kofler> And critical packages are dep-transitive.
14:25:18 <Kevin_Kofler> kdebase-workspace + its deps = half of the distro
14:25:18 <jreznik> Kevin_Kofler: exactly
14:25:29 <Kevin_Kofler> Even eet, an Enlightenment package, would get dragged in.
14:25:39 <Kevin_Kofler> (kdebase-workspace requires qedje which requires eet.)
14:26:37 <jreznik> and we usually do batch updates - whole KDE SC packages - all packages depends on kdelibs, so it blocks whole update
14:26:39 <SMParrish> Kevin_Kofler: they asked for a list we give it to them.  the fact that if pulls in a ton of extraneous stuff is what they will have to work through
14:26:47 * ltinkl notes the command "rpmdev-bumpspec -r --comment="- rebuild against correct tag" F-1{1,2,3}/*.spec" for later usage :)
14:28:36 <jreznik> another thing is - we have to assure that our update is not broken, but it's task for us - KDE SIG, as I'm not sure anyone else in Fedora is interested in it
14:28:53 <Kevin_Kofler> jreznik: +1
14:29:14 <Kevin_Kofler> And so far we didn't have any breakage which would warrant stricter scrutiny for our packages.
14:30:18 <jreznik> I agree with Kevin (and his open letter) - this is SIG task...
14:30:34 <than> +1
14:30:50 <jreznik> let's prepare two variants - one is empty list - and try to convice FESCo to lighter policy
14:31:31 <rdieter_work> here (late, sorry)
14:31:56 <jreznik> another is as much lightweight list - so kdelibs and kdebase-workspace (but that mean lot of deps - should be out of scope, so only these TWO packages)
14:32:01 <Kevin_Kofler> rdieter: So we're currently discussing the critical package list for KDE which FESCo has asked us for.
14:32:31 <Kevin_Kofler> IMHO we should just turn up with the empty list.
14:32:39 <rdieter> ie, packages to be considered critpath ?
14:32:41 <than> jreznik: it's stupid to add the deps to the list
14:32:44 <ltinkl> qt, kdelibs, kdebase*
14:32:54 <ltinkl> are imho the most important
14:32:54 <Kevin_Kofler> than: But that's how they work.
14:33:21 <jreznik> than: yes
14:33:22 <rdieter> could start out small, say just qt/kdelibs
14:33:27 <Kevin_Kofler> And in some ways it makes sense, if a lib has unresolved symbols, the dependent packages won't work.
14:33:42 <Kevin_Kofler> A lib bug can also make everything crash.
14:34:07 <jreznik> question is - what is critical
14:34:10 <rdieter> and consider adding kdebase-workspace, when/if we can split it a bit to avoid pulling in more than want we minimally want.
14:34:27 <jreznik> does this mean - working desktop (so kdebase-workspace) or just qt/kde apps?
14:34:29 <Kevin_Kofler> For workspace, I guess kdm and its deps could work.
14:34:43 <Kevin_Kofler> It's critical, it'd protect the kdebase-workspace SRPM, but not qedje, eet and stuff like that.
14:35:12 <rdieter> kdm is good, kpackagekit should be considered
14:35:34 <Kevin_Kofler> But this all assumes we want to have a nonempty critpath at all. :-)
14:36:10 <Kevin_Kofler> I don't see how we'd need critpath protection for our stuff. It doesn't work anyway as the recent HAL splitting fiasco has shown.
14:36:34 <rdieter> provided we have enough proventesters, are there any other downsides to critpath?
14:36:44 <rdieter> (talking mostly to Kevin_Kofler here)
14:36:47 <SMParrish> I would rather us provide them with a suitable list, than have one provided to us. That is the risk we take if we send them an empty list
14:37:05 <Kevin_Kofler> AIUI, they want to require 1 proventester + 1 regular tester for critpath packages.
14:37:15 <rdieter> ok, I think we can handle that.
14:37:17 <Kevin_Kofler> (or 2 proventesters, of course)
14:37:19 <Kevin_Kofler> Not just 1 proventester.
14:37:46 <jreznik> ok, so let's have two our provetesters under KDE SIG umbrella and it's ok to have everything in critical path
14:38:00 <jreznik> any volunteer?
14:38:00 <Kevin_Kofler> Well, is everything really critical?
14:38:07 <Kevin_Kofler> I wouldn't call kdesdk critpath.
14:38:19 <jreznik> Kevin_Kofler: no, it isn't ;-)
14:38:24 <Kevin_Kofler> Of course Kompare is so important everyone absolutely needs it working. ^^
14:38:51 <Kevin_Kofler> More seriously, I think Kate might be considered critical by some folks. But I don't think it qualifies for critpath.
14:38:52 <rdieter> I'd propose:  qt (implicit), kdelibs, kdm as our initial list
14:39:02 <jreznik> rdieter: +1
14:39:05 * thomasj waves late
14:39:20 <Kevin_Kofler> I'd propose: as our initial list. ^^
14:39:28 <rdieter> I'm omitting kpackagekit, since I'm still not convinced we could get timely fixes when/if any problems are identified anyway
14:39:30 <jreznik> I'm not sure critpath should be strongly package wise based
14:39:32 <SMParrish> I'd agree with rdieter's list +1
14:39:50 <jreznik> for desktop it should be more - basic testcase for whole env. should pass
14:40:11 <rdieter> and we can work to split out stuff from kdebase-workspace that we don't consider critical
14:40:33 <rdieter> but atm, the umbrella kdebase-workspace pulls in a bit much, imo.
14:41:26 <Kevin_Kofler> jreznik: I think the whole critpath process is just broken.
14:41:53 <rdieter> Kevin_Kofler: we know how you feel. :)
14:42:26 <Kevin_Kofler> So now we have 3 votes for rdieter's proposal, 1 for the empty list.
14:42:54 <Kevin_Kofler> ltinkl? than?
14:43:18 <jreznik> Kevin_Kofler: I don't like package based critpath but I understand that we need some more assurance we do not ship shit
14:43:21 <ltinkl> +1 for rdieter proposal
14:43:28 <Kevin_Kofler> OK, so it passes.
14:43:32 <Kevin_Kofler> Move on please.
14:44:10 <jreznik> #agreed critical path components are qt (implicit), kdelibs, kdm
14:44:26 <jreznik> #topic Bug Triage method (rough draft)
14:44:42 <jreznik> #link https://fedoraproject.org/wiki/SIGs/KDE/Bugz
14:46:04 <Kevin_Kofler> This is just codifying existing practice, isn't it?
14:46:12 <SMParrish> This draft is my method of triage and as I found out its very similar to what the KDE folks do as well.  In fact the flow chart came from them
14:46:37 <Kevin_Kofler> "(distribution or plugin)" would need to be replaced for us.
14:46:51 <SMParrish> Kevin_Kofler: yes it is.  people wanted it in print
14:47:15 <rdieter> not sure if it's worth documenting exceptions, but for "important" and reproducible items, the kde sig take take over the job of pushing certain bugs upstream.
14:47:20 <jreznik> one question is if we can/should change upstreaming policy
14:47:22 <Kevin_Kofler> In our case it'd be "(upstream)".
14:47:24 <Kevin_Kofler> Otherwise this looks OK.
14:47:27 <rdieter> s/take take/can take/
14:48:01 <SMParrish> I'll clean it up and change the wording on the flow chart this week
14:48:04 <jreznik> rdieter: +1 (but again - it's practically current existing practice for important issues)
14:48:22 <rdieter> ok, then rubber stamp a-ok from me too, +1
14:48:50 <Kevin_Kofler> +1 to this policy, looks sane.
14:49:01 <ltinkl> +1 from me too
14:50:36 <thomasj> very nice chart
14:50:37 <jreznik> +1 (with rdieter's proposed extension)
14:52:06 <jreznik> ok we have 4 votes
14:52:51 <jreznik> #agreed on bugreporting policy
14:53:01 <jreznik> anything else to the topic?
14:54:29 <jreznik> #topic open discussion
14:54:57 <Kevin_Kofler> rdieter:
14:54:58 <Kevin_Kofler> <Sho_> there's also a few packages where f12 is newer than f13 right now
14:54:58 <Kevin_Kofler> <Sho_> arora and cmake ..
14:54:58 <Kevin_Kofler> <Kevin_Kofler> (in kde-redhat)
14:54:58 <Kevin_Kofler> <Kevin_Kofler> (not in official repos)
14:54:58 <Kevin_Kofler> <Sho_> yep
14:55:08 <Sho_> yeah rdieter knows
14:55:21 <SMParrish> Saw an email this am that koffice needs to be rebuilt for rawhide
14:55:34 <rdieter> I'm a little surprised about cmake, we can/should do an update to get that up to 2.8.1
14:55:47 <rdieter> arora was just a qt47 rebuild (I think)
14:56:24 <rdieter> SMParrish: yeah, an abi-breaking poppler landed in rawhide
14:58:04 <rdieter> who's doing the kde-4.4.3 rebuilds ?
14:58:11 <rdieter> (sorry, I missed that part)
14:58:52 <Kevin_Kofler> rdieter: ltinkl is taking care of it.
14:59:08 <rdieter> ltinkl: remember devel/rawhide too
14:59:21 <ltinkl> um, I was told not to
14:59:57 <jreznik> ok, time is out, let's move back to #fedora-kde
15:00:10 <Kevin_Kofler> rdieter: devel was built properly.
15:00:31 <Kevin_Kofler> We're doing the "append .1 and rebuild" trick.
15:00:31 <rdieter> ltinkl: ok, it's just for upgrade paths, bumping cvs only is probably ok at this point then
15:00:32 <rdieter> ah, nvm. :)
15:00:34 <rdieter> good.
15:00:56 <jreznik> #endmeeting