18:00:29 #startmeeting FESCO (2015-12-09) 18:00:29 Meeting started Wed Dec 9 18:00:29 2015 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:29 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:29 The meeting name has been set to 'fesco_(2015-12-09)' 18:00:29 #meetingname fesco 18:00:29 The meeting name has been set to 'fesco' 18:00:29 #chair ajax dgilmore number80 jwb nirik paragan rishi thozza sgallagh 18:00:29 Current chairs: ajax dgilmore jwb nirik number80 paragan rishi sgallagh thozza 18:00:29 #topic init process 18:00:33 .hello sgallagh 18:00:34 sgallagh: sgallagh 'Stephen Gallagher' 18:00:40 .hello kevin 18:00:41 nirik: kevin 'Kevin Fenzi' 18:00:47 .hello jkurik 18:00:48 hi 18:00:49 jkurik: jkurik 'Jan Kurik' 18:00:57 Hi 18:00:58 .hello thozza 18:00:59 thozza: thozza 'Tomas Hozza' 18:02:32 sgallagh: I am busy for 15-20 minutes 18:02:32 .hello rishi 18:02:33 rishi: rishi 'Debarshi Ray' 18:03:00 dgilmore: OK, I'll move the updates-deliverables topic to later in the meeting 18:04:34 Well, we have quorum. 18:04:43 #topic #1478 F24 Self Contained Changes 18:04:43 .fesco 1478 18:04:44 sgallagh: #1478 (F24 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1478 18:05:20 +1 18:05:20 this one: https://fedoraproject.org/wiki/Changes/KojiSignedRepos 18:06:07 sgallagh: +1 to #1478 18:06:07 +1 18:06:18 +1 18:06:44 +1 18:07:15 +1 18:07:25 sorry, present now 18:08:10 hello 18:08:15 +1 18:08:39 +1 but there was a somewhat orthogonal question on signed metadata 18:08:48 curious if there was an answer there? i don't remember seeing one 18:10:01 #agreed Self-Contained Change "Koji Signed Repos" is approved (+7, 0, -0) 18:10:50 * nirik doesn't think signed metadata gets us anything, but it's possible to do 18:11:14 nirik: maybe reply with why you think that? 18:11:20 where was the question? 18:11:52 nirik: devel list 18:11:55 from petr 18:11:56 oh, devel. mikem answered 18:12:09 "That is out of scope as koji will not be actually performing signing as 18:12:09 part of this feature, just utilizing rpm signatures that have already been 18:12:09 imported. Neat idea, but bigger problem and not really related to this" 18:12:43 nirik: yes, i saw that. it wasn't really an answer to the underlying question, just "we won't do this" 18:12:47 anyway, i'm getting us offtrack 18:12:48 OK, so is there anything for FESCo to discuss here? 18:12:58 sgallagh: no 18:13:07 I'll reply further. 18:13:09 OK, then I'll move along 18:13:22 #topic #1511 F24 System Wide Change: Default Local DNS Resolver 18:13:22 .fesco 1511 18:13:24 sgallagh: #1511 (F24 System Wide Change: Default Local DNS Resolver) – FESCo - https://fedorahosted.org/fesco/ticket/1511 18:13:32 We realized that we can not commit enough time to make everything complete for F24 Alpha due to Christmas and other priority things. We still think it is important to have this in Fedora and want to keep working on it, but not for F24. For the record, the decision has nothing to do with any devel list discussion. 18:13:44 jkurik: We want to keep the tracking bug if possible 18:13:53 so I think we can skip this right away 18:13:55 thozza: So you are withdrawing this from consideration? 18:13:55 thozza: so you are officially delaying this again? 18:14:12 jwb We are officially not aiming F24 18:14:17 thozza: ok, no problem 18:14:32 thozza: does it really not have _anything_ to do with the devel list discussion? i would hope that some of the concerns there are at least being evaluated 18:14:32 bummer. ;( 18:14:46 sgallagh: yes, I can not commit the time right now and other owners didn't note they can 18:15:06 thozza: FWIW, the proposal would be more convincing if it had some research about what other popular client-side OSes do. 18:15:12 jwb: Nothing new happened 18:15:18 we are aware of the things 18:15:34 thozza: ok... i'm not sure what the means. 18:15:43 The recent purchase of the .box TLD made me snicker. But that's off-topic. 18:15:56 Yeah. :) 18:16:09 rishi: unfortunatelly I don't have Mac OS, nor Windows available 18:16:15 but I'm not the only owner 18:16:22 thozza: I hope you are not the only one working on it. :) 18:16:28 thozza: Sure, but there must be literature on it out there. 18:16:39 I am sure it should be possible to get access to such systems. 18:16:40 thozza: if you would like to test windows, contact me offline 18:16:45 rishi: well, that is the main reason why we are not aiming F24, because It seems so 18:16:58 thozza: How is Android doing it? AOSP should have something to poke at, right? 18:17:22 thozza: A few lines like: "this is also what Android and Windows are doing these days" goes a long way in convincing people. :) 18:17:32 sgallagh: Don't know, although there is one person porting Unbound to Android 18:17:34 thozza: (Please don't interpret this as attacking your efforts, we just want more info) 18:17:44 sgallagh: correct 18:17:47 Atleast that's how I think since I don't claim to be a networking expert. 18:18:05 Right. I just wanted to note that Lennart didn't make me do this 18:18:33 i don't care who raised the concerns. the concerns seem valid, so i appreciate taking the time to work through everythign 18:18:44 thozza: Eh? I did find his question valid. 18:19:24 But given the necessity to integrate everything with teams where we have no guaranteed commitment (NM, Gnome, ....) I don't think F24 is realistic 18:20:01 rishi: he had couple of suggestions we are aware of and are actually trying to get solutions to IETF RFC 18:20:14 and we also have possible solution 18:20:17 thozza: great 18:21:23 thozza: Cool, although I am not sure "solutions to IETF RFC" means. But I trust you. 18:21:29 *what 18:21:51 ie, make the solution a standard, not just something we do 18:21:54 rishi: I mentioned it in my response to the list 18:22:09 thozza: I am still reading the thread. 18:22:36 thozza: But, please, it would be awesome if you had a ready answer to the "what do other client-side OSes do" question. 18:22:55 That will immediately win over people, like me, who are relatively clueless about networking. 18:22:59 rishi: I agree, but unfortunately I don't know 18:23:09 I expected other people to comment on this 18:23:33 e.g. Paul Wouters is more familiar with other OS in this regard IMO 18:23:40 ok, it seems like thozza is doing all the proper things here. perhaps we should move on in the meeting? 18:23:42 sorry here now 18:23:49 jwb: agreed 18:23:50 thozza: Yeah, but you know how people are. It is easy to shoot something down. :) 18:23:57 jwb: agreed 18:24:04 rishi: right 18:24:22 As a non-binding resolution, we could assert that FESCo considers DNSSEC to be important for Fedora's future, as a means to spur folks to action. 18:24:44 sgallagh: fine with me 18:25:02 sure 18:25:26 Ok. 18:25:47 i mean, to the extent dnssec solves the problem, sure. 18:25:53 Because I'd like to see us at least coming through as supportive of a solution here. (Even if ultimately it isn't exactly the same as the one currently proposed) 18:26:15 i'm not entirely convinced that strong cryptographic assurances of dns are all that awesome given that i don't necessarily trust dns' root of trust 18:27:03 ajax: I'm thinking that falls into the realm of "perfect being the enemy of good". It's better than the status quo. 18:27:15 exactly 18:27:30 but i've not paid enough attention to know whether dnssec solves the "turkey hijacks a.root-servers.net so you need to use 8.8.8.8" problem 18:27:52 thozza: I question how hotspot detection should work if someone is not using workstation, i.e. using the Xfce or KDE spins 18:28:27 dgilmore: Let's take implementation questions back the list, ok? 18:28:34 dgilmore: last time we discussed with NM devels that we may try to have DBus interface in dnssec-trigger, so that other desktops can integrate 18:28:35 sgallagh: sure. 18:29:18 also they realized that they rely on resolv.conf containing the resolvers from DHCP so they can not do the detection with localhost address there 18:29:49 * nirik has been using dnssec-triggerd with Xfce for a long long time. 18:29:50 #info FESCo would like to assert that DNSSEC is important for the future of the Fedora Project and as such we urge anyone who can do so to assist in working out the remaining issues with implementation. 18:29:56 the bottom line is that we have to coordinate things and come up with compromises 18:29:59 +1 18:30:05 +1 18:30:26 +1 18:30:28 That wasn't a call for another vote; we had enough affirmatives and no negatives that I figured it was fine to just info 18:30:39 yeah. moving on 18:30:51 :) 18:31:06 #info The DNSSEC Change Proposal is deferred from F24 due to lack of resources during the available timeframe 18:31:11 sorry if I disappointed anyone :) 18:31:22 #topic #1512 F24 System Wide Change: Node.js 4.2 18:31:22 .fesco 1512 18:31:23 sgallagh: #1512 (F24 System Wide Change: Node.js 4.2) – FESCo - https://fedorahosted.org/fesco/ticket/1512 18:31:25 thozza: thanks for putting in the effort and trying 18:31:57 ;) 18:32:02 So, this is a long time coming. Unfortunately the person who had been single-handedly maintaining the nodejs stack in the past disappeared. 18:32:03 +1 to nodejs 18:32:13 Several of us have started the process of moving to the latest LTS release. 18:32:27 Yes, +1. 18:32:34 +1 18:32:34 +1 (this was delayed from F23) 18:32:39 I'm obviously +1 to my own Change 18:32:43 thozza: i am not disappointed at all. i am encouraged 18:32:50 +1 18:33:10 sgallagh: disappeared? 18:33:25 sgallagh: did we go through the MIA maintainer thing? 18:33:28 jwb: He's gone non-responsive, but a Node.js SIG has sprung up. 18:33:36 +1 18:33:37 All of his packages are comaintained by the SIG, so it's not an issue 18:33:41 oh good 18:33:43 +1 18:33:50 +1 18:34:21 jwb: If we missed any, several SIG members are provenpackagers as well, so we should be able to get by anyway. 18:34:40 #agreed System-Wide Change Node.js 4.2 is approved for Fedora 24 (+8, 0, -0) 18:34:48 sgallagh: i was mostly just making sure we weren't subverting our own process after having told several people not to do that recently 18:35:12 jwb: not to do what? 18:35:29 sgallagh: skip steps of the non-responsive maintainer process 18:35:31 hijacking things 18:36:20 I don't think that's a concern here. 18:36:29 OK, let's move on. 18:36:37 #topic #1444 updates deliverables 18:36:37 .fesco 1444 18:36:38 sgallagh: #1444 (updates deliverables) – FESCo - https://fedorahosted.org/fesco/ticket/1444 18:37:23 some of my concern here is averted with the two week atomic 18:37:30 but not entirely 18:38:22 dgilmore: What are your remaining concerns? 18:39:31 sgallagh: that it is not clear what we should be making as part of the updates process. I want to make sure that all expectations are met 18:40:12 we have the updates repos, updates-testing repos, atomic repos for both today 18:40:32 we make the two week atomic deliverables by a different process 18:40:36 dgilmore: "both"? 18:40:44 updates and updates-testing 18:40:47 sgallagh: updates and updates-testing 18:40:51 Oh ok. Sorry. 18:40:56 Thank you for clarifying 18:41:52 sgallagh: its likely to get much more difficult and unclear when we start doing layered images and other consumable formats 18:41:59 so would the glorious future have us making a full compose for every updates push? 18:42:13 i.e. do the layered images get thier own updates and testing cycles 18:42:15 etc 18:42:36 nirik: not sure we will ever want to do that 18:42:50 at least until we move to a rolling release 18:43:02 me either, just trying to get a handle on any goal here. 18:43:39 for me the goal is to have a clear contract of sorts in what is expected of releng, and what users can expect. 18:43:43 It might just have to be us doing what we are doing and people requesting new stuff as we go, because it's hard to know what new thing people want when 18:44:06 nirik: on RHEL we have introduced so called Batch updates, to collect update for certain period and then we do compose for each batch and docker images are on top of it 18:44:42 right 18:44:53 Maybe something like monthly updates + urgent CVEs would be frequent-enough? 18:44:55 yeah, thats been proposed for fedora as well. 18:44:58 maybe we want to do monthly updates of lives, docker etc 18:45:06 (In terms of doing a full compose) 18:45:53 sgallagh: changing how we push updates is a different discussion maybe 18:46:02 as in doing less frequent pushes etc 18:46:27 Well, I was thinking orthogonally to that in terms of rebuilding the docker base image, the vagrant image, etc. 18:46:43 what I want to avoid is someone coming to me a month after f24 is released and say why are you not pushing out foo updates 18:46:56 where foo is something not a rpm or atomic repo 18:47:12 sgallagh: we actually build them for f23 nightly 18:47:26 sgallagh: they get built as part of the two week nightly compose 18:47:35 dgilmore: I'm perfectly ok with having a deadline for when such requests have to be made and telling people "wait for Fedora N+1" after that 18:47:36 but only f23 not f22 18:47:47 dgilmore: oh, ok. I didn't know that. Thanks 18:47:55 also playing into this is the PDC... so we know what actually might need rebuilding and what doesn't 18:48:23 nirik: right. we would then need to write something to dynamically make the compose configs 18:48:37 but it is in my long term plans 18:48:44 nirik: expand PDC please? 18:49:01 jwb: Product Definition Center 18:49:11 jwb: https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter 18:49:22 it's the thing that will know for example if we update 'foo' rpm, what images/things we would need to redo 18:49:30 oh, right 18:49:37 so we could not rebuild things that don't have any changes. 18:49:45 (as if that ever happens in fedora :) 18:50:10 * jwb raises an eyebrow at the "until we move to a rolling release" comment above 18:51:31 jwb: it is an idea I have rolling around in my head. Its something i talked about briefly in the interview questions when I ran for FESCo 18:51:41 not saying we will do it 18:52:22 * nirik thinks rawhide is enough rolling for those that want it. Most people really don't want a rolling release IMHO 18:52:34 at the least I want to get a development stream that looks like a full release everyday and is a rolling release that can be relied on 18:52:47 nirik: may be as far as it goes 18:52:55 sure. 18:53:22 so what can we do here? I think we may have to just say 'please submit any updates deliverables as part of a change when you submit the change' ? 18:53:56 We should probably decide where to record the list of stuff that is being updated 18:54:05 nirik: there is already a question in the Change template asking whether the Change affects deliverables 18:54:24 nirik: I guess we say that updates deliverables are the atomic repos and the updates rpm repos, if you want anything else you need to ask for it in your change 18:54:33 sgallagh: the PDC? 18:54:53 dgilmore: docker? 18:55:01 i thought you said you're already updating docker images 18:55:37 jwb: we make docker, cloud, vagrant images along with updated atomic installer as part of the nightly two week compose 18:55:46 jwb: but we do not push them out 18:55:53 its kinda a seperate thing 18:56:14 jwb: and we only do it for f23 currently, we switched f22 off when f23 was released 18:56:33 dgilmore: is there a reason not to include it in the "list of stuff being updated" though? 18:56:42 jwb: so it is not a universal thing, and is done on the side 18:57:06 jwb: yes because when f24 comes out f23 will stop being done. 18:57:45 without adding a caveat that its life span is shorter I would not want to set an expectation that it will be updated 18:58:00 * rishi notes that it's almost an hour now 18:58:11 rishi: the meeting is 2 hours 18:58:18 is this all mentioned in the 2 week atomic docs/stuff? 18:58:32 nirik: not 100% sure on that 18:59:30 jwb: if we want to do it for the life of the OS I am okay with adding it 19:00:14 perhaps saying on the first tuesday of each month we will push out updated docker and cloud images 19:00:27 ok, let's take this in smaller steps. is there anyone that thinks the PDC isn't NOT the place to have this list? 19:00:58 jwb: it is designed as the place to have it 19:01:13 great. so we have the where. now we work on the what 19:01:47 i think everyone agrees atomic repos and updates rpm repos go on the list 19:01:50 yay 19:01:59 Ack 19:02:05 ack 19:02:28 if we're updating other things that are available, we should add them too. even if their lifecycles are different. why? because we should be able to have independent lifecycles anyway 19:02:53 because we already have that requirement with 2 week atomic. 19:02:57 well, yeah, we should note them for sure. 19:03:02 The two-week atomic also implies the various Fedora Cloud deliverables, yes? 19:03:09 We should list them explicitly 19:03:20 and because in the future products might diverge in lifecycle 19:03:32 (scary big change not actually planned) 19:04:00 * number80 has to attend another meeting 19:04:14 sgallagh: we make an updated atomic installer, cloud base image, cloud base vagrant image, cloud atomic image, cloud atomic vagrant image, docker base image 19:05:04 dgilmore: That's great. I'm just saying we want those listed explicitly in the PDC 19:05:24 dgilmore: is there any plan to have Fedora Docker images for ARM? 19:05:45 little bit off topic (sorry) 19:06:20 thozza: yes, I made some on the side for f22, trying to figure out the best way to get hardware that can run arm vms to be able to make them for f24 19:07:01 dgilmore: I saw those, but was looking for F23 ones and didn't find them 19:07:36 thozza: I have not made any, I need to fix a u-boot bug to get kvm working again 19:07:52 OK, so what is left for us to do here? 19:07:55 thozza: lets talk about this elsewhere 19:08:00 It seems to me that we have the three things we needed: 19:08:10 sgallagh: wait for PDC to exist and rel-eng to populate it with the things it already updates? 19:08:25 dgilmore: right, thanks 19:08:28 beyond that, the "request new things as they come" seems to be the sanest plan 19:08:32 * nirik nods 19:08:33 1) We know where we're going to keep the list of things to be updated - PDC 19:08:44 2) We know the initial set of things that are going into that list - see above 19:09:06 3) We will figure out a reasonable deadline for each Fedora release by which someone has to add something to the list. 19:09:22 I guess we could bikeshed 3, but otherwise I think this seems more or less solved? 19:09:39 +1 19:10:14 yes 19:10:28 +1 Thats what I was after. 19:12:20 #info The PDC will retain a list of the artifacts that will get post-release updates. This list will initially contain: updated RPM repos, atomic repos, atomic installer, cloud base image, cloud base vagrant image, cloud atomic image, cloud atomic vagrant image, docker base image. There will be a deadline set after which this list becomes immutable for that Fedora release. 19:12:31 (Acceptable summary?) 19:13:04 +1 19:13:08 +1 19:13:52 +1 19:13:59 #undo 19:13:59 Removing item from minutes: INFO by sgallagh at 19:12:20 : The PDC will retain a list of the artifacts that will get post-release updates. This list will initially contain: updated RPM repos, atomic repos, atomic installer, cloud base image, cloud base vagrant image, cloud atomic image, cloud atomic vagrant image, docker base image. There will be a deadline set after which this list becomes immutable for that Fedora release. 19:14:16 #agreed The PDC will retain a list of the artifacts that will get post-release updates. This list will initially contain: updated RPM repos, atomic repos, atomic installer, cloud base image, cloud base vagrant image, cloud atomic image, cloud atomic vagrant image, docker base image. There will be a deadline set after which this list becomes immutable for that Fedora release. (+5, 0, -0) 19:14:25 #topic Next week's chair 19:14:50 So in the end the new FESCo will be next week 19:14:54 my jury duty for this week was delayed until next. i cannot guarantee i will be present 19:14:58 if we are willing to start 20-30 minutes late I can do it 19:15:18 thozza: In that case I am out. 19:15:25 * thozza too 19:15:38 * rishi needed a break 19:15:48 * thozza too :) 19:16:40 I could do it next week, but I am in the election, so may not be in. ;) 19:16:44 that is concerning 19:17:05 nirik: If you want to volunteer, I'll cover it if you don't get re-elected. 19:17:13 alright 19:17:23 I assume we are not meeting the following 2 weeks? 19:17:39 That will depend on when we move the regular meeting time 19:17:47 i'll be on PTO for those, so you guys can do whatever you'd like :) 19:17:56 nirik: I assume we will on the 23rd but not the 30th 19:18:04 If it gets moved to Monday, for example, some of us might be there. 19:18:28 Let's decide that after the new FESCo is seated. 19:18:31 * rishi slowly moves away from the computer 19:18:33 proposal, cancel meetings on the 23rd and 30th 19:18:45 we could decide next week sure. 19:18:47 or just wait 19:18:48 #info nirik will chair next week's meeting, assuming he's re-elected. If not, sgallagh will pick it up. 19:18:50 * nirik will be out both those weeks. 19:18:50 dgilmore: Isn't that something best done with the new FESCo? 19:19:04 rishi: maybe 19:20:23 #topic Open Floor 19:21:30 Anything? 19:21:51 nada 19:22:04 I'll hold the meeting open for another two minutes. 19:22:29 since new fesco is next week i doubt anyone expects me to be around 19:22:35 but i definitely won't be, i'll be on pto 19:22:59 ajax: enjoy 19:23:15 Was going to ask about an issue that came up in FPC, but I really should file a ticket instead. 19:23:15 ajax: have a good vacation 19:23:29 tibbs|w: Is this the pre-generated code thing? 19:23:33 Yes. 19:23:52 Yeah, please file a ticket on that. I think it's going to require Discussion. 19:23:56 I don't think it's FPC's domain to decide if something is "free enough". 19:24:18 So, yeah. I was too slow/lazy to get it in before this meeting. 19:25:12 The short version is this: "For packages that ship pre-generated code in their tarball, does FESCo want to insist that the files that were required to generate that code must also be present in the SRPM?" 19:25:43 As I said, this is probably going to require some extended discussion, so I think it would be best to take it to a ticket. 19:26:04 And also, does FESCo want to insist that the tools necessary to actually generate those files be 1) free and 2) actually packaged in Fedorqa. 19:26:29 uh, don't we already have a guideline that talks about this? 19:26:32 Right, I'd actually name that as two separate-but-related questions. 19:26:44 We don't to my knowledge. 19:27:04 pretty sure we do. it's how things like seabios and crap are pacakged 19:27:12 jwb: This is for handling stuff like the output of gdbus-codegen for example. 19:27:35 jwb: Perhaps you're thinking of the code vs. content thing. 19:27:38 OOHHH 19:27:39 Or in the case that inspired it: a tarball that carried yacc output. 19:27:49 generated code as in literally code 19:27:52 Where we don't require the tools to generate the content be free or packaged. 19:27:52 yes 19:28:00 oh fun 19:28:01 But this is 100% code. 19:28:38 Depending on the license, there's a legal question in there as well, so I'll have to involve them. 19:28:50 I just need to actually do that. 19:28:58 this include things like coccinelle scripts. but those should be trivial 19:29:11 Right, it's a big issue. 19:29:24 It involves our ability to actually fix/patch code. 19:30:06 Anyway, fun for FESCo. I'll get back to actually trying to file the ticket. 19:30:14 tibbs|w: Thanks 19:33:07 tibbs|w: if it is machine generated code, I would nearly be inclined to say you need to run the process to generate it as part of the build 19:33:22 a foolish consistency... 19:33:26 dgilmore: We've had that debate before. *bleeping* autotools 19:33:42 but it is likely a much bigger topic than we can do today 19:33:46 sgallagh: ;) 19:34:22 Yes, autotools is one example about which we've talked in the past, but the question is larger than that. 19:34:41 Anyway, FPC didn't think this was exactly their thing, so.... 19:34:54 Right, but I mostly bring it up because every time we discuss it, we learn that it's basically impossible to demand that we regenerate everything 19:35:08 So we strongly recommend it. 19:35:37 OK, we'll table this for this week. 19:35:50 #action tibbs|w to file a ticket around auto-generated code 19:35:56 Anything else for Open Floor? 19:36:10 Except, yeah, I don't think we actually recommend it anywhere, or mention it at all. 19:37:27 tibbs|w: I swear we used to... oh well 19:38:11 I just remember a bunch of arguments about it, but no resolution. 19:39:03 I guess we can end the meeting 19:39:10 OK, works for me. 19:39:13 Thanks for coming. 19:39:17 #endmeeting