16:04:36 #startmeeting FPC 16:04:36 Meeting started Thu Jul 3 16:04:36 2014 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:04:36 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:04:40 #meetingname FPC 16:04:40 The meeting name has been set to 'fpc' 16:04:44 #topic Roll Call 16:04:47 #chair geppetto 16:04:47 Current chairs: abadger1999 geppetto 16:04:57 * racor is here 16:05:03 #chair racor 16:05:03 Current chairs: abadger1999 geppetto racor 16:05:27 Rathann, spot, SmootherFrOgZ, tibbs: FPC ping 16:06:21 * Rathann here 16:06:35 #chair Rathann 16:06:35 Current chairs: Rathann abadger1999 geppetto racor 16:09:07 Remi is definitely out this week and spot said that July through flock would be his busiest month before his schedule started going back to normal. 16:09:36 Looking like no quorum today. 16:09:45 But 4 is enough to have some discussion and vote on tickets. 16:10:10 yeh, tibbs usually pops in a bit too … might just be doing something for a few. 16:11:08 #topic #339 software collections in Fedora 16:11:08 abadger1999: forgot to forward to you, but someone emailed me to ask if we could look at 317 again. 16:11:15 langdon: You around? 16:11:37 abadger1999: yeah.. but i am not sure we have anything for you .. im sorry to say 16:11:40 remi's on vacation so we weren't able to continue our talk about the email he sent about scldevel. 16:11:41 langdon: okay. 16:12:02 langdon: Should I continue to hold up things waiting on you or just forge ahead? 16:12:05 i think this is a bad week here (in the US) too 16:12:12 Very true. 16:12:16 sorry? 16:12:29 like "table for today"? 16:12:36 or do you mean something else? 16:12:48 langdon: yeh, table until next week 16:13:08 geppetto: abadger1999 yeah, let's table it.. 16:13:27 I was thinking we were waiting to approve or disapprove the ruby scl naming for getting a counter proposal on naming. 16:14:07 but if the counter proposal isn't forthcoming... maybe we should vote to approve or not and then address any name change in an update. 16:14:23 #chair tibbs|w 16:14:23 Current chairs: Rathann abadger1999 geppetto racor tibbs|w 16:14:32 Hey tibbs. 16:14:41 Howdy. Sorry, sometimes Thursday doesn't work out all that well for me. 16:15:11 i think current status on naming is that there are arguments against "any name changes" ... but no arguments on "alternate name changes". So, I am not sure of the preference of the FPC.. 16:15:24 Yeah. Maybe we should think about looking for a new time again... but I guess after August when spot gets back is a better time to think about it. 16:15:35 langdon: k 16:16:01 so, if the FPC "believes" the name change is the "right answer" then it should proceed. I don't have a counter on the "type" of change. 16:16:56 langdon: alright, I guess we'll try to move ahead with voting on the current names that we proposed then. 16:17:05 So one thing that came up this week in releng and fesco tickets 16:17:34 was that the SCL team wanted to continue to put scl macros into packages for now because the guidelines say they can. 16:17:44 and then keep them in there later under grandfathering. 16:18:17 So I guess we need to take a vote on that now since we want them to be strictly separate. 16:18:30 wtf is grandfathering? 16:18:31 and allowing that to go on for now and then changing it later will mean more work. 16:18:50 geppetto: Allowing hte old behaviour to continue after the guidelines are updated. 16:18:52 geppetto: american euphemism for "new laws don't apply to old things" 16:18:56 yeh, so -1, -1, -1, -1 16:19:24 abadger1999: Yeh, but we've never allowed that apart from maybe a short conversion period 16:19:26 Really -- our usual definition of grandfathering, though, is that we don't require the packager to update (although it would be nice) but they must take patches to fix that. 16:19:29 abadger1999: Have we? 16:19:45 geppetto: Some things are longer term like package naming. 16:20:13 geppetto: When we update package naming we usually use grandfathering to mean, as long as the package is active, you can continue to use the old name. 16:20:31 fair enough 16:21:02 But yeah -- really in most cases we'd ideally want a conversion period but we lack manpower and enforcement to actually achieve that. 16:21:16 anyhow.. 16:21:21 https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change 16:22:07 Hmm.. 16:22:11 * abadger1999 realizes something 16:22:39 My terminology in that draft also expects that SCLs will be placed in a separate package rather than a separate branch of an existing repo. 16:22:56 yes 16:23:10 Does FPC want to vote on making that our official recommendation at this time as well? 16:23:26 * Rathann is +1 to both proposals 16:23:28 I was on the fence before but over the past few days I've come to think that's the right thing to do. 16:23:52 Proposal: SCL packages must be separate packages, not separate branches in the git repos 16:23:55 +1 16:24:22 +1 16:25:17 +1 16:25:33 IF we want to talk about this more that's fine too... I can update the other proposal to specify either package or branch of pacakge. 16:25:47 +1 though this almost seems a releng issue. 16:26:13 dgilmore said that he'd implement it according to FPC recommendations. 16:26:40 tibbs: You won't think that the first time you have to alter a normal package that's been sclized in the main branch ;) 16:26:42 If he has reservations later, I'll bring his concerns back here. 16:26:54 0, I have been absent too many times in recent weeks to be able to follow. 16:27:43 #info Proposal: SCL packages must be separate packages, not separate branches in the git repos (+1: 4, 0:1, -1:0) Seeking more votes in ticket 16:28:33 Proposal: Approve: https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change which makes for strict separation between mainstream and SCLized packages 16:28:34 +1 16:29:18 +1 16:30:48 geppetto, tibbs|w, racor: votes? 16:31:08 +1 16:33:51 Okay, well, we'll probably need to vote in the ticket anyhow so geppetto and racor can vote there. 16:34:13 #info https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change which makes for strict separation between mainstream and SCLized packages (+1:3, 0:0, -1:0) Seeking more votes in ticket 16:34:14 I am confused. What are we voiting on? https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change was what I just voted on. 16:34:14 abadger1999: I'm confused … how is this different? 16:34:22 #undo 16:34:22 Removing item from minutes: INFO by abadger1999 at 16:34:13 : https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change which makes for strict separation between mainstream and SCLized packages (+1:3, 0:0, -1:0) Seeking more votes in ticket 16:34:55 racor, geppettoSorry -- the prior vote was about whether SCL-ized packages could be done in separate branches or had to be separate git repos. 16:35:40 Ok, I'm +1 on the latest one. 16:35:49 Cool. 16:35:53 The previous one was +1 == allowed to use a branch? 16:36:25 geppetto: the previous one was +1 *not* allowed to use a branch 16:36:34 ok 16:36:58 Wsa your vote there okay? 16:37:15 racor: The same question for you. 16:37:24 Yeh, I'm still +1, but for anyone reading the logs later … I could probably be convinced to relax that given a reason. 16:38:01 Yes, I am on 0 in the first vote. Still trying to understand the 2nd one. 16:38:10 k 16:38:26 The second one was where the rest of us voted on https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change 16:38:37 racor: the latest one is basically … you can't put scl macros into a non-scl package. 16:39:27 Thanks for the explanations, +1 16:39:29 The first one was bordering with a releng issue: in implementing SCLs, should SCLs be put into separate branches of an existing package or into a separate git repo than the existing package. 16:39:58 racor: okay, so you're 0 for the first one and +1 for the second, correct? 16:40:18 abadger1999: yes. 16:40:40 #info https://fedoraproject.org/wiki/User:Toshio/SCL_Macros_Change which makes for strict separation between mainstream and SCLized packages (+1:5, 0:0, -1:0) 16:41:26 #topic #382 Go Packaging Guidelines Draft 16:41:32 Needs input from vabatts 16:41:44 mattdm said he'd poke him again for us. 16:41:55 #topic #414 Please consider requiring AppData for all desktop 16:42:05 Need input from spot and from rhughes. 16:43:03 There seems to be a desire from the desktop team to use MUST instead of SHOULD... mattdm is getting more information for us about reasons for that or anything else that might help us make a decision. 16:43:14 #topic #419 ruby193 in SCL 16:43:19 https://fedorahosted.org/fpc/ticket/419 16:44:11 So the update from langdon earlier is that we don't need to block on the naming questions. 16:44:44 But there's still the issues in https://fedorahosted.org/fpc/ticket/419#comment:3 16:45:11 I added one compat question to the page itself after last week's meeting as well. 16:45:38 #topic #435 %py3dir not removed by rpmbuild --clean 16:45:51 No movement in bz and that's where this needs to come from :-( 16:45:56 #topic #439 update for Packaging:Tmpfiles.d 16:46:01 https://fedorahosted.org/fpc/ticket/439 16:46:27 I dropped the ball on this. I was supposed to rewrite the draft to take care of the issues we identified last meeting. 16:46:38 no problem 16:46:40 I'll do that tomorrow before the kids get up for the festivities. 16:46:47 #topic #440 mimeinfo scriptlet update 16:46:51 https://fedorahosted.org/fpc/ticket/440 16:48:18 I voted +1 in ticket. It's just a scriptlet for running update-mime-database so that it doesn't have such a big performance hit. 16:48:49 According to comment:4 we should be able to use it on all Fedora versions (not in EPEL yet). 16:49:02 looking at the history … this is just adding -n to the command, right? 16:49:11 if so +1 16:49:20 It will only improve performance in rawhide. On older releases -n is a forward compat no-op 16:49:24 +1 16:49:41 +1 16:50:16 racor, Rathann: votes for the mimeinfo scriptlet update? 16:50:22 Though the split with epel is a pain in this case. If someone insists on keeping the same spec, the conditionals will get nasty. 16:50:58 hm I'm a bit confused about fesco decision 16:51:15 I'm confused about all of that, too, but I think it's a separate issue. 16:51:37 yeh, I wasn't sure what that was saying … but it didn't seem like I needed to 16:51:39 Basically, there's a new -n option that makes things faster. Update guidelines to use it. 16:51:46 Rathann: The fesco decision was that we wouldn't force the package maintainer to push the version of the update-mime-info package that makes -n actually improve performance back to F20 and F19. 16:51:47 yeh 16:52:01 abadger1999: ahh, cool. thanks. 16:52:09 So F19 and F20 just has a version where -n is a no-op for compat 16:52:19 ok then, +1 16:52:44 racor: if you vote on this one we can close it. 16:52:47 :-) 16:54:40 #info mimeinfo scriptlet update (+1:4, 0:0, -1:0) Will seek additional vote in ticket 16:54:59 #topic Bundled Library exception request for Gazebo 16:55:04 https://fedorahosted.org/fpc/ticket/317 16:55:17 We were asked to look at this in the mailing list 16:55:22 abadger1999: Sorry, was distracted on the phone ... trying to catch up ... 16:55:29 k 16:55:32 No worries 16:56:43 seems fine to me 16:56:56 The description of this ticket sounds fine to me. 16:57:12 Yes, seems OK. 16:58:04 * abadger1999 starts off voting 16:58:06 +1 16:58:08 +1 16:58:24 subpackaging is sufficient to consider this a fork rather than bundling 16:58:39 my vote on #440: +1 17:00:28 Rathann, geppetto: votes on #317 now being acceptable (fork, not bundling)? 17:00:42 yeh, +1 17:00:49 racor: and you too but I know you're catching up :-) 17:02:17 my vote on #317 subpackaging seems fine to me ... +1 17:02:31 #info Approve 317 as forking rather than bundling: (+1:4, 0:0, -1:0) Will seek more votes in ticket 17:02:44 #topic #440 mimeinfo scriptlet update 17:02:50 #info EDIT: mimeinfo scriptlet update PASSED (+1:5, 0:0, -1:0) 17:02:54 #topic Open Floor 17:03:03 Okay, anything else people want to discuss today? 17:04:04 +1 on #317 17:04:28 #info EDIT: Approve 317 as forking rather than bundling: APPROVED (+1:5, 0:0, -1:0) 17:04:45 Alrighty, if nothing else, I'll close in 60s 17:05:01 Hooray. 17:05:32 :-) barely went into the second hour this week ! 17:05:47 #endmeeting