18:00:35 #startmeeting FESCO (2015-11-11) 18:00:35 Meeting started Wed Nov 11 18:00:35 2015 UTC. The chair is ajax. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:35 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:35 #meetingname fesco 18:00:35 The meeting name has been set to 'fesco' 18:00:35 #chair ajax dgilmore hguemar jwb nirik paragan rishi thozza sgallagh 18:00:35 Current chairs: ajax dgilmore hguemar jwb nirik paragan rishi sgallagh thozza 18:00:36 #topic init process 18:00:41 .hello rishi 18:00:42 rishi: rishi 'Debarshi Ray' 18:00:44 .hello kevin 18:00:45 nirik: kevin 'Kevin Fenzi' 18:00:46 .hello hguemar 18:00:48 .hellomynameis kushal 18:00:48 number80: hguemar 'Haïkel Guémar' 18:00:52 kushal: kushal 'Kushal Das' 18:00:56 hi 18:00:59 .hello thozza 18:01:01 thozza: thozza 'Tomas Hozza' 18:01:04 .hello jkurik 18:01:04 jkurik: jkurik 'Jan Kurik' 18:01:22 ajax: you need to chair my irc nick, meetbot doesn't map irc nick/fas 18:01:34 tsk, i do 18:01:58 * ajax edits meeting template page 18:02:13 right, i think that's quorum. apologies for the tz confusion last week. 18:02:25 #topic #1278 establish Fedora Bat-Signal for ultra-critical security updates 18:02:29 .fesco 1278 18:02:30 ajax: #1278 (establish Fedora Bat-Signal for ultra-critical security updates) – FESCo - https://fedorahosted.org/fesco/ticket/1278 18:02:31 https://fedorahosted.org/fesco/ticket/1278 18:02:51 is there really anything further to do here other than "yes, let's do this"? 18:02:57 per comment #14 we're waiting for mattdm ? 18:03:02 * nirik nods 18:03:12 yup 18:03:16 that guy is a slacker 18:03:41 lets remove meeting keyword until it has something to discuss? 18:03:48 wfm 18:03:49 *nods* 18:04:24 #info Removed from meeting agenda until ticket is updated 18:04:32 i'll do that 18:04:48 #topic #1491 clarifications/improvements for new bundling policy 18:04:48 .fesco 1491 18:04:48 https://fedorahosted.org/fesco/ticket/1491 18:04:50 ajax: #1491 (clarifications/improvements for new bundling policy) – FESCo - https://fedorahosted.org/fesco/ticket/1491 18:05:09 so, I made a wiki page for the policy we approved. 18:05:25 should we go thru each of the proposed improment/clarifications or? 18:05:56 it's short enough, i think 18:06:13 +1 for me 18:06:17 yes +1 18:06:18 does anyone have any issues with the wordingn in that policy page? 18:06:31 * rishi reads 18:06:51 well, the proposed changes have had some discussion. I didn't put any of them on the page yet. 18:07:23 ajax: The Wiki page looks good to me. 18:07:59 nirik: did that discussion have any suggestions for amendment, or...? 18:08:09 yes. shall I go thru them one at a time? 18:08:10 honestly, the most important is there 18:08:23 well, I think the wiki page as is is too vuage... 18:08:38 thus asking for some clarifcations. 18:08:57 sure, i'm just trying to work throught the wall of text in the ticket 18:09:15 1. Is there a time limit you should wait to hear from upstream? some people in ticket said "up to maintainer" 18:09:36 which could lead to "I sent it friday afternoon, havent heard anything monday so lets go!" 18:09:51 up to reasonable delay 18:10:05 sure, upstream may be completely gone, not responsive. 18:10:15 yeah, i'd think matter of taste 18:10:28 a week? 18:10:43 sure, that's a fine number 18:10:51 wfm 18:11:09 What if it's a one person project and that person is on vacation. 18:11:20 Trying to encode these things in a policy is tricky. 18:11:22 yeah, there's lots of edge cases for sure. 18:12:09 i think it's not worth codifying it. 18:12:14 I would trust the packager and leave it at that, but I am not too hung up on this. 18:12:27 ok. 18:12:30 since we require people to contact publicly upstream, if there's a public answer, we can always unbundle afterwards 18:13:04 * nirik looks thru the rest to see if any might have support enough to pass. ;) 18:13:05 Seeing how people do the unresponsive maintainer recently I think they will not wait the time even if it is exactly stated 18:13:36 it must be a reasonable time 18:13:59 To be honest I don't get it why sgallagh pushed for the change to be approved so much, when now we are still not done with it and have to clarify things. But given it has been approved I'm OK with the wiki as is. 18:14:26 proposal: add that "the list of bundled provides is maintained by the FPC. They should handle disputes or adjustments to bundled names" 18:14:42 nirik: Fine with me. 18:14:44 +1 18:14:52 thozza: this topic is den of snakes, we just managed to have an agreement which didn't happen for years on that topic, that's my theory 18:14:57 (assuming they are willing to do this. I can ask) 18:15:10 nirik: +1 18:15:16 nirik: according our last exchanges, they were 18:15:17 * nirik is +1 for his own proposal 18:15:25 +1 (again) 18:15:47 number80: It seemed to me that it came out of nowhere. Just my perception of it 18:15:57 +1 18:16:11 #approved FPC to manage bundled names list (+6 -0) 18:16:19 * nirik can add that. 18:16:29 do we have any control mechanism to make sure people don't bundle quietly? 18:16:29 thozza: at least, I'm glad that topic *died* 18:16:29 * ajax hopes he got the # right 18:16:36 e.g. announce the bundling somewhere? 18:16:51 thozza: it's supposed to be documented in the spec file 18:17:08 The only other big thing I see is the topic toward the end about bundled libs interacting with other things. 18:17:17 jwb: so how often do you check SPEC files for packages in Fedora? :) 18:17:23 thozza: we don't currenlty, but we could if people wanted to 18:17:50 I don't know if there's a proposal to tease out of that... 18:17:57 I mean something that people could just ignore most of the time, but if there is something suspicious we can at least catch it 18:18:02 thozza: frequently for things i care about. but people that are going to bundle quietly are going to bundle quietly regardless of whether or not they are supposed to send an email. 18:18:17 jwb: true 18:18:32 i'm not sure the bit not exposing provides for things in %{_libdir}/%{name} is right 18:19:01 if you also install a file in /etc/ld.so.conf.d that can work fine 18:19:11 I think it could be automated to generate a diff of which packages started to bundle every period of time 18:19:24 thozza: we have shummershum now, we would need work on top of it to figure out what source files are the same accross packages and how to report that and handle approved stuff, etc. 18:19:30 not sure if it is worth it 18:19:37 and there's like 14 files there on my machine as it is 18:19:40 thozza: it is 18:20:03 but, i do agree that bundled libs' sonames should be filtered out from the provides list 18:20:23 yeah. 18:21:01 yes 18:21:25 number80: I meant the script I mentioned.... just for clarification :) 18:21:37 ok 18:21:38 OK, my proposal there was mostly just to get the conversation started. I was pretty sure it wasn't a complete solution. 18:21:53 (Sorry, I'm on PTO today because my kids have no school; just got to my computer) 18:22:12 okay, we're at 15 minutes on this 18:22:19 perhaps that could be discussed on list... 18:22:25 and then something hashed out there? 18:22:46 nirik: "that"? 18:22:51 or just some more thought on it. 18:22:54 nirik: I think we could probably just go with "FESCo wants bundled libs to not be automatically listed" and let the RPM/FPC figure out the details 18:23:01 the bundled libraries providing things they shouldn't 18:23:09 *RPM/FPC folks 18:23:18 ah, yeah. there's a packaging doc for how to do that already i thought 18:23:47 ajax: For filtering out specific things, yes. 18:23:52 sure, although in many bundling cases it's not going to be needed. 18:23:59 If we wanted to try for a better auto-detection, that's Work. 18:24:07 (copylibs, things used at buildtime instead of runtime, etc) 18:24:15 nah, that's easy i bet. 18:24:48 every soname-looking Provides string with arity > 1 in the repository 18:25:29 arity? 18:25:32 count. 18:25:41 provided by more than one package 18:25:52 ajax: I meant build-time detection 18:26:04 But yeah, maybe it's sufficient to detect it after-the-fact and file bugs 18:27:17 proposal: bundled libs must be appropriately filtered from rpm Provides as documented in https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering 18:27:29 sure, +1 18:27:42 +1 to my own 18:27:50 +1 18:28:02 +1 18:28:07 ajax: +1 18:28:08 +1 18:28:29 #approved bundled libs must be appropriately filtered from rpm Provides as documented in https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering (+6 -0) 18:28:39 any other proposals about this?' 18:29:04 well, it might be nice to define system library, but I guess that could be difficult. 18:29:28 oh, you know one when you see one. 18:29:59 I don't see anything else that likely would pass.... unless it's fonts, but that seems a mixed bag as well. 18:30:22 so, I guess I am ok to close the ticket 18:30:50 cool. we can nail those two down as separate tickets should the issue become pressing 18:31:07 /me nods 18:31:14 sure. if others think of clarifications they can make some new proposals. 18:31:31 #topic 1478 F24 Self Contained Changes 18:31:31 .fesco 1478 18:31:32 https://fedorahosted.org/fesco/ticket/1478 18:31:33 ajax: #1478 (F24 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1478 18:32:01 we have a new change: Product Definition Center 18:32:09 Is this really Self-Contained? 18:32:12 +1 here. 18:32:23 it affects only the way 18:32:36 I'm all for it, but it's unclear if it's going to require involvement from the WGs (for example) 18:32:39 sgallagh: it's just more to tell people it exists... it's not using it for things yet 18:32:39 how relened is gathering information 18:32:45 ok 18:32:48 +1 in either case 18:33:06 +1 for the changes in the ticket except PDC (+0) 18:33:11 it shouldn't... unless WG's are making their own images, which would be bad. ;) 18:33:23 +1 18:33:33 Sure, +1 18:33:34 I'm not sure that the current implementation of PDC lives up to the expectations 18:33:40 +1 but i still don't think this was necessary as a Change 18:33:48 number80: how can it? it doesn't exist yet... 18:33:57 #approved Change is approved (+6 -0) 18:34:01 jwb: there's one somewhere 18:34:13 in staging, which isn't complete 18:34:18 maybe let's let them work on it. 18:34:38 #topic 1495 Significant amount of updates when a Fedora release is made GA 18:34:41 .fesco 1495 18:34:42 ajax: #1495 (Significant amount of updates when a Fedora release is made GA) – FESCo - https://fedorahosted.org/fesco/ticket/1495 18:34:44 https://fedorahosted.org/fesco/ticket/1495 18:35:08 I openned this one to get FESCo opinion on this 18:35:17 Proposal 1 sounds like a no-go to me. 18:35:37 I don't think there's anything here to change. 18:35:40 I still don't get what's the problem 18:36:06 I'm with nirik; it sounds like someone is trying to solve a non-problem with a worse solution :) 18:36:39 well, the issue they have is that we have this tested thing we release, then we dump tons and tons of 0 day updates on it (which aren't tested as much). 18:37:20 but it's the same old discussion about updates policy 18:37:21 that "tested" property is a function of how long it takes to validate it once it's frozen though, right 18:37:24 ? 18:37:42 yeah, but better solutions would be rings ... then it would be much easier to reduce 0day updates number 18:37:44 yeah. 18:37:47 so really the complaint is not "there's too much noticeable change here" 18:37:58 it's "validation is too slow" 18:38:10 maybe 18:38:11 because the change rate is going to be basically constant anyway 18:38:32 i think it's that, combined with "there is no consistent approach on how often to update and when to update" etc 18:38:33 right, but per list, there's unlikely to ever be a time we can redo everything and fully validate it in a short time. Too many manual things 18:38:59 More automated integration testing would be nice, but that's considerable work 18:39:12 though now that i've said that i wonder what the time-series graph looks like of commit rate over, say, a year 18:39:13 (Work that *is* being done, but no clear timeline) 18:39:24 The fact that we constantly have updates coming through a hose pipe is inded an issue. 18:39:38 There is no way that thing is every QAed or can be QAed. 18:39:41 *ever 18:39:48 https://bodhi.fedoraproject.org/releases/F23 18:40:07 I guess the best bet is to go for an immutable core plus atomic updates. 18:40:14 sounds that we agree that the problem to solve is not the one suggested in the ticket :) 18:40:15 Which people are already working on. 18:40:42 number80: indeed 18:40:47 number80: Ack 18:41:35 well, in the absence of concrete proposals here, we'll just say this is something to meditate on for now 18:41:45 /me nods 18:41:50 #topic 1496 OpenH264 solution.fesco 1496 18:41:50 .fesco 1496 18:41:51 https://fedorahosted.org/fesco/ticket/1496 18:41:52 ajax: #1496 (OpenH264 solution) – FESCo - https://fedorahosted.org/fesco/ticket/1496 18:42:09 so, this is anoying and messy, but thats legal stuff for you. ;( 18:42:41 happy to answer any questions about the proposed workflow. 18:43:04 Not that we can do any better ... 18:43:13 I question how useful this will be without also supporting audio codecs, but any improvement is worth something 18:43:36 yeah, this looks fine to me 18:43:38 * rishi is quite happy/intrigued to see that Cisco has agreed to hose the RPM for us 18:43:53 ajax: Looks good to me. 18:44:08 sgallagh: Yeah, won't be that useful without AAC, as far as I know. 18:44:20 *host 18:44:28 perfect is the enemy of good or something 18:44:35 i'm +1 for the ticket 18:44:44 Well, this could inspire other "folks" to provide us these codecs under the same agreement 18:44:48 +1 18:44:51 I'm +1 for the ticket as well 18:44:58 Yeah, +1 18:44:59 Any improvement, however marginal, is still an improvement 18:45:00 +1 18:45:08 +1 18:45:12 +1 here 18:45:34 #approved Proposal is approved 18:45:39 d'oh 18:45:44 #approved Proposal is approved (+7 -0) 18:45:48 great 18:46:04 #topic Next week's chair 18:46:25 (everyone takes one step backward) 18:46:31 * number80 travelling again next wednesday 18:46:41 :) 18:46:52 ajax: Ok, I'll do it. 18:46:57 rishi: thanks 18:47:02 #info rishi to chair next week 18:47:12 #topic Open Floor 18:47:54 will close in ~5 minutes if nobody has anything 18:52:02 #endmeeting