16:30:59 #startmeeting fedora_atomic_wg 16:30:59 Meeting started Wed Nov 15 16:30:59 2017 UTC. The chair is walters. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:59 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:59 The meeting name has been set to 'fedora_atomic_wg' 16:31:26 #topic Roll Call 16:31:33 .hello walters 16:31:34 walters: walters 'Colin Walters' 16:31:36 .hello2 16:31:37 .hello strigazi 16:31:37 ttomecek: ttomecek 'Tomas Tomecek' 16:31:39 .hello2 16:31:40 strigazi: strigazi 'Spyros Trigazis' 16:31:43 dustymabe: dustymabe 'Dusty Mabe' 16:31:51 .hello2 16:31:53 ksinny: Sorry, but you don't exist 16:31:55 .hello kurushiyama 16:31:56 kurushiyama: Sorry, but you don't exist 16:31:57 .hello miabbott 16:31:58 oops 16:31:59 miabbott: miabbott 'Micah Abbott' 16:32:00 .hello rubao 16:32:02 rubao: rubao 'rubao' 16:32:03 .hello sinnykumari 16:32:04 * miabbott is only around for the first 1/2 of the meeting 16:32:05 ksinny: sinnykumari 'Sinny Kumari' 16:32:08 * coremodule is present! 16:32:12 .hello coremodule 16:32:13 coremodule: coremodule 'Geoffrey Marr' 16:32:19 ksinny: yeah your fas name has to match your nick if you want .hello2 to work 16:32:47 dustymabe: thought so 16:32:51 .hello gscrivano 16:32:52 giuseppe: gscrivano 'Giuseppe Scrivano' 16:33:08 .fas jasonbrooks 16:33:09 jbrooks: jasonbrooks 'Jason Brooks' 16:33:10 016047 16:33:27 #chair giuseppe dustymabe ksinny rubao coremodule strigazi ttomecek jbrooks 16:33:27 Current chairs: coremodule dustymabe giuseppe jbrooks ksinny rubao strigazi ttomecek walters 16:33:30 .hello jlebon 16:33:31 jlebon: jlebon 'None' 16:33:32 welcome coremodule 16:33:35 #topic Action items from last meeting 16:33:52 (i am totally just copy-pasting https://fedoraproject.org/wiki/Atomic_WG#Meetings - whoever wrote that thank you!) 16:34:18 hi 16:34:24 #topic https://pagure.io/atomic-wg/issue/354 16:35:00 walters: i usually paste them in here 16:35:05 do you want me to do that this time? 16:35:11 sure 16:35:24 .hello davdunc 16:35:25 i get them from meetbot here 16:35:26 davdunc: davdunc 'David Duncan' 16:35:28 https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-08/fedora_atomic_wg.2017-11-08-16.30.txt 16:35:34 * jberkus to post target publication, calendar of posts later today to 16:35:36 mailing list 16:35:38 * jberkus to get out survey about container runtimes 16:35:40 * jbrooks jberkus to test asciibinder rpm 16:35:42 * maxamillion to announce to the world that we are planning to remove 16:35:42 ah ok, got it 16:35:44 fedora docker layered images from docker hub and start fresh 16:35:46 * jberkus to propose new quorum rules based on scheduled online votes 16:35:49 #topic Action items from last meeting 16:36:01 #topic Action items from last meeting 16:36:06 #link https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2017-11-08/fedora_atomic_wg.2017-11-08-16.30.txt 16:36:20 * dustymabe notices jberkus is MIA 16:36:32 and so is adam 16:36:35 I tested the asciibinder rpm in a container, it errored out, I replied to the maintainer, don't think I've heard back 16:36:48 jbrooks, is there a bz for that? 16:36:50 .hello2 16:36:51 maxamillion: maxamillion 'Adam Miller' 16:36:54 maxamillion: hiya 16:37:02 we are in previous action items 16:37:09 * maxamillion to announce to the world that we are planning to remove 16:37:12 walters, It was a comment on his copr test, not sure where to bz 16:37:16 ah got it 16:37:51 dustymabe: still on my TODO, I'm trying to get the rebuild stuff in line so I can have an actionable sync operation, I don't want to say we're removing and switching until we're actually ready to do it 16:38:08 if others would rather the announcement go out, then I can do it sooner rather than later 16:38:20 Ah, he did respond, and it's ready to test again 16:38:36 Oh, missed the new meeting time :( 16:38:39 https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/message/Y5BKMAC3HB3BNPQAT5M4GUE5QFQTYZYH/ 16:38:47 So, 16:38:57 maxamillion: so re-action 16:38:57 #action jbrooks to retest asciibinder rpm 16:39:05 kushal: :) 16:39:11 just started 16:39:16 dustymabe, thanks 16:39:21 .hellomynameis kushal 16:39:22 kushal: kushal 'Kushal Das' 16:39:26 maxamillion My two cents: It might be of advantage for people which will need/want to adapt/migrate to get early notice. 16:39:48 ok walters mind re-actioning items from jberkus? 16:40:00 #action jberkus to post target publication, calendar of posts later today to mailing list 16:40:04 #action jberkus to get out survey about container runtimes 16:40:10 #action jberkus to propose new quorum rules based on scheduled online votes 16:40:31 kurushiyama: I'm open to whatever the consensus is, but we've yet to reach one 16:40:56 maxamillion: on the topic of removing the fedora dockerfiles images on docker hub? 16:41:04 i thought we reached concensus on that one pretty easily 16:42:13 yeah i didn't think anyone objected 16:42:16 dustymabe: no, about the announcement ... do we wait until we're ready to pull the trigger or should I just announce it and we'll get around to actually doing it when it's all ready 16:42:28 ?* 16:42:29 im for announcing now 16:42:41 I'm against announcing now 16:42:42 then when we do it just respond to the announement email 16:43:07 so a pre-announce. 16:43:08 ok. either way works 16:43:19 but I'll do it if people would prefer it 16:43:27 i didn't anticipate there being a long time between when we announced and when we did it 16:43:32 hence the Action Item 16:43:37 .hello jberkus 16:43:38 jberkus: jberkus 'Josh Berkus' 16:43:43 those are typically for 'things to do this week' 16:43:44 sorry I'm late, pest control issue 16:44:09 dustymabe: I didn't either, but I can't ever seem to get a solid block of time to work on the automation, the interrupt work leading up to and dealing with the f27 release has been rough ... also OSBS in stage had to be rebuilt ... it's been one dumpster fire after another 16:44:09 Since maxamillion is the one doing it, I'm good w/ his announce timetable 16:44:21 jbrooks: meh, it's just an email :) 16:44:24 maxamillion: indeed. 16:44:31 lets drop the action item and track it in a ticket then 16:44:37 can you create a new ticket for that? 16:44:39 dustymabe: I can 16:44:42 cool 16:45:39 .hello mwmahlberg 16:45:40 kurushiyama: mwmahlberg 'Markus Wolfgang Mahlberg' 16:46:00 let's move to this week's items then? 16:46:04 +1 16:46:11 #topic https://pagure.io/atomic-wg/issue/354 16:46:32 kurushiyama: I did not get to the quorum rules; sorry, with the survey and the F27 release I dropped that 16:46:57 jberkus Cool. Just when you are ready. 16:47:52 feels like this one is good to continue conversation in ticket? 16:48:04 walters: mostly 16:48:14 was hoping someone could summarize as the ticket is getting quite long 16:48:22 yeah i had to reread it 16:48:33 will give 1 more min for people to comment, i'm just going to pile on there though 16:49:05 i fall into the "i'm ok with whatever as long as it's consistent and not too burdensome on the maintainer" camp 16:49:33 same 16:49:45 yah, we're just trying to figure out what that is 16:50:16 the only issue still being discuss is whether we should allow automated conversion of man pages which doesn't fit the format 16:50:41 jberkus: so we're pretty close to resolution? 16:50:53 ok only 10 mins left, let's move on if people are OK with that? 16:51:02 Wouldnt it make more sense to have one central "source of truth" and generate the various formats needed from that? 16:51:30 kurushiyama: kinda, except that there's not necessarily a 1:1 correspondence between packages and containers 16:51:32 walters: we usually run for an hour, but i'm not opposed to having a shorter meeting today 16:51:39 oh right, sorry 16:53:05 anyone with anything else to say? 16:53:24 i dropped a comment in the ticket 16:53:46 still waiting for details from the AWS Marketplace, but I am pushing. 16:53:48 dustymabe: can I confirm our publication schedule for F27 blogs? 16:53:58 and is ksinny here? 16:54:00 jberkus: in open floor? 16:54:06 sure 16:54:07 we are still in tickets phase 16:54:48 #topic https://pagure.io/atomic-wg/issue/360 16:55:12 i think this one had to do with jberkus' action items and the survey 16:55:33 btw, it's helpful for the meeting logs if you say what the ticket is as well as the number 16:55:42 container runtimes in atomic host ^^^ 16:55:47 "Decide strategy for including container runtimes in Atomic Host" 16:56:09 i usually #topic the title and #link the url 16:56:17 ah 16:56:56 what confuses me on this a bit is - if we go this direction how much different are we from a "minimal install"? 16:56:58 jberkus: yes 16:57:07 Is a docker-ce system container considered at all? from the docker repos? 16:57:31 I have 43 responses to the survey 16:57:34 strigazi, i am not sure docker upstream has looked at the syscontainer approach 16:57:43 a few of them are members of the Fedora Atomic team, so I need to filter those out 16:57:54 I do not see why the community could not provide alternative runtimes since they are not mutually exclusive. Stripping away a proven setup would make Atomic an immutable Alpine... ;) 16:57:57 * kurushiyama takes cover 16:58:00 jberkus: i'll note I have abstained from responding 16:58:06 yah 16:58:07 i guess an important detail here is "do we still include container-selinux"? 16:58:09 but i will respond if you'd like that input 16:58:16 no 16:58:26 we're looking for users here, particularly users we don't otherwise hear from 16:58:33 and actually that requirement is something where syscontainers would need a host dependency 16:58:50 if it's possible for any of you to broadcast that survey link so we can get more results, that would be great 16:59:03 https://goo.gl/forms/OBVcbz00dwZpcLb52 16:59:09 * kurushiyama fires up twitter 16:59:14 otherwise `atomic install docker` is going to be problematic on a yum-based system without container-selinux 16:59:28 At this point, only two of the 43 has serious objections to containerizing docker 16:59:53 but for one of them those objections are strong enough that downstream (i.e. RHAH) might choose NOT to containerize docker 17:00:05 I think we'd keep container-selinux 17:00:26 We'd be keeping atomic and runc, so it's not like we'd be including zero container components 17:00:26 so one question is, do we want to containerize docker if we know that downstream (RHAH, CAH) won't? 17:00:40 walters, we could add an .rpm dependency on the system container, if installed with --system-package=yes (which is the default) then it will be honored 17:00:52 we also have systemd-container 17:00:53 when the .rpm to track files on the host is installed 17:01:08 walters: isn't systemd-container just a wrapper around runc? 17:01:20 jberkus, systemd-container is nspawn from systemd 17:01:31 oh, right 17:01:35 do we use that for anything? 17:01:52 which ironically is only pulled in indirectly from oci-register-machine 17:02:02 * dustymabe still doesn't like the idea of removing docker from base system, but I'm not good at convincing others of my opinions these days 17:02:14 interestingly, 7 of our users claim to be running Docker 17 CE on Atomic Host 17:02:19 I wonder how they installed it? 17:02:22 (we don't list it explicitly) 17:02:37 I built a system container 17:03:11 That is how we used docker 17.x in FAH 17:03:40 (also we have bubblewrap which is pulled in indirectly too by rpm-ostree) 17:04:15 here's one chart which has a consistent trend: https://pasteboard.co/GTMOgGR.png 17:04:19 strigazi, Oh, cool, did you just base it off the existing docker one? 17:04:45 jbrooks yes, based on docker-centos syscontainer 17:04:53 leaving out the miscellaneus responses, we're just about evenly split between people who want the latest Docker and people who want a "stable" older version 17:05:05 (stable being Kube/Openshift support, probably) 17:05:12 My point of view is that the Red Hat family of OSes should be as consitent as possible to minimize migration efforts. 17:05:46 dustymabe: we wouldn't be doing a survey if it wasn't a split 17:06:35 kurushiyama: I don't like that because it infers that Fedora bends to Red Hat's will, but it doesn't and shouldn't, Fedora is beholden to the community 17:06:39 jberkus: there is a difference on what stable means based on swarm vs kube/openshift 17:07:04 kurushiyama, but Fedora is always going to be leading to some degree right? 17:07:21 strigazi: is there anything "stable" with swarm? 17:07:26 maxamillion I do not see it as bending, but rather agreement on a certain procedure to optimize the "user experience". 17:07:42 consistency with the latest kube release seems reasonable to me. 17:07:46 walters: I think he was responding to my question about whether we want to containerize docker if we know that RHAH won't 17:08:12 ah, right 17:08:19 jberkus: let's try to let user adoption define what is stable, user ask for it in general 17:08:22 walters Ofc. I can only say that from a users point of view, removing the included Container runtime will make a lot of people's life _a lot_ harder. 17:08:39 walters Docker, that is ofc. 17:08:41 that's definitely true 17:08:47 strigazi: I'm not sure what course of action your statement would mean 17:09:06 one detail here is it will force more people to do container image mirroring 17:09:21 Disclosing: If it was removed downstream, it would make the use of Docker close to impossible for us. 17:09:29 walters: or just package layer an rpm they build 17:09:43 kurushiyama: so if Fedora can't evolve, we're basically stuck delivering the RHEL experience but with newer versions of software forever ... so long as those newer versions of software don't actually change anything, yes? 17:10:16 dustymabe, yes, but also mirroring for the rpms 17:10:28 walters: yes 17:10:39 maxamillion No, that is not what I am trying to say. 17:10:48 i think we need to let more results come from the survey 17:10:52 (which for fedora is a lot more problematic due to all of the inherent races in how we deliver RPMs) 17:11:02 I don't know, I'm not so wedded to removing docker, I guess 17:11:03 maxamillion: isn't that the fundamental dilemma for Fedora? should we do things that we know that RHEL will never adopt? 17:11:16 My thing has been: what does this say about cri-o? 17:11:21 jbrooks: yeah 17:11:29 so here's the problems with NOT removing docker 17:11:38 1. base image/tree size 17:11:51 2. makes installing your own Docker (to get a different version) harder 17:11:53 maxamillion The point I am trying to make is that it should be consistent. By means of finding a procedure all parts can agree with. 17:11:57 jberkus: if there's enough community interest, why not? 17:12:16 3. de-facto promotes a specific version of Docker ahead of other runtimes 17:12:54 jberkus: i think you need to rephrase your title 17:12:55 jberkus: what I meant is, we can't tell users what stable is. I think having the option to use the stable for docker in a some way is positive. I don't want to flag swarm unstable and make it completely inaccessible 17:12:59 kurushiyama: pending scope, I'm in agreement 17:13:03 we have different options 17:13:04 maxamillion: I'm suggesting that sometimes the answer is going to be yes, and sometimes it's going to be no 17:13:17 1. NOT removing docker and DON't include CRI-O 17:13:28 2. NOT removing docker and INCLUDING CRI-O 17:13:31 i think i'd say *if* we remove we should try to make it sort of gradual somehow...maybe for f28 we simply don't start the service by default? 17:13:33 jberkus Regarding the promotional part... X-Windows? ;) 17:13:34 3. NOT including either 17:13:45 (starting docker.service by default is a huge pain point actually and i regret it) 17:13:53 i can do that pr right now 17:14:26 dustymabe: IIRC, including CRI-O will bulk up the base image by 20%, no? 17:14:35 walters: and maybe don't start container-storage-setup too? 17:14:44 strigazi, that'd be implicit in this 17:14:44 walters: i'm not opposed to that (because docker-storage-setup can be tricky), but let's open a ticket for it and discuss there 17:14:49 dustymabe, ok will do 17:14:55 jberkus: maybe. it's still an option 17:15:09 and we just removed kube, so we freed up some space 17:15:45 dustymabe: yet somehow the ISO download isn't smaller. What's up with that? 17:16:12 jberkus: honestly I haven't looked at the ISO download sizes lately, so I don't know 17:16:13 jberkus, the ISO also includes anaconda which is 50% of a desktop, with fonts etc. I'd guess that grew 17:16:22 walters: ah 17:16:36 maybe better comparison would be qcow sizes?? 17:16:40 How about different spins? 17:16:54 kurushiyama: honestly i've thought about that before 17:17:00 dustymabe the raw ones 17:17:16 i don't think we want to get too fractured, but I like the idea of COPRs for Atomic Host :) 17:17:23 also sadly we duplicate the initramfs a few times...i need to fix that 17:17:26 dustymabe I think this would be exactly the agreement we need.a 17:17:30 jberkus: I just don't understand why that's ultimately a concern of Fedora's. If Red Hatters are interested in joining the community and expressing their interests as members of the community, that's wonderful. However, this concept that Fedora as an organization should align with Red Hat as an entity seems weird 17:17:35 * walters filed https://pagure.io/atomic-wg/issue/384 17:18:19 It looks like the compressed qcow is about 20MB smaller 17:18:27 than in 26 17:18:30 maxamillion: i'm with you on the fact that we are Fedora and we can do whatever we want to. but as someone who helps manage more than just fedora it's a lot easier when I don't have to keep up with package differences between FAH RHELAH and CentOSAH 17:18:44 compressed raw 17:18:50 maxamillion: so that's a "no, we don't care what RHAH/CentOS will do with it" for you. 17:19:06 jberkus: any chance you could compare the uncompressed sizes? xz compression is magical 17:19:10 and might be skewing the numbers 17:19:38 jberkus: no, nevermind 17:19:43 I'm clearly not making my point well enough 17:19:52 it doesn't matter and is off topic 17:19:52 jberkus: i think officially that is our answer. we should never make a decision that hurts the community that benefits the downstreams 17:20:04 maxamillion: I think it's clear. 17:20:09 dustymabe: yes, that 17:20:09 Looks like 668 vs 750 for the qcows 17:20:20 but if it helps a good part of the community members that are doing the work then i'd say it makes sense to have alignment 17:20:28 dustymabe, kurushiyama: yeah, the perfect solution to this for everyone *except* Fedora RelEng would be to have separate trees, one with a built-in stable docker, and one without 17:20:35 dustymabe: it's about Fedora's community vs the downstreams, community should always win out but downstreams are welcome to that community 17:20:55 but I can imagine what suggesting that we double our number of trees/ISOs would provoke as a reaction 17:20:59 Do we know how much smaller the image would be w/o docker? 17:21:21 I don't imagine it would be that dramatic 17:21:22 jberkus Hm, would they? Or decide just to follow the Docker tree maybe? 17:21:52 kurushiyama: I don't follow 17:22:13 jberkus: my thoughts are that we would have the base tree. then a subtree (like a layer) that included docker, and another subtree that was for crio 17:22:22 we could have another subtree that was for libvirt/kvm 17:22:23 etc.. 17:22:31 but now we are heading towards the weeds 17:22:41 dustymabe: you would know better than me how possible that is 17:22:46 we should probably head back to meeting land and go to the next ticket 17:22:46 jberkus Assume there was a FAH-Docker and a FAH-CRIO spin. RelEng would not necessarily have to deal with CRIO, right? 17:23:14 yeah i don't think we can *decide* anything now, but we're going to have to keep discussing this for a while, and this was a good discussion i think 17:23:28 +1 17:23:32 yah, and I have stuff for Open Floor 17:23:41 #topic 363 Overhaul list of members, Quorum Rules 17:23:46 #link https://pagure.io/atomic-wg/issue/363 17:24:01 walters: got postponed amidst f27 release 17:24:15 while we are on this topic can we look at https://pagure.io/atomic-wg/issue/377 and choose to just dup that in favor of this ticket or not 17:24:37 looks like it's similar to me 17:24:52 basically 'majority rules a vote' 17:24:57 how do we decide on that ticket? vote or not? ;) 17:25:04 :) 17:25:20 heh 17:25:35 cage fighting 17:25:47 can we get to F27 publications? 17:25:54 I really need to address thesebefore the meeting ends 17:26:32 walters: ? 17:26:48 there is one ticket opened by giussepe 17:26:53 that would be good to discuss 17:26:53 sorry yes, we can context switch to that now? 17:27:11 anyone object to people editing the wiki to add themselves to the WG like ashcrow ? 17:27:30 or we could maybe not publish anything for the f27 release. that's OK I guess, I'm on PTO anyway\ 17:27:39 #topic f27 publications 17:27:58 ok, this is the tentative schedules 17:27:59 https://gist.github.com/jberkus/1eb55b7d85e2d584f7c7c6138776c2d1 17:28:18 except that there's issues with 3 of those so I want to check on them 17:28:27 jbrooks: where are we on Kube containers? 17:28:38 jberkus, They're coming 17:28:46 I think we'll be good to pub today 17:28:55 maxamillion is hooking us up 17:29:00 schedule looks good to me 17:29:06 +1 17:29:10 miabbott: did point out an issue in cockpit he might want to get addressed 17:29:15 before he publishes 17:29:23 maxamillion++ 17:29:24 jbrooks: Karma for maxamillion changed to 4 (for the f27 release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:29:24 ksinny: how does your multi-arch blog post sync with the fedora magazine article? 17:29:33 dustymabe: yeah, that was issue #3 17:29:56 got it handled 17:29:59 jberkus: multi-arch post on Fedora Magazine will be publish tomorrow at 8Am UTC 17:30:15 whatever anyone needs, just ping me this week ... it's GA release week so things are going to be hectic and I understand 17:30:27 apologies if I've been snippy ... it's been a rough few days 17:30:28 should we try to finish the remaining meeting tickets? 17:30:39 ksinny: how does the content for the two compare? 17:30:45 walters: is giuseppe around? 17:30:52 jberkus: conents are same 17:30:57 ksinny: can you stay for 10min after the meeting? 17:30:57 giuseppe: how urgent is the ticket you opened? 17:31:03 jberkus: yeah, I will 17:31:14 dustymabe, it depends also on getting the CRI-O image released 17:31:15 ok, done with publications 17:31:26 we want to use it with the Openshift installer 17:31:30 let's just discuss it real quick 17:31:48 which is still using an image on my personal docker.io 17:31:56 #topic Fedora version agnostic location for container images 17:32:00 #link https://pagure.io/atomic-wg/issue/376 17:32:15 so the way I read this was we just want images that arent' tied to f25/f26/etc 17:32:35 but can just use latest/etcd instead of f26/etcd 17:32:40 yes, it is enough to not have the f25/f26/f27 in the image name 17:32:47 I think modularity will give us this for free? 17:32:54 Once that's in action 17:33:02 i'm +1 for that but I yield to maxamillion 17:33:10 jbrooks: yah, but I don't think we want to wait for that 17:33:12 jbrooks, that is a very interesting question 17:33:19 it could even be a /latest/ that points to whatever is the last release, f27 now 17:33:29 jberkus, yes, but OTOH we should probably check what they're thinking for a naming scheme for containers 17:34:13 Whether it's changes to flibs or waiting for modularity, I think there'll be a wait 17:34:21 walters: wouldn't hurt, do you think you can get a clear answer from someone? when I asked Langdon at Flock, he gave me a big shrug 17:34:43 jberkus: i never shrug 17:34:44 i have no idea of the status of containers-from-modules 17:34:55 jberkus: he does say "meh" a lot 17:34:58 This is the sort of thing that we can accomplish more simply in docker.io/projectatomic 17:35:03 For now 17:35:07 dustymabe: point 17:35:22 i mean server-side-containers, i personally do plan to try to convert some of my "pet containers" to use modules but that's client side and has no relation to server-side images 17:36:06 currently, we are waiting on base-images showing up in r.fp.o.. then we will be producing images based on modules.. mostly with help from eliska 17:36:11 so if we're proposing /latest/...that seems like it should be an easy patch for releng? 17:36:27 walters: i'd like to not assume and let maxamillion weigh in 17:36:29 i would actually be very curious *where* such a patch would be made 17:36:31 containers-from-modules is likely to need some level of design for how it's going to affect FLIBS ... arbitrary branching isn't something I've taken into consideration for FLIBS because it wasn't a thing until a few months ago 17:37:11 yeah, the idea of /latest/ would be pretty easy to maintain for the sync operation to the registries 17:37:12 maxamillion: what do you think about registry.fedoraproject.org/latest -> registry.fedoraproject.org/f26 ? 17:37:24 dustymabe: I think f26 is wrong, but the idea is fine 17:37:29 :) 17:37:44 so drill down just a little deeper on this one 17:38:08 if I build etcd in f27 then /latest/etcd -> /f27/etcd 17:38:20 and httpd didn't have an f27 version yet 17:38:31 would /latest/httpd -> /f27/httpd ? 17:38:34 it would not 17:38:39 i.e. is it global or not? 17:38:46 let's do 2-3 more mins on this then i'll call it, and let's do the members/voting one first thing next time, and please add comments to the ticket for that one 17:38:48 global would probably be easier to implement 17:39:06 dustymabe: not the way I was thinking of it, global would actually be harder 17:39:06 ok /me quiet now 17:39:12 maxamillion: +1 17:39:19 maxamillion: can you update the ticket ? 17:39:29 I don't know of anyone who is -1 for this 17:39:41 sure thing 17:39:43 +1 17:39:51