16:00:30 #startmeeting FESCO (2016-11-18) 16:00:30 Meeting started Fri Nov 18 16:00:30 2016 UTC. The chair is maxamillion. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:30 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:30 The meeting name has been set to 'fesco_(2016-11-18)' 16:00:41 #meetingname fesco 16:00:41 The meeting name has been set to 'fesco' 16:00:41 #chair maxamillion dgilmore jwb nirik paragan jsmith kalev sgallagh Rathann 16:00:41 Current chairs: Rathann dgilmore jsmith jwb kalev maxamillion nirik paragan sgallagh 16:00:44 #topic init process 16:00:46 hello 16:00:47 .hello maxamillion 16:00:48 maxamillion: maxamillion 'Adam Miller' 16:01:09 .hello pnemade 16:01:10 paragan: pnemade 'Parag Nemade' 16:01:16 morning 16:01:27 * threebean waves 16:01:34 .hello kalev 16:01:37 kalev: kalev 'Kalev Lember' 16:02:55 .hello sgallagh 16:02:56 sgallagh: sgallagh 'Stephen Gallagher' 16:03:13 hi 16:03:19 .hello rathann 16:03:20 Rathann: rathann 'Dominik Mierzejewski' 16:03:25 .hello jkaluza 16:03:26 jkaluza: jkaluza 'Jan Kaluža' 16:03:42 alright, let's get rolling 16:03:50 #topic #1635 F26 Self Contained Changes 16:03:55 .fesco 1635 16:03:57 maxamillion: Issue #1635: F26 Self Contained Changes - fesco - Pagure - https://fedorahosted.org/fesco/ticket/1635 16:04:00 .fesco 1635 16:04:02 ugh 16:04:02 maxamillion: Issue #1635: F26 Self Contained Changes - fesco - Pagure - https://fedorahosted.org/fesco/ticket/1635 16:04:09 https://pagure.io/fesco/issue/1635 16:04:24 * nirik is +1 to both 16:04:36 +1 from me as well 16:04:38 * maxamillion is +1 to both 16:05:03 +1 from me also to both 16:05:07 I think it's premature to vote, honestly. The conversation on the mailing list just kicked into gear. 16:05:29 (I'm heavily in favor of this Chanage, but I don't know if FESCo has all the information it needs for a decision yet) 16:05:33 *Change 16:06:14 i'm kind of concerned that the implication is the new modular build thing will replace what we have today 16:06:25 which is a very big, not self-contained change 16:06:26 jwb: That is *not* on the table for F26 16:06:30 * threebean nods 16:06:40 jwb: that's still a "magical future" thing 16:06:41 i understand that, but that doesn't lessen my concern 16:06:45 fair 16:07:04 replacing what we do today is the long-term intent, yes. 16:07:30 but the F26 Changes here are scoped to have little to no impact on the current state of things for F26 itself. 16:07:36 conservative. 16:08:22 jwb: the goal there being to get us all much more familiar with how this whole thing will work before we get too far in and can't turn back. 16:09:36 * jwb is thinking 16:09:52 * threebean nods 16:10:56 so to accomplish this familiarity, you're going to have to make changes to existing RPMs in fedora, yes? 16:11:08 * threebean defers to sgallagh on that question. 16:11:14 (but I think the answer is mostly "no") 16:11:22 but those changes are just fixing things right? 16:11:23 otherwise you won't be able to do your module compose (e.g. the 3000 rpm base runtime reduction, etc) 16:11:34 right. 16:11:55 and we have 0 process or policies in place for composing modules 16:11:57 * nirik was thinking the things that didn't even build since the 'remove perl from buildroot' and the like. 16:12:09 I those changes are just to make sure packages having all the BuildRequires or Requires 16:12:23 Sorry, phone rang. *reads up* 16:12:25 nirik: there will be fixes for sure. but there will also possibly be _changes_ 16:12:47 yeah to reduce deps? 16:12:47 like... moving documentation to a subpackage. or reduction in function in the base package to make it smaller 16:12:53 right 16:13:01 The changes we're focusing on will be for dependency reduction, yes. 16:13:10 but those things could/would be useful in the non module world too no? 16:13:16 so the changes in the ticket are all about the infrastructure to do these builds. that's fine i guess 16:13:40 nirik: Some of them would, others wouldn't necessarily. 16:13:42 but the changes required to actually make that infrastructure useful are a different thing 16:13:50 sgallagh: right 16:13:58 i feel like we're putting the cart before the horse a bit here 16:14:06 For example, we're working on guidelines (proposed to FPC) for how to skip running %check and thereby ignore %check-only dependencies 16:14:22 heh, it's chicken-and-egg problems all the way down. 16:15:01 yaks, it's yaks all the way down 16:15:21 jwb: you're right about the tickets only talking about infrastructure pieces. that was intentional. 16:15:26 But the guidelines we're working on should be additive (in the sense that the goal is for module-specific changes to have zero impact on the results if you ran the same spec through the current infra) 16:16:03 If we need non-standard packaging changes, would that require a separate Change proposal? 16:16:10 (or is that process overkill?) 16:16:23 my basic concern is that we're going to have the infrastructure and it'll be a bit of wild-west in packaging land using it 16:16:31 threebean: I'll be filing a separate Change for that once the guidelines are accepted 16:16:35 somewhat like jurrasic park 16:16:53 we have the technology, but we have no guidelines on what is and isn't acceptable for using it 16:16:54 sgallagh: good to know. 16:16:56 /me looks for his Tyrannosaur saddle 16:17:07 I noticed that the ModularCompose change speaks about a non-existent product (CrazyServer) 16:17:16 jwb: so ... Docker? 16:18:07 maxamillion: maybe? 16:18:13 Rathann: Ignore that name... but the idea is that Fedora Server will also be attempting to produce an alternative compose from modules. This will be non-blocking and unadvertised. 16:18:27 right 16:18:35 jwb: I basically just meant that "we have the tech but no real guidelines" sounds a lot like the docker ecosystem 16:18:51 We do *not* intend it to be used by end-users in F26. There's a goal for F27 to have such a thing as a real deliverable, thoguh 16:18:53 maxamillion: ok, then yes. except this also has more impact on non-Docker things 16:18:59 jwb: right 16:20:32 So, the meat of this Change Proposal is that we want to set up a parallel build infrastructure and do it in such a way as to have little-to-no functional impact on existing build infrastructure 16:20:40 threebean: ^^ accurate? 16:20:44 yes. 16:21:16 threebean: where is the description of the Module Build Service? 16:21:19 note that the Change includes writing patches for pungi which, if we do that poorly, could break pungi and therefore break the release. but.. we won't do that. 16:21:31 Rathann: https://fedoraproject.org/wiki/Changes/ModuleBuildService 16:21:31 I guess my follow up question is, is this really a Change yet? .... sounds like a dev project that will potentially become a change in the future 16:21:59 I'm +1 either way, just not sure we need to require it go through the Change process 16:22:37 ah, so it's basically koji+some stuff on top of it? 16:22:46 Rathann: yup. 16:22:54 maxamillion: Well, the goal is that by F26 release, it should be possible for anyone to submit jobs to it 16:23:02 So I'd say that's a user-visible Change 16:23:19 fwiw, there's a minor dist-git changes to allow storing modulemd.yaml files in a new modules/ namespace there. and a patch to fedpkg to allow 'fedpkg module-build' from those directories. 16:23:41 sgallagh: fair 16:24:02 sgallagh: but you literally just said sgallagh> We do *not* intend it to be used by end-users in F26 16:24:17 jwb: Different conversation 16:24:23 uh... no 16:24:25 I was talking about the Modular Server artifact. 16:24:25 how? 16:24:32 I've been reading about this over the last few days and I'm generally in favour 16:24:42 ok, well my concern is with the build service 16:24:51 jwb: Right, the build service should be usable in F26 16:25:09 and if the goal is to have end users be able to use it by f26, and we have no policy or process in place, then none of my concerns are being addressed here 16:25:44 the Change states explicitly that it will not be usable by the general packager group in the F26 timeframe. that instead, we will lock it down to only members of the Modularity WG. 16:25:51 jwb: So are you asking for that to be explicitly written into the Change Proposal? 16:25:58 the point of that is to stop people from putting in module definitions *before* we have policy. 16:26:04 sgallagh: define "that" 16:26:05 (That policies for how modules are to be specified and built must exist)? 16:26:31 threebean: yes, but that isn't what sgallagh is saying 16:26:35 which is all very confusing 16:26:37 jwb: I'm wrong :) 16:26:51 i don't think you're wrong. i think you're highlighting exactly my concerns 16:26:51 :) 16:27:17 look, people climb mountains because they are there. once this exists, people will want to use it 16:27:30 * threebean nods 16:27:46 jwb: True, but to do so I guess they'd have to join the Modularity WG 16:28:01 (Or perhaps WG->SIG would be more accurate) 16:28:10 sgallagh: may work out well for increasing your membership 16:28:19 * threebean did not consider this angle. 16:28:19 Indeed 16:28:37 back to my point though, yes i would feel much more comfortable if we said policies for how modules are specific and built must exist 16:28:46 er, s/specific/specified 16:29:17 i think the infra and policies can be done in parallel, but the goal should be to have both done by the end of f26 16:29:22 I understand. do you understand my counter-point? that we want to use the experience of building the base set of modules first in order to figure out a good policy? 16:29:39 i do. and in a limited access setup, that will work 16:30:00 how you create and maintain that limited access is the question, but it's something you need to solve :) 16:30:08 * threebean nods 16:30:13 ack 16:30:57 .members modularity-wg 16:30:58 threebean: Members of modularity-wg: asamalik blc cpacheco eslobodo geppetto james +jkaluza jstanek jwboyer karsten @langdon lkocman mclarke merlinm mganisin mikedep333 modularity mprahl +nphilipp pavlix phracek psabata @ralph rwilliam sct sgilson ttomecek ttorling whitney yselkowitz 16:31:14 i'm hesitantly +1 if we all agree the policies need to be defined before the restrictions are removed for usage 16:31:16 hi threebean ! 16:31:25 that would be the current set. we don't have restrictions on who can join at the moment. 16:31:28 OK, so shall we (FESCo) ask that threebean amends the Change Proposal to include a requirement that policies must be in place (or at least under review by FPC) by Final Freeze? 16:31:56 please? 16:31:58 +1 16:32:07 oh, wait. 16:32:09 no, -1 16:32:13 hmm? 16:32:30 Can we make the amendment: policies must be in place before the restrictions are lifted. 16:32:46 I'd be fine with that. 16:32:47 i'm ok with that version 16:32:48 which just gives me wiggle room, possibly after F26 GA. 16:33:22 sure, sounds good to me too 16:33:31 * nirik is fine with that 16:33:32 such policies I would want either FPC or FESCo to approve before being considered official. 16:34:19 threebean: I think that's firmly in the FPC wheelhouse. 16:34:28 * threebean nods 16:34:30 But they can opt to kick it up to us, of course 16:34:48 they might. afaik, they deferred on container guidelines 16:35:09 this is... different enough from RPMs that they might not view it as their responsibility 16:35:13 indeed 16:36:34 I'm pretty sure the P stands for "packaging". 16:36:55 Fedora Policy Committee? :) 16:36:57 If we switched to .deb packaging, would it not still be the FPC's job? 16:37:00 containers ARE packaging 16:37:11 anyway, this is getting into the weeds 16:37:13 yes. 16:37:14 indeed 16:37:19 alright 16:37:21 (and I need to disappear in 10) 16:38:13 do we have a proposal to vote on? 16:38:58 proposal: Modularity changes are approved provided that they are amended to say that policies must be in place before the restrictions are lifted. 16:39:08 /me was just writing the same thing. 16:39:09 * threebean nods 16:39:10 +1 16:39:28 +1 16:39:29 +1 16:39:48 +1 16:39:53 +1 16:39:58 +1 16:40:26 thanks for bearing with me and having a productive conversation threebean and sgallagh 16:40:39 :) 16:40:45 again, sorry for not responding on the list sooner. 16:40:54 jwb: Thanks very much for keeping us honest and transparent 16:40:57 #agreed Modularity Changes are approved provided that they are emended to say that policies must b in place before restrictions are lifted (+1: 6, -1: 0, +0: 0) 16:41:09 #topic #1647 F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates 16:41:12 .fesco 1647 16:41:13 maxamillion: Issue #1647: F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates - fesco - Pagure - https://fedorahosted.org/fesco/ticket/1647 16:41:14 https://pagure.io/fesco/issue/1647 16:41:34 I think this is going to make for a more-exciting-than-usual mass-rebuild, but I'm +1 16:42:03 yeah, same 16:42:05 +1 16:42:08 maxamillion: I'm +1 to the previous one, by the way, sorry for the late vote 16:42:13 Rathann: no worries 16:42:14 * paragan will be happy to help and fix any build failures from mass-rebuild 16:42:28 +1 to this change 16:42:28 and I already voted +1 in ticket #1647 16:43:16 +1 from me. even if it makes the mass rebuild more exciting, I think -Werror=implicit-function-definition is definitely worth breaking the builds for so that people are forced to fix this 16:43:17 +1 16:44:10 jwb: ? 16:44:51 OK, I have to leave, but my votes are in the ticket (please count them) 16:44:58 *tickets 16:45:03 maxamillion: i voted +1 in the ticket 16:45:08 oh, sorry 16:45:22 np, i was being lazy 16:45:26 fair :) 16:45:41 #agreed F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates (+1: 7, -1: 0, +0: 0) 16:45:47 #topic Next week's chair 16:46:28 maxamillion: we might want to see if there will be quorum first 16:46:36 * jsmith is late (sorry, silly time zone changes) 16:46:44 I am available next week 16:46:46 I'm happy to take next week's 16:46:49 US has a holiday on thurs and most people are off friday because of crazy shopping time 16:46:52 next week is a holiday in the us 16:46:53 I may be unable to attend next week 16:46:56 ah 16:47:06 i'm going to be completely afk 16:47:15 oh right 16:47:25 maybe postpone the next week meeting 16:47:28 I'll be completely AFK as well 16:48:03 proposal: skip next week 16:48:34 (which would make the next meeting dec 2nd... 2016-12-02) 16:48:51 right 16:49:06 +1 16:49:19 +1 16:49:40 +1 to skip next week meeting 16:49:41 +1 16:49:58 +1 for my own proposal 16:50:07 oh great 16:50:11 +1 16:50:18 I have plans for next Friday too 16:51:52 we're missing sgallagh ... did he have to step away already? 16:52:20 As we are skipping the next week meeting I will suggest to keep voting in the tickets 16:52:30 I believe so. 16:52:30 maxamillion: yes 16:52:34 #agreed: Skip next week's FESCo Meeting, the next time we will meet will be 2016-12-02 (+1: 6, -1: 0, +0: 0) 16:52:35 paragan: also yes 16:53:01 #info: voting should continue in pagure tickets on FESCo issues 16:53:21 so ... who's going to chair on 2016-12-02? 16:53:46 I'll take 12/02 if nobody else volunteers 16:53:56 thanks jsmith 16:54:05 (and again, sorry for being late today) 16:55:40 #info jsmith to chair 2016-12-02 FESCo Meeting 16:55:45 #topic Open Floor 16:56:29 Can we close this ticket https://pagure.io/fesco/issue/1638 ? 16:56:39 looks we got +5 votes there 16:57:34 sure. We should document it tho... 16:57:43 +1 16:58:37 nirik, agree 17:00:11 I can just go do that if people are ok with those 2 places. 17:00:30 * paragan is okay to document it both places 17:00:34 +1 17:00:46 alright, anything else for Open Floor? 17:01:13 nothing from my side 17:01:37 nirik++ thanks for volunteering to document it 17:02:16 nirik++ 17:02:25 alright, I'll give it 60 more seconds before I close up shop 17:02:30 yup, thanks nirik 17:05:02 #endmeeting