14:00:46 <nils> #startmeeting modularity_wg
14:00:46 <zodbot> Meeting started Tue Jul 25 14:00:46 2017 UTC.  The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:46 <zodbot> The meeting name has been set to 'modularity_wg'
14:00:46 <nils> #meetingtopic Meeting of the Modularity Working Group (once every two weeks)
14:00:46 <nils> #chair dgilmore langdon tflink
14:00:46 <zodbot> Current chairs: dgilmore langdon nils tflink
14:00:59 <nils> #topic Roll Call
14:01:01 <langdon> .hello langdon
14:01:02 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
14:01:03 <nils> .hello nphilipp
14:01:05 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
14:01:18 <jkurik_mtg> .hello2
14:01:18 <ignatenkobrain> .hello ignatenkobrain
14:01:19 <zodbot> jkurik_mtg: Sorry, but you don't exist
14:01:22 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
14:01:28 <contyk> o/
14:01:29 <ignatenkobrain> jkurik: :D
14:01:30 <jkurik> .hello2
14:01:32 <contyk> .hello psabata
14:01:35 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
14:01:37 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:01:43 <tflink> .hello tflink
14:01:50 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
14:02:06 <langdon> .hello2 you too jkurik
14:02:07 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
14:02:16 * tflink has another meeting scheduled right now and is going to be semi-lurking, is going to get it rescheduled going forward
14:02:24 <jkurik> hi langdon and everybody here
14:02:48 <sgallagh> .hello sgallagh
14:02:49 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:03:16 <nils> #topic Agenda
14:03:30 <nils> Does anybody have anything for the agenda? The board is empty.
14:03:41 <langdon> \o/ boltron!
14:03:58 <nils> #info Boltron is out!
14:04:08 <sgallagh> nils: There's a Server SIG meeting later today where we're going to have a post-mortem on Boltron and a strategize where to go in F27 and F28
14:04:36 <nils> then let's get at it...
14:04:41 <nils> #topic Boltron is out!
14:05:00 <nils> langdon, I guess that's yours :)
14:05:11 <langdon> oops.. wasn't look
14:05:12 <langdon> ing
14:05:21 <nils> you brought it up :P
14:05:31 <langdon> yeah.. need more coffee
14:05:34 <contyk> the server wg meetings are so late
14:05:35 <langdon> #link https://fedoramagazine.org/announcing-boltron/
14:05:38 <langdon> ha
14:05:46 <nils> 👍
14:06:05 <langdon> so.. we shipped it... it has some issues.. but it mostly works.. and we forgot some pretty important things for the qcow
14:06:24 <langdon> but.. we did prove that the whole thing builds in the infrastructure and we can get the whole thing shipped
14:06:29 <langdon> with only a bit of pain
14:06:37 <contyk> mmcgrath made it work yesterday; I assume he used the non-modular cloud-init
14:06:48 <langdon> contyk, nice
14:07:13 <asamalik> .hello asamalik
14:07:14 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:07:14 <langdon> qcow is missing cloud-init, sudo, and network-manager so.. that's fun
14:07:45 <langdon> but.. we should have daily builds RSN, which will show off these kinds of issues a lot faster
14:07:57 <langdon> i guess that is all i have on this.. unless people have qs
14:08:30 <contyk> do we have a specific plan for dnf in f27?
14:08:54 <langdon> ohh.. sorry.. and i am working on a note to devel-announce
14:08:59 <contyk> will it include everything we want or will it be just a limited functionality?
14:09:10 <contyk> because dnf in boltron is... well
14:09:13 <langdon> contyk, the hope is everything.. but we need to confirm with dnf
14:09:24 <nils> contyk, doesn't sound as if you mean that it is well :)
14:09:37 <contyk> ;)
14:10:27 <nils> sgallagh, do you want to #info the later meeting?
14:10:46 <sgallagh> nils: I was actually thinking it should be a #topic
14:10:56 <sgallagh> So we can decide what we want to propose
14:11:00 <nils> sgallagh, aah, sorry, my bad
14:11:17 <jkurik> contyk: I would suggest to check with dmach as he is maintaining the roadmap for DNF
14:12:02 <nils> I guess we're through with this one
14:12:09 <contyk> jkurik: I was hoping langdon would know :)
14:12:20 <contyk> I can add one more note
14:12:33 <contyk> langdon said we would be having new builds soon
14:13:03 <contyk> mbs is going to be configured to create s390x tags this week and we should have modulemds for platform and host soon too
14:13:05 <ttomecek> .hello ttomecek
14:13:06 <zodbot> ttomecek: ttomecek 'Tomas Tomecek' <ttomecek@redhat.com>
14:13:16 <contyk> I would like to start building these modules this week
14:13:17 <langdon> contyk, ohh right..
14:13:33 <langdon> and the new builds would be "boltron-rawhide" or something
14:13:44 <langdon> based on an f27 core
14:13:46 <contyk> if you insist on that name :)
14:14:10 <contyk> but yet, we're operating on (frozen) rawhide atm
14:14:27 <langdon> i just made it up..
14:14:39 <langdon> i would like to just call it f27 .. but.. you know
14:14:42 <sgallagh> To be clear "frozen rawhide" == "a snapshot of rawhide"?
14:14:58 <contyk> yes, a snapshot of rawhide plus cherry picked updates
14:15:43 <langdon> well.. not really a snapshot, right? just only updates when the h&p is rebuilt
14:15:50 <contyk> nope
14:15:53 <contyk> it's a snapshot
14:15:58 <langdon> why not follow rawhide?
14:16:08 <contyk> because we wouldn't be able to build anything
14:16:26 <contyk> it changes too much; following branches is fine for some use cases, not really for ours
14:16:32 <sgallagh> langdon: The rate of churn is ridiculous
14:16:42 <nils> langdon, any package FTFBS would kill the module build
14:16:46 <nils> for instance
14:17:16 <contyk> just like during f26 development, we will be rebasing the snapshot every now and then
14:17:39 <contyk> but we would like to stabilize it first
14:17:48 <langdon> we should probbably be re-snapshotting pretty regularly though..
14:18:27 <contyk> it's easier once you have a stable base
14:18:32 <langdon> sure
14:18:45 <contyk> regular as in "every Monday" rebases don't help anything
14:18:54 <contyk> quite the opposite
14:19:28 <sgallagh> What we actually need is a stable base and then scripts that try to rebase each package individually on a constant basis and yell loudly when it stops building
14:19:33 <langdon> contyk, sure.. but at some point soon, it should probably start.. maybe once there is some continuous testing in place
14:19:40 <nils> sgallagh, +1
14:19:41 <langdon> sgallagh, yeah
14:19:42 <sgallagh> (With some handwavy logic for handling things that have to update together)
14:19:54 <contyk> yes, CI is the answer
14:19:57 <contyk> something we still lack
14:20:59 <contyk> langdon: what you were thinking originally, that we just reference rawhide, will apply to atomic host
14:21:11 <contyk> langdon: but that's yet to be discussed with atomic wg
14:21:47 <contyk> anyway, that's all I wanted to add :)
14:21:54 <langdon> well.. actually, i thought you had some CI going already.. but, yeah.. i guess i was thinking it would at least be rebasing on rawhide "every week" (or sometihng)
14:22:09 <langdon> but.. im not married to it.. and i see your point
14:22:22 <langdon> but i would really like the CI to be in place to make this less of a concern
14:22:26 <contyk> langdon: we have a few tests but most of the package level tests rot in upstreamfirst pagure
14:22:37 <langdon> right
14:22:39 <contyk> langdon: the tests we have for base-runtime are... well, for base-runtime
14:22:44 <langdon> ha
14:22:46 <contyk> it will need to be adapted
14:22:56 <contyk> and it only tests a small subset of the functionality
14:23:10 <nils> langdon, if we had "scratch-builds" for modules, rebuilding against brand new would be more feasible I guess
14:23:16 <contyk> freshmaker isn't available either
14:23:44 <contyk> it doesn't need to be a scratch build
14:23:59 <contyk> we use PDC flags to decide whether the module build is fine or could be ignored
14:24:12 <langdon> yeah.. whihc makes a lot more sense to me than scratch builds
14:24:18 <contyk> yeah
14:24:20 <ttomecek> contyk, btw, any updates on the 'container-runtime in platform module'? I got asked by docker maintainers about container-runtime module.
14:24:22 <nils> tell me the difference :P
14:24:33 <langdon> would like to see cleanup in koji for pdc-says-this-build-stinks though.. which i don't think is in the works
14:24:42 <contyk> ttomecek: you suggested we should include ocid only, right?
14:25:00 <contyk> ttomecek: docker could live in a standalone module
14:25:04 <langdon> nils, no difference to a human.. except that the human doesn't have to decide
14:25:09 <ttomecek> contyk, no, runc, ocid doesn't exist, it's cri-o, and it's meant for kubernetes *only*
14:25:11 <contyk> ttomecek: that's part of a big module plan we need to put together :)
14:25:24 <contyk> ttomecek: ah, ok, runc
14:25:29 <langdon> ttomecek, really? cri-o isn't for "my laptop"?
14:25:43 * langdon must have missed that
14:25:50 <nils> langdon, I think the main difference could be that you can do scratch-builds "from local source" i.e. doesn't have to be in dist-git
14:25:50 <contyk> ttomecek: would appreciate some input in fedora-modularity/hp on this matter, thank you
14:26:00 <ttomecek> contyk, I agree with that (having docker in a separate module, I kind-of asked docker maintainers if they wanna start working on it, but since we don't have guidelines in-place yet and only modularity wg can build modules...)
14:26:07 <langdon> nils, ahh .. "mbs-build local" :)
14:26:13 <nils> langdon, no
14:26:25 <nils> langdon, "fedpkg local" vs. "fedpkg build --scratch"
14:26:35 <nils> scratch builds are in official infra
14:26:45 <langdon> ttomecek, contyk  sorry.. not sure i follow.. separate from what? container-runtime module? or h&p?
14:26:46 <contyk> nils: that's not really doable and you know why
14:27:02 <contyk> nils: also for CI real builds are better
14:27:15 <contyk> nils: you can GC them if they're bad or actually ship them if they are fine
14:27:25 <contyk> nils: you cannot do that with scratch builds; you need to build it again
14:27:30 <langdon> like do you guys envision a docker-module and a runc-module? or a container-runtime that has different install profiles? and/or in h&p? or on h&p?
14:27:42 <ttomecek> langdon, sorry, can't find any reference to support my argument
14:27:45 <contyk> langdon, ttomecek: docker separate from container runtime in platform
14:27:49 <nils> contyk, yeah, there's no way to "download a module" when there aren't any artifacts yet
14:28:15 <langdon> ttomecek, ha
14:28:33 <nils> But I guess we've strayed from the topic pretty far already, so let's get on with sgallagh's?
14:28:35 <contyk> langdon: the idea was that we would use runc to run our standard module containers; this would be used by dnf somehow, perhaps, and would be in platform to allow direct installation of container modules
14:28:50 <nils> And table container-related discussion for afterwards`
14:28:51 <nils> ?
14:29:01 <contyk> langdon: and then there would be the full docker, in a module because it's developed at a much faster pace
14:29:09 <ignatenkobrain> contyk: somehow ;)
14:29:12 <contyk> langdon: runc is supposed to be stable
14:29:21 * ttomecek is sorry for distraction
14:29:22 <langdon> ahh ok.. i see.. but, per nils, maybe we should "re-#topic"?
14:29:31 * langdon holds breath on runc
14:29:35 <ignatenkobrain> I feel that we will need "atomic" to be somewhere for DNF supporting containers
14:29:36 <contyk> +1
14:29:40 <ignatenkobrain> but I would rather avoid this
14:29:43 <ttomecek> contyk, I'm writing a todo for myself to start the discussion
14:30:02 <nils> ok, let's continue this after sgallagh's topic
14:30:07 <nils> #topic Server SIG meeting later today
14:30:10 <nils> #chair sgallagh
14:30:10 <zodbot> Current chairs: dgilmore langdon nils sgallagh tflink
14:30:53 * sgallagh looks up
14:31:08 <sgallagh> First, to reiterate: great job on Boltron, folks!
14:31:30 <langdon> +1
14:32:03 <sgallagh> It has been suggested to me that we should seriously consider (starting with F27) replacing the existing Server Edition artifacts with those produced (and using) modularity features.
14:32:23 <sgallagh> So, using that as a straw-man: let's try to figure out what we would need to do to get there.
14:32:53 <sgallagh> #info Straw-man proposal: Fedora 27 Server Edition is modular-only  -- How do we get there?
14:33:09 <langdon> yeah.. im starting a doc to try to collect everything i know about.. /me doesn't actually have a link yet
14:33:27 <langdon> and contyk & i were talking about a list of the modules we expect
14:33:31 <contyk> langdon: "From the Big Bang to Modular Server"
14:33:37 <langdon> right!
14:33:39 <sgallagh> Heh
14:33:43 <langdon> should be a one-pager!
14:33:55 <sgallagh> contyk: "Intelligent Design of Fedora Server"
14:34:00 <contyk> :)
14:34:21 <contyk> later we can add <s></s> around the first word
14:34:36 <sgallagh> Joking aside, I think the major hurdle we would have to get over with the Server SIG in general will be feature parity.
14:34:50 <nils> sgallagh, to be fair, what we did seems rather evolutionary to me
14:34:52 <sgallagh> There are a few aspects of Fedora Server that we will *really* not want to regress.
14:35:13 <sgallagh> Some of these will be easy, others... complicated.
14:35:27 <langdon> yeah.. i think we need that punch list.. and/or we can address that with prioritization
14:35:30 <sgallagh> (Shall I start with the easy stuff or just drop the Big One now?)
14:35:56 <contyk> sgallagh: would you consider not having all of the Fedora packages available being an issue?
14:35:57 <langdon> sgallagh, big one!
14:36:17 <sgallagh> contyk: Sorry, can you rephrase that? "Fedora packages" starts to get overloaded.
14:36:33 <contyk> sgallagh: those ~20k source packages we have in Fedora today
14:36:46 <contyk> sgallagh: nowadays you can install anything you want on your server installation
14:37:00 <nils> contyk, WDYM, nowadays?
14:37:15 <contyk> nils: in a non-modular release
14:37:19 <sgallagh> contyk: We discussed that in a previous Server meeting. We're okay with *not* having access to everything.
14:37:27 <contyk> sgallagh: ok, thanks
14:37:38 <sgallagh> We're fine with shipping a core set of stuff and adding to it with new modules as we go
14:37:51 <sgallagh> Our user-base is currently small enough that we're willing to take the risk
14:37:55 <nils> contyk, I don't see that changing, do you? If "anything you want" != "in any artifact you want" at least.
14:38:15 <contyk> nils: it will change; you will only have access to modularized content
14:38:25 <sgallagh> The Big One of course is FreeIPA, which is currently Fedora Server Edition's flagship component.
14:38:39 <nils> contyk, yeah, but all content will be modularized... eventually ;)
14:38:53 <contyk> nils: is that an action for nils?
14:38:55 <sgallagh> nils: Right, and as I said the Server SIG discussed this
14:39:10 <sgallagh> And we're okay with shipping without everything being modularized first.
14:39:23 <nils> contyk, heh, I'm sure the powers that be want to send me out "in the jungle for months on end" :P
14:39:27 <sgallagh> We are fine as long as we don't regress any of the features we've advertised previously.
14:39:41 <sgallagh> Which mostly boils down to "FreeIPA", "PostgreSQL" and "Cockpit"
14:39:52 <sgallagh> Oh, and support for being managed by Ansible
14:40:32 <ignatenkobrain> that's getting more complicated
14:40:34 <langdon> sgallagh, do you foresee freeipa as module-rpms or as containers?
14:40:48 <ignatenkobrain> because ansible's DNF cant manage modules
14:41:06 <sgallagh> langdon: That's a great question...
14:41:16 <ignatenkobrain> and at this point I don't think there will be way of managing modules from DNF API in f27 (probably only CLI support)
14:41:21 * nils is not sure if he likes the sound of "ansible's DNF"...
14:41:47 <ignatenkobrain> nils: obviously I meant DNF plugin for ansible ;)
14:41:50 <sgallagh> (We will also have to discuss whether we want to support an upgrade path or agree that fresh install is the only way to go from F26->F27 Server)
14:42:10 <langdon> ignatenkobrain, well.. priorities change.. we can add it to the list and see what can be committed too
14:42:31 <langdon> sgallagh, i know mattdm is really pushing for upgrade..
14:42:33 <sgallagh> langdon: On paper, I think the container strategy is better for FreeIPA... but I know enough about the internals to be concerned that it probably wouldn't happen in time for F27.
14:42:46 * ignatenkobrain is just saying what is on DNF's team radar nowadays and raising some concerns ;)
14:42:55 <langdon> sgallagh,  gotcha i thought it had "been done" already
14:42:57 <contyk> not sure how the upgrade would work
14:42:58 <sgallagh> langdon: That's all well and good, but I think we may want to accept this one-time cost for Fedora at least.
14:43:17 <sgallagh> langdon: Well, if we wanted it fully containerized, there needs to be a concerted effort to do so
14:43:21 <langdon> contyk, sgallagh re:upgrade agreed.. but we should at least think about it
14:43:45 <langdon> sgallagh, yeah.. i was just saying, i thought that had been done.. but i am apparently mistaken
14:44:11 <sgallagh> langdon: A FreeIPA container exists as a PoC... but it's a monster container with the whole shabang in a single instance.
14:44:16 <sgallagh> It's basically a VM
14:44:24 <sgallagh> And it's out of date, last I heard
14:45:03 <sgallagh> Realistically, it needs to be divided up into individual services, which means breaking some assumptions in the code about pieces co-existing on the same machine.
14:45:23 <sgallagh> s/machine/filesystem/
14:45:30 <langdon> got it
14:45:31 <nils> contyk, the mapping of "no modules" to whatever modules are available by then that have the same content will be tricky, yes
14:46:43 <sgallagh> nils: Well, we could always have an "upgrade" profile on every module that automatically enabled *nothing*. Then on upgrade just turn on all modules :-D
14:46:55 <nils> sgallagh, hue
14:47:01 <langdon> sgallagh, or it could just rm -rf /
14:47:04 <sgallagh> hue?
14:47:19 <nils> sgallagh, "heh" with an accent :D
14:47:24 <sgallagh> haha
14:48:02 <sgallagh> Honestly, while upgrades would be *nice*, I think it might be worthwhile to look at that for F28 rather than F27
14:48:05 <langdon> ok.. devel-announce email away
14:48:16 <sgallagh> (So we support them for the F26->F28 jump)
14:48:28 <contyk> https://imgflip.com/i/1t1or0
14:48:36 * langdon lied.. source address the wrong one :(
14:49:40 <nils> sgallagh, I think we should offer some kind of upgrade path eventually, not necessarily for f27
14:50:09 <sgallagh> langdon: Let me get back to your FreeIPA question: where were you going with the rpms-vs-containers question?
14:50:09 * langdon going to print that pic and hang it on the wall
14:50:26 <nils> sgallagh, so we're done for SIG tonight?
14:50:34 <sgallagh> nils: Not yet.
14:50:37 <langdon> just that if it is a container.. it is easier to build/deliver than as rpms
14:50:44 <langdon> assuming that the containers were done
14:50:46 <sgallagh> I'd like to leave this meeting with a clear idea of what we're proposing
14:50:54 <sgallagh> langdon: but harder to upgrade
14:50:58 * nils is desperately looking where to wedge in the #topic boundary
14:51:21 <contyk> langdon: so you wouldn't want to build the freeipa container from modules?
14:51:22 <sgallagh> langdon: Do we have examples of container-based modules yet?
14:51:33 <sgallagh> Or module-based containers?
14:51:34 <langdon> nils, i think sgallagh wants a list of what the m-wg should propose to the s-wg at the meeting today/tonight
14:51:42 <nils> langdon, ah
14:51:43 <sgallagh> langdon: Exactly
14:51:50 <langdon> sgallagh, yes.. a bunch
14:51:59 <sgallagh> ok
14:52:01 <nils> module-based containers that is
14:52:06 <langdon> ohh.. sorry.. unclear
14:52:10 <contyk> that workflow isn't automated, unfortunately
14:52:13 <nils> I don't think we do it the other way around :)
14:52:32 <langdon> nils, right.. not yet.. and it will require negotiation yet
14:52:48 <sgallagh> nils: I guess my question is, could I do "dnf module-install postgresql" and have that pull down a container and run it?
14:52:58 <contyk> you build rpms in a module and then create (manually) a Dockerfile in the docker/ namespace that installs your content on top of a modular base image
14:53:00 <sgallagh> (And *should* that be possible?)
14:53:01 <langdon> devel-announce is always moderated, right?
14:53:18 <contyk> sgallagh: it should but it isn't
14:53:20 <sgallagh> langdon: yes
14:53:29 <langdon> sgallagh, i want that .. but dnf and atomic haven't agreed to it yet :)
14:53:30 <sgallagh> contyk: Well, I'm not certain about that.
14:53:49 <sgallagh> I wonder if we actually want to do that or if we should be using openshift/minishift in such cases
14:54:01 <sgallagh> sorry, not minishift. Ignore that part.
14:54:17 <langdon> sgallagh, i think it depends on the container(s).. freeipa? probably.. bind? probably not
14:54:36 <sgallagh> langdon: Probably not... what?
14:54:54 <sgallagh> I asked an either/or question, so I'm unclear which side you're answering :)
14:54:55 <langdon> sgallagh, two examples.. one that might want openshift and one that probably wouldn't
14:56:00 <sgallagh> I'm not sure that there's a story to be told for any container that isn't manageable by OpenShift/Kubernetes
14:56:01 <langdon> sgallagh, does that make more sense?
14:56:13 <langdon> sgallagh, ohh.. was that what you meant?
14:56:29 <langdon> i thought you meant "a app that required openshift when it was installed"
14:56:47 <sgallagh> Well, those might or might not be tightly-coupled statements :)
14:57:13 <langdon> ha
14:57:46 <sgallagh> langdon: Honestly, I kind of foresee a world where every system is an OpenShift node right from install-time.
14:57:51 <langdon> sgallagh, do you want to take a stab at the "list of things for server wg"? we are running out of time
14:57:58 <langdon> sgallagh, me too
14:58:08 <sgallagh> Some machines might be a self-contained cluster, others part of a mesh.
14:58:12 <langdon> i think modularity is the first steps on that path
14:58:41 <sgallagh> langdon: Well, if that's our long-term vision, then we should make sure to ask the right questions along the way.
14:58:57 <sgallagh> i.e. "Does this plan advance our goal?"
14:59:41 <langdon> well.. my long term vision is more "service based functionality" with less reliance on "host of that service" .. every computer as an openshift node is one path for that.. or at least part of a path
15:00:00 <sgallagh> langdon: For today, shall we settle for "Propose that F27 ship only the modular compose *concurrent with the Workstation release*"?
15:00:21 <sgallagh> And see what the SIG comes back with as requirements for reaching such a goal?
15:00:23 <langdon> i don't understand your part in *s
15:00:37 <langdon> like at the same time as wkstn? in case it slips?
15:00:38 <sgallagh> langdon: Unlike Boltron, it would have to ship on release day
15:00:43 <langdon> right
15:00:44 <langdon> yes
15:00:58 <sgallagh> Though I'm really concerned by the time available to F27
15:01:00 <langdon> but it is the same release day as the normal compose :)
15:01:12 <langdon> as contyk says.. why? we still have *5* weeks!
15:01:18 <sgallagh> langdon: Yes, I was trying to be more explicit
15:01:36 <sgallagh> langdon: We still don't even have a mass-rebuild ;_;
15:01:39 <langdon> sgallagh, yeah.. i thought your phrasing was fine
15:02:00 <sgallagh> Anyway, let's go with fact-finding for today's meeting
15:02:06 * langdon notes once modularity is all the way implemented we will be doing them every day..or not at all.. depending on perspective
15:02:26 <langdon> them = mass rebuilds
15:02:36 <sgallagh> #info Modularity WG will propose that Server Edition ships only modular-composed artifacts in Fedora 27 on the same schedule as other official releases
15:02:58 <sgallagh> OK, nils /#topic
15:02:59 <langdon> sgallagh, just a note.. we had the change approved already
15:03:13 <sgallagh> Which Change?
15:03:21 <langdon> like this is already the stated plan.. as of the server meeting a few weeks ago
15:03:29 * langdon digs
15:03:51 <langdon> https://fedoraproject.org/wiki/Changes/Modular_Server < i think
15:03:56 <langdon> there are 3 with similar names
15:04:09 <langdon> yeah.. thats it
15:05:59 <nils> OK, given that we're overtime, do you guys talk about the dnf<->container thing from earlier now? Or table it for next time?
15:06:27 <sgallagh> ok
15:07:17 <langdon> nils, maybe in #f-m?
15:07:36 <nils> langdon, sure, we can discuss anything in #fedora-modularity :)
15:07:41 <langdon> ha
15:07:51 <langdon> but.. let's end meeting? sgallagh ?
15:07:58 <sgallagh> I'm done
15:08:01 <nils> In that case, thanks everybody!
15:08:04 <nils> #endmeeting