16:02:46 <dgilmore> #startmeeting FESCO (2017-05-12)
16:02:46 <zodbot> Meeting started Fri May 12 16:02:46 2017 UTC.  The chair is dgilmore. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:46 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:02:46 <zodbot> The meeting name has been set to 'fesco_(2017-05-12)'
16:02:46 <dgilmore> #meetingname fesco
16:02:46 <dgilmore> #chair maxamillion dgilmore jwb nirik jforbes jsmith kalev sgallagh Rathann
16:02:46 <zodbot> The meeting name has been set to 'fesco'
16:02:46 <zodbot> Current chairs: Rathann dgilmore jforbes jsmith jwb kalev maxamillion nirik sgallagh
16:02:49 <dgilmore> #topic init process
16:02:59 <kalev> morning
16:03:04 <jforbes> .hello jforbes
16:03:04 <maxamillion> .hello maxamillion
16:03:04 <sgallagh> .hello sgallagh
16:03:04 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
16:03:07 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
16:03:08 <nirik> morning
16:03:10 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:03:24 * threebean waves
16:03:50 <dgilmore> lets get moving
16:04:14 <jkaluza__> .hello jkaluza
16:04:15 <zodbot> jkaluza__: jkaluza 'Jan Kaluža' <jkaluza@redhat.com>
16:04:20 <contyk> .hello psabata
16:04:25 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
16:05:06 <dgilmore> #topic #1705 MBS and the module-build-macros package.
16:05:07 <dgilmore> .fesco 1705
16:05:07 <dgilmore> https://pagure.io/fesco/issue/1705
16:05:08 <zodbot> dgilmore: Issue #1705: MBS and the module-build-macros package. - fesco - Pagure - https://pagure.io/fesco/issue/1705
16:05:36 <dgilmore> so not very well it seems we have a policy that everything has to be build from git
16:05:52 <dgilmore> by not very well I mean its not documented well
16:05:55 * langdon lurks
16:05:58 <sgallagh> My reading of this is that the module-build-macros package is an internal implementation detail and the fact that it happens to exist as an RPM is a bit of interesting trivia.
16:06:06 <dgilmore> that all came out wrong
16:06:12 <nirik> I did find some mention in the packaging policy... but yeah...
16:06:16 <kalev> can fesco decide to do an exception here for this?
16:06:29 <kalev> seems like the easiest way to solve the issue for f26 for now
16:06:39 <dgilmore> kalev: fesco can decide on any technical decision
16:07:05 <sgallagh> kalev: I think it's fair to hear rel-eng's position before we make any decisions, though :)
16:07:06 <dgilmore> I have concerns over building from srpm
16:07:06 <maxamillion> nirik: oh? I didn't know that
16:07:27 <dgilmore> but some of it may be that I am not informed enough on how modules are supposed to work
16:07:33 <maxamillion> dgilmore: what concerns? (I'm kind of on the fence about this stuff, curious on your thoughts)
16:07:53 <dgilmore> maxamillion: well it takes away the single source of truth
16:08:10 <dgilmore> you can not go to once place to fine all the sources
16:08:21 <dgilmore> you have to know that this thing is off on the side
16:08:33 <sgallagh> dgilmore: Well, it's autogenerated from the sources we do have, though.
16:09:02 <dgilmore> I also think the effort to make a branch in git for the package and pushing, it and building from it is small
16:09:03 <sgallagh> How is it meaningfully different from libtool scripts, for example?
16:09:24 <dgilmore> sgallagh: everything is contained in the build environment
16:09:32 <Rathann> hello, sorry for being late
16:09:36 <maxamillion> Rathann: welcome
16:09:38 <dgilmore> sgallagh: and all teh sources can resolve back to dist git commits
16:10:07 <jkaluza__> are we deciding about f26 here, or generally about MBS?
16:10:22 <dgilmore> jkaluza__: neither right now
16:10:28 <sgallagh> dgilmore: Well, all of the sources here can resolve back to dist-git commits also. It's just a little less easy to spot.
16:10:33 <dgilmore> we are having a discussion about building from srpm
16:10:46 <dgilmore> sgallagh: not really
16:10:56 <jforbes> Right, looking at the linked git tree base-runtime.yaml, it appears all git tags are listed there
16:10:58 <dgilmore> sgallagh: there is no spec in the module repo
16:11:35 <maxamillion> jforbes: +
16:11:37 <maxamillion> +1 *
16:11:45 <dgilmore> how you get from the base-runtime.yaml to builds is some black box magic
16:12:16 <sgallagh> dgilmore: No more so than `autoreconf` in a spec file...
16:12:24 <jkaluza__> you can say that about koji building from dist-git too
16:12:40 <threebean> jkaluza__: +1
16:12:40 <jkaluza__> it magically generates srpm from dist-git
16:12:55 <kalev> I was just about to say that, this seems more like koji config than actual source that needs versioning
16:13:13 <jforbes> It is, if you don't understand the build process there, but it is well defined and should be reproduceable because every components git reference is there
16:13:35 <dgilmore> sgallagh: you are not making any sense to me right now
16:13:35 <maxamillion> sgallagh: I am curious if there's a good solution to the issue you raised in ticket about the reaping of old content in koji
16:13:40 <sgallagh> dgilmore: So let me ask a different question. We've established that you feel that this is *different* from how other builds happen, but could you explain why you feel this is a *problem*?
16:13:48 <maxamillion> sgallagh: or was that addressed and I just missed it?
16:13:54 <kalev> the rpm has a single generated file in it, a /usr/lib/rpm/macros.d/macros.modules: https://paste.fedoraproject.org/paste/gAd64Fou0ccwIsCvMrsPVF5M1UNdIGYhyRLivL9gydE=
16:14:14 <sgallagh> maxamillion: I was satisfied by the "it can be reproduced perfectly" answer, but maybe I missed something.
16:14:52 <dgilmore> the generated rpm defines the dist tag etc. I am not sure if it defines the fedora macors or what other macros are defined
16:15:07 <maxamillion> sgallagh: ah ok
16:15:09 <maxamillion> sgallagh: +1
16:15:18 <contyk> does it matter what macros it defines?
16:15:26 <maxamillion> sgallagh: I think that satisfies the requirement
16:15:27 <sgallagh> maxamillion: s/reproduced/recreated/ (for clarity)
16:15:28 <jkaluza__> contyk: +1
16:15:29 <dgilmore> sgallagh: its a critical piece of what defines the module, yet it is generated by magic
16:15:31 <maxamillion> sgallagh: right
16:15:39 <threebean> s/magic/software/
16:15:51 <jkaluza__> dgilmore: what is so magic about that?
16:15:53 <dgilmore> all I am saying is that I see no reason for it to live in dist-git as well
16:16:04 <pingou> it's deterministic no? there is no random element in the file?
16:16:21 <contyk> pingou: it's directly generated from content stored in dist-git
16:16:25 <nirik> dgilmore: to live in? or not to live in?
16:16:33 <contyk> pingou: so it's dist-git contents + mbs code
16:16:34 <maxamillion> dgilmore: right, but this is similar to how things like autoconf work isn't it? ... or am I missing something?
16:16:43 <jkaluza__> the problem here is maybe that it is not Koji what generates that
16:16:54 <dgilmore> maxamillion: one critial difference
16:16:56 <langdon> can i put this a different way? basically, in the effort to reuse the existing infrastructure we need to use koji to build modules.. in a greenfield world, we would build directly from the modulemd .. because we are doing reuse we need to generate inputs koji understands.. but .. the modulemd is still the single source of truth
16:17:03 <pingou> contyk: ok thanks
16:17:15 <dgilmore> maxamillion: everything for running autoreconf is inside the buildroot
16:17:21 <dgilmore> and fully tracked
16:17:33 <maxamillion> dgilmore: to be cleear ...  I'm still on the fence and just trying to understand everyone's stance on this while I wade through it all in my head
16:17:38 <dgilmore> where this is something injected into the buildroot from outside
16:18:06 <jkaluza__> from fedora-infra service
16:18:07 <dgilmore> I am not even saying I am 100% against doing it from srpms
16:18:09 <sgallagh> dgilmore: One could argue that this is functionally equivalent to passing a command-line argument to mock.
16:18:11 <jkaluza__> which generates that from dist-git
16:18:12 <threebean> dgilmore: this is the same case for the mock configs, which are generated by kojid.
16:18:18 <dgilmore> just that with what is in place today we really need to
16:18:37 <langdon> just like if we only had a c compiler but want to write code in ruby, we would generate c code then compile and throw away the c sources
16:18:55 <dgilmore> threebean: its not really.
16:19:03 <sgallagh> langdon: That sentence made me sad :(
16:19:10 <langdon> sgallagh, :)
16:19:27 <dgilmore> threebean: you can get an approximation of the buidlroot that is close enough to reproduce with the mock config in the mock package
16:19:45 <dgilmore> threebean: but this is defining critical macros that effect the build
16:20:36 <pingou> but you can get these macros easily yourself, no?
16:20:43 <nirik> I wonder... could modules have a special koji build-srpm task that makes these from git and modulemd?
16:20:48 <dgilmore> pingou: I do not know that
16:20:50 <praiskup> by mock config koji can define critical macros too ...
16:20:50 <nirik> instead of just making a src.rpm and uploading it?
16:20:53 <pingou> (isn't that how modules are built locally?)
16:21:02 <threebean> pingou: yes.
16:21:09 <kalev> nirik: that does sound cleaner
16:21:28 <jkaluza__> if you submit the same dist-git hash and branch to MBS, it will generate the same macros in that rpm
16:21:42 <threebean> nirik: that's an option (which would require a patch to koji)
16:22:00 <threebean> although, I think koji upstream is trying to get out of the business of doing special case things for new content types.
16:22:04 <maxamillion> nirik: that could work, I'm curious what the overhead would be pull that off
16:22:09 <threebean> (which is why we ended up writing a separate service on top of koji in the first place)
16:22:25 <dgilmore> threebean: koji is trying to get out of special casing things
16:22:32 <Rathann> what I don't understand is why switching to keeping module-build-macros package in dist-git requires rebuilding the world
16:22:46 <maxamillion> dgilmore: fair point
16:22:52 <threebean> yes.
16:23:21 <jkaluza__> Rathann: because the current world would be build the "wrong" untrusted way I think
16:23:42 <maxamillion> dgilmore: so if it's the case that we don't want special stuff in koji, then would it make sense to do it the way proposed in the ticket?
16:23:50 <jkaluza__> I mean, it can  be decided of course we will keep the current modules as they are
16:25:06 <dgilmore> maxamillion: it may be we needs some tooling that can make the module macros rpms for us  to inject in
16:25:08 <maxamillion> jkaluza__: I don't follow
16:25:16 <dgilmore> I am not sold on any one action
16:25:34 <contyk> dgilmore: why can't that tooling be mbs itself?
16:25:38 <maxamillion> dgilmore: I'm confused, I thought that's what this was doing?
16:25:42 <contyk> (which is what's happening now)
16:25:43 <dgilmore> just that today we have a requirement that everything be build from a git hash
16:25:50 <dgilmore> and not built from srpm
16:26:11 <dgilmore> if we want to make an exception for this one case thats valid.
16:26:26 <dgilmore> I think there is a lot of unkowns about how it all works
16:26:31 <jkaluza__> maxamillion: we have modules built with module-build-macros built from SRPM for F26. If we decide the current way is not acceptable, we need to decide what to do with them. We may need to rebuild all of them with module-build-macros spec stored in git.
16:26:41 <praiskup> what I see here is not really "spec file in distgit" but rather "file describing how to _generate_ spec file is in dist-git"
16:26:47 <contyk> I think the code is rather trivial
16:26:49 <dgilmore> I have been trying to wrap my head around it more. and I am slowly getting there. but there is not enough time in the day
16:26:54 <praiskup> which is not a problem
16:27:02 <jkaluza__> maxamillion: There is no time for that for F26, thats why I've asked in the beginning if we are talking about f26 or generally about mbs
16:27:23 <maxamillion> jkaluza__: alright
16:27:34 <dgilmore> praiskup: that would take major changes in koji
16:27:48 <pingou> dgilmore: well, in a way, the first step of a build in koji is: build the srpm, then it  builds the rpm itself, so we could see mbs as a substitute to this first step
16:27:54 <kalev> one concern I have with the current approach where the macros come from a rpm vs a koji generated config is that when the macros come from rpm, it seems to need a new buildroot for each build, just to make the macros available for the new build
16:27:55 <Rathann> jkaluza__: could you point to the code that generates the module-build-macros?
16:27:57 <dgilmore> today we can define the command to fetch the sources from lookaside cache
16:27:59 <jkaluza__> maxamillion: technically, we do not have to rebuild all modules for this change, but if we don't trust the modules with modules-build-macros from SRPM, we wil have to do that
16:27:59 <praiskup> dgilmore, the tool "generating" the spec file should be available, so koji can reuse it and allow you to do trivial changes in koji
16:28:01 <kalev> this seems to be a bit of a wasteful approach
16:28:01 <pingou> so instead of having dist-git -> koji (srpm) -> koji (rpm)
16:28:08 <maxamillion> basically as long as there's no way that an arbitrary srpm could be injected mid-stream to circumvent the integrity of the build pipeline, then I think I'm fine with the proposal
16:28:10 <pingou> we have dist-git -> mbs (srpm) -> koji (rpm)
16:28:20 <dgilmore> but there is hardcoded logic in koji that expects that a spec file exists in the checkout
16:28:33 <kalev> what nirik suggested earlier to have koji generate the config and inject it would avoid generating a new buildroot for each macro change
16:28:44 <dgilmore> praiskup: that would require invasive changes in koji
16:28:49 <dgilmore> but its an option
16:30:22 <dgilmore> given where we are in the f26 cycle, I think that any change to behaviour would cause us to not be able to ship any modules
16:30:37 <dgilmore> I would be okay granting an exception for the thinsg already built
16:30:40 <nirik> yeah, we are close to the wire.
16:31:04 <dgilmore> I want us to figure out what is acceptable going forward, get it in place and documented
16:31:39 <maxamillion> dgilmore: +1
16:31:43 <nirik> so should we vote on the exception first? then determine what to do moving forward?
16:31:46 <kalev> dgilmore: good plan
16:31:54 <nirik> or perhaps thats a discussion for another day?
16:32:08 <jforbes> I think that is probably the sane thing to do, given the timeline, they need to be handled separately
16:32:22 <Rathann> could someone point to the code that generates the module-build-macros srpm?
16:32:29 * Rathann can't find it
16:32:33 <threebean> Rathann: yeah, one sec.
16:32:35 <jkaluza__> Rathann: yes, w8...
16:32:51 <jkaluza__> threebean: hm, or do that, I'm not using my laptop, I would have to search for that
16:32:52 <dgilmore> proposal #accept FESCo is okay with the modules built to date being shipped as they are
16:33:03 <sgallagh> +1
16:33:05 <maxamillion> +1
16:33:06 <kalev> +1
16:33:12 <nirik> dgilmore: for how long? just f26?
16:33:15 <jkaluza__> threebean: builder/KojiModuleBuilder.py, get_dist_tag_srpm or something like that
16:33:19 <nirik> or just beta?
16:33:22 <threebean> Rathann: https://pagure.io/fm-orchestrator/blob/master/f/module_build_service/builder/KojiModuleBuilder.py#_121
16:33:40 <dgilmore> nirik: well it depends on us deciding how it should be done
16:33:51 <dgilmore> and giving a timeline for that to be implemented
16:34:09 <nirik> ok. in any case I am +1 for an exception for now.
16:35:21 <dgilmore> for the record, the only reason building from srpm works today is because we had to make the mbs user a koji admin in order to create tags and targets inside of koji
16:35:44 <dgilmore> there is a desire to figure out how to not have mbs user be a admin
16:35:56 <jkaluza__> does other services have koji admin accounts too?
16:35:58 <dgilmore> at which point the current way fo building will start to fail
16:36:07 <Rathann> threebean: thanks
16:36:08 <threebean> jkaluza__: bodhi, for one?
16:36:22 <jkaluza__> I'm curious if there is similar plan for them to not use koji admin
16:36:24 <dgilmore> threebean: I think we removed bodhi from being an admin
16:36:32 <dgilmore> at least we are attempting to
16:36:32 <jkaluza__> great :)
16:36:50 <dgilmore> koji-gc is an admin
16:37:06 <dgilmore> and needs to be to make the calls to delete builds
16:37:27 <dgilmore> but I am +1
16:37:39 <threebean> yeah, all of that depends on implementing a granular acl system in koji..
16:37:42 <threebean> ..which is non-trivial.
16:37:52 <dgilmore> #accept FESCo is okay with the modules built to date being shipped as they are (5:+1 0:0 0:-1)
16:37:53 <nirik> so I'd say we should perhaps work on this out of meeting and come up with a plan when more info is known...
16:38:14 <dgilmore> nirik: I am fine with that
16:38:16 <jkaluza__> threebean: well, I will have to think about that more, if we won't need to create target, I'm not sure what else is left with admin rights
16:38:28 <nirik> ie, talk to koji devs about what they might accept, etc
16:38:41 <pingou> jkaluza__: building from srpm
16:38:41 <dgilmore> jkaluza__: making repos can not be done by user
16:39:24 <kalev> soooo, one thing that is unclear to me is if the mbs builds are allowed to continue as they are for now, or does this decision imply that the builds done _up until now_ are ok but can't continue the way they are?
16:39:58 <threebean> kalev: +1
16:39:59 <Rathann> if I understand correctly, the module-build-macros is different for each module name and version pair and needs to be present in the buildroot
16:40:00 <dgilmore> I think having active discussions and not just file random tickets to lay out the problems with releng and the koji devs would go a long way to making everyones life easier
16:40:05 <Rathann> is that right?
16:40:12 <threebean> Rathann: that's right.
16:40:13 <jkaluza__> Rathann: correct
16:40:30 <Rathann> hm
16:40:34 <dgilmore> kalev: well I think it implies they are okay until we figure out teh right way
16:40:42 <pingou> dgilmore: like the ones from devconf?
16:40:48 <threebean> or the releng irc meetings?
16:41:02 <threebean> or #fedora-releng conversations every other day?
16:41:04 <Rathann> so it's a little bit like a mock config and a little bit like rpm version tag
16:41:21 <dgilmore> threebean: no, like when planning
16:41:46 <dgilmore> threebean: as in make sure that a releng person and a koji dev are in mbs planning meetings
16:42:05 <pingou> do we have enough koji devs for that? :)O
16:42:10 <maxamillion> threebean: dgilmore: how many meetings is that though?
16:42:19 <dgilmore> maxamillion: I have no idea
16:42:41 <maxamillion> dgilmore: I fear it's a lot ... I've seen a lot of modularity + factory 2.0 related meetings floating around
16:42:47 <jkaluza__> threebean: Can we probably send email or something with MBS intentions for next sprint?
16:42:49 <dgilmore> maxamillion: but I like to think that had we been involved that some of teh issues we have hit could have been avoided
16:42:51 <jkaluza__> threebean: Like every sprint
16:43:05 <maxamillion> dgilmore: very well could have
16:43:25 <jkaluza__> threebean: We kind of know what we are going to do, we even have those PR on pagure, it should not be a problem to ping dgilmore or someone from releng to review that what we are doing there is OK for them
16:43:55 <threebean> sure, we can script that up.
16:44:07 <jkaluza__> I mean, most of the PRs these days are done or review by me. I can ask mboddu or others to give their +1 on Koji related things
16:44:09 <langdon> i think the factory team has been doing a pretty good job doing architecture reviews when they get put together.. I think sometimes the details catch us all off guard.. not much to do about that except lots of communication and patience.. this is all new stuff..
16:44:32 <Rathann> I'm not convinced if an autogenerated macros package is the best way of providing module name and version for a module build
16:44:46 <Rathann> this feels like it should be part of the build system itself
16:44:50 * threebean nods
16:45:05 <threebean> Rathann: I think that was our original approach, but the koji devs suggested the current method we're using.
16:45:07 <jkaluza__> Rathann: oh, the module_name and module_version is there only for people to use them from their spec files if they want
16:45:16 <jkaluza__> Rathann: If you mean those macros
16:45:23 <Rathann> jkaluza__: yes I do mean these
16:45:37 <Rathann> so they're not part of MBS "ABI"?
16:45:46 <maxamillion> langdon: I think a lot of it is that there's groups of people with heads down doing work and it's difficult to realistically sync frequently with everyone and still execute on all the work
16:46:02 <jkaluza__> Rathann: they are, but it is not how you define the name of module
16:46:06 <dgilmore> threebean: :(
16:46:07 <langdon> maxamillion, exactly.. i should have put "patience" in all caps ;)
16:46:46 <maxamillion> threebean: oh, the current approach came from the koji devs?
16:47:02 <Rathann> I see
16:47:09 <jkaluza__> Rathann: imagine you have php component (RPM) in a httpd module. In that php.spec, you may want to find out that you are building for httpd module and build something differently
16:47:19 <threebean> yeah.  I think originally we wanted to extend the tag to be able to define the values there.
16:47:26 <maxamillion> threebean: ah, TIL
16:47:46 <maxamillion> alright, so ... is everyone good with this ticket? we good to move on or are there other things to address here?
16:48:20 <jkaluza__> Rathann: feel free to discuss that on #fedora-modularity next week if you have more question/ideas there. I don't want to flood here :)
16:48:40 <Rathann> jkaluza__: right, sorry
16:48:48 * nirik is fine to move on for now.
16:49:06 <maxamillion> nirik: +1
16:49:12 * langdon remembers his idea for #info to zodbot anytime.. to capture "what you should read" from irc channels you don't follow all the time
16:49:32 <jforbes> nirik: +1
16:50:04 * Rathann thinks it'd be better to extend koji to inject arbitrary macros into the buildroot instead of this, but of course this was probably much quicker to implement
16:50:22 <dgilmore> I do not think we are going to get this entirely resolved today
16:50:27 <jkaluza__> Rathann: +1
16:50:31 <dgilmore> and we are at 45 minutes on the topic
16:50:40 <Rathann> right, let's move on
16:50:42 <maxamillion> dgilmore: +1
16:50:49 <kalev> Rathann: I think so too
16:50:56 <Rathann> I'd be +1 to an exception for the current state if one is necessary
16:51:16 <dgilmore> Rathann: good to know
16:51:21 <dgilmore> we did give it one for now
16:51:29 <dgilmore> while we figure out the long term plan
16:51:36 <Rathann> right
16:51:42 <dgilmore> #topic #1706 F26 Boltron & Beta Freeze
16:51:42 <dgilmore> .fesco 1706
16:51:43 <dgilmore> https://pagure.io/fesco/issue/1706
16:51:43 <zodbot> dgilmore: Issue #1706: F26 Boltron & Beta Freeze - fesco - Pagure - https://pagure.io/fesco/issue/1706
16:51:47 <dgilmore> so langdon
16:51:53 <langdon> yep!
16:52:09 <dgilmore> what special things do you think you will need
16:52:20 <dgilmore> and how does it not fit into the current workflows?
16:52:46 <langdon> as jwb pointed out.. hopefully, not much.. i think the biggest worry was not to catch anyone by surprise..
16:53:10 <langdon> and support for changes to kickstarts & pungi configs getting merged.. which we can't do
16:53:20 <maxamillion> yeah, I don't see this causing much issue since it's net new and outside the scope of the official Fedora Release
16:53:31 <dgilmore> #info ticket is informational in nature
16:53:39 <maxamillion> it's not on QA's radar, it's not in the compose, it's not in any mainline koji tags ... etc etc
16:54:03 <langdon> but, strictly speaking, covered by the beta freeze
16:54:05 <dgilmore> langdon: I am still not entirely sure what exactly we are delivering
16:54:13 <dgilmore> outside of some repos with packages in them
16:54:18 <jkaluza__> dgilmore: just to be sure, does that mean I can change pungi-fedora variants-modular.xml after the beta freeze?
16:54:25 <jkaluza__> threebean: ^that's what langond wants, right?
16:54:43 * langdon types slowly
16:54:47 <threebean> yeah - that and other related modularity files in the releng repos.
16:55:00 <jkaluza__> dgilmore: are relengs ok with that?
16:55:06 <nirik> is that stuff marked can-fail or whatever, so it keeps going if those things break?
16:55:08 * jwb joins way late
16:55:08 <dgilmore> jkaluza__: sure
16:55:10 <jwb> sorry, meetings
16:55:16 <jkaluza__> dgilmore: awesome! +1
16:55:22 <langdon> so.. official list of modules included will be there on monday/tuesday.. trying to get the last of it ironed out..
16:55:25 <threebean> nirik: well, it's actually a separate compose.  so yes, in a way.
16:55:45 <contyk> we're delivering a qcow and a docker base image too, hopefully
16:55:52 <langdon> and jkaluza__'s points.. and the kickstarts for brt-base-image and qcow
16:55:56 <contyk> in addiiton to the repo
16:55:57 <threebean> contyk: aiming to do so.
16:56:16 <nirik> threebean: ah, right. ok. If it's not going to break the frozen content, I don't have any objection...
16:56:22 <jkaluza__> hm, if we can change pungi-fedora modular config after tuesday, we could manage to ship even the images
16:56:36 <dgilmore> nirik: its a who;le extra compose we will have to run
16:57:09 <dgilmore> langdon: but without making an anaconda installer we can not make anything else
16:57:10 <threebean> nirik: https://pagure.io/pungi-fedora/blob/f26/f/nightly-modular.sh
16:57:22 <dgilmore> and I have seen no effort yet to enable making an installer
16:57:23 <langdon> contyk is on it!
16:57:24 <threebean> dgilmore: yeah, contyk's team is cranking on that.
16:57:35 <langdon> he is hoping monday
16:57:45 <langdon> and he is here.. so can speak for himself ;)
16:57:57 <jkaluza__> dgilmore: we (or at least I) were just afraid we won't be able to change the pungi-fedora after the freeze
16:58:33 <dgilmore> jkaluza__: all changes should go into rawhide first
16:58:37 <dgilmore> and its never frozen
16:59:13 <dgilmore> when proven moving back is easy and given that its all seperate changing is not impactful on release work
16:59:15 * nirik nods
16:59:25 <jwb> i think the concern is rawhide moves too fast
16:59:30 <jwb> which is why they're using f26
16:59:53 <jwb> f26 is gated.  rawhide has no gating, so it has no mechanism to pre-QA content before it goes into a module, etc
17:00:30 <dgilmore> they are gating the module content by its nature
17:01:14 <contyk> sgallagh is working on the installer module
17:01:27 <contyk> although the way it should be all built is still a bit of a mystery
17:01:34 <sgallagh> (at this very minute, which is why my attention is split)
17:01:45 <contyk> for instance where should the kickstarts referencing the modular compose live? should it be the f26 branch?
17:01:55 <dgilmore> One thing that I have not seen covered is what to do when pulling in newer content
17:02:00 <contyk> do we need the boot image in our compose or can we use the traditional one?
17:02:03 <contyk> things like that
17:02:15 <dgilmore> the workflows for main fedora is very clear, freeze exceptions etc
17:02:35 <jkaluza__> dgilmore: you mean how to get new content into modular f26?
17:02:39 <langdon> dgilmore, i think you are seeing the problems with not having arbitrary branching yet for dist-git.. it is super confusing because dist-git is still release-oriented and modularity is not
17:03:01 <dgilmore> but I wonder how we should handle the case where modules need something newer to fix a bug in modules. what are we to do in the main fedora stream
17:03:14 <dgilmore> langdon: likely
17:04:01 <langdon> dgilmore, we can always fail to COPR for that kind of scenario.. we don't have it at present.. like the "code" isn't the problem.. its accurate dep-checking/tracking
17:04:30 <langdon> when "everything" isn't just there.. you find problems in packaging
17:05:14 <langdon> but we haven't (to mu knowledge) needed, for example, a new lib for f26..
17:05:37 <langdon> because we just want the "running f26" version of things.. we are dealing with showing off multiple versions using copr or rawhide
17:05:50 <dgilmore> langdon: okay
17:06:13 <dgilmore> langdon: I think we do need to have some discussions about resourcing needs
17:06:39 <dgilmore> as in disk etc and making sure that we have some idea of what and how much we need to retain
17:06:41 <langdon> yeah.. hw and people
17:07:05 <dgilmore> because it seems like we may not be able to clean up any of the modules
17:07:06 <maxamillion> langdon: wait, what about COPR?
17:07:17 <maxamillion> langdon: we should never be targeting COPR for anything that is going to ship
17:07:19 <langdon> luckily, i can, mostly, throw threebean under the bus on resourcing ;)
17:07:41 <threebean> yeah, that's a thing.
17:07:47 <dgilmore> maxamillion: copr is not supported
17:07:49 <langdon> maxamillion, yeah.. i know.. but we might use it to demonstrate new stuff while we are in "preview" mode.. not for "real"
17:07:58 <dgilmore> so anything there is not an official part of fedora
17:08:14 <maxamillion> langdon: I don't think it can carry the Fedora branding if you do that .... /me could be wrong though
17:08:15 <threebean> before the f26 cycle we had only guesses about storage.  now we've got some data in koji and we can start to extrapolate usage expectations.
17:08:15 <langdon> thats why we would like to stick to rawhide..
17:08:16 <dgilmore> but there is nothing against it being there
17:08:46 <langdon> nothing in boltron as shipped would be from copr.. more like "please do this survery and provide feedback, step 1 enable copr repo"
17:08:54 <langdon> *survey
17:09:49 <langdon> maxamillion, make sense?
17:10:30 <dgilmore> any more questions on Boltron and f26?
17:11:38 <dgilmore> I will take that as no
17:11:54 <dgilmore> I am going to sneakly inject something rather than wait for open floor
17:12:05 <dgilmore> #topic Fedora on windows
17:12:08 <dgilmore> https://www.theverge.com/circuitbreaker/2017/5/11/15625320/ubuntu-suse-linux-fedora-windows-store-microsoft-build-2017
17:12:11 <Rathann> hehe
17:12:16 <dgilmore> so that was announced yesterday
17:12:21 <langdon> +2
17:12:29 <dgilmore> which is cool
17:12:34 <Rathann> it is good news
17:12:37 * langdon working on getting a working windows instance again so I can try it out
17:12:38 <dgilmore> I had heard that it may be a thing
17:12:54 <maxamillion> that's pretty cool
17:12:59 <kalev> that's cool indeed
17:12:59 <dgilmore> would have been nice to have been in the loop a little more
17:13:07 <jforbes> Nice!
17:13:19 <langdon> speaking as a council member.. it was embargoed
17:13:20 <dgilmore> apparently they are sucking in the docker base image
17:13:23 <maxamillion> is anyone from Fedora working on that? is that something we're releasing or is Microsoft building it?
17:13:28 <maxamillion> dgilmore: ah
17:13:31 <langdon> all fedora/rht
17:13:37 <langdon> with support from MS
17:13:45 <maxamillion> langdon: cool
17:13:49 <dgilmore> we will have to figure out the handoff
17:13:58 <dgilmore> and the best set of content to offer
17:14:00 <langdon> i think now that it is announced we can actually do it more "right"
17:14:34 <dgilmore> It would not take much to make a kickstart and enable it in the compose  to make something targeted at the use case
17:14:37 * langdon contemplating the Boltron on WSL! ;)
17:14:53 <dgilmore> would anyone be against slipping it into F26?
17:14:56 <langdon> dgilmore, exactly.. i or matt will be definitely asking for more "help"
17:15:10 <dgilmore> so that from day 1 its a really nice experience for the users?
17:15:33 <langdon> i would be excited to see that.. as a council member.. not fesco :)
17:15:52 * dgilmore has zero way to actually test it
17:16:05 <langdon> dgilmore, assuming fesco approves.. I can hook the right people up on rel-eng side with the people who did the work
17:16:05 <nirik> it would be nice, but not sure how much work it will be...
17:16:21 <sgallagh> dgilmore: slipping what into F26?
17:16:23 <langdon> i think it is "done".. just would need to be stuck somewhere "official"
17:16:39 <dgilmore> nirik: mattdm told me that we just need to give them a tar.xz of the filesystem contents
17:16:53 <dgilmore> sgallagh: a Fedora for Windows tarball
17:16:58 <langdon> right
17:17:32 <langdon> like i think someone wrote the script to make the tarball (kickstart what have you).. but they are running it by hand
17:17:57 <nirik> testing could be difficult for us/our QA, but if someone can test it...
17:18:06 <langdon> there is still some work to do to get it in to the windows store though
17:18:18 <langdon> i think MS has been helping to test
17:18:26 <langdon> but I can follow up on that for y'all
17:18:59 <dgilmore> I think something better than the docker base image would be good
17:19:10 <dgilmore> not taht the base image is bad
17:19:18 <maxamillion> dgilmore: honestly, I'd be willing to help with that from the container image side of the house
17:19:26 <dgilmore> just that we could provide a bit larger more robust set of tools
17:19:27 <sgallagh> dgilmore: This looks like a job for... Base Runtime. contyk?
17:19:45 <Rathann> and modularity?
17:19:52 <langdon> lol
17:20:40 <Rathann> I mean it makes sense if it's aimed at developers who need an easy way to install Fedora plus, say, gcc and python dev environment
17:20:50 <dgilmore> proposal #agreed FESCo is okay with adding Fedora on Windows disk image in f26. Assuminmg that its not invasive and does not take away from otehr deliverables
17:20:53 <Rathann> or ruby, haskell or whatever else we have
17:21:00 <maxamillion> dgilmore: +1
17:21:02 <nirik> +1
17:21:05 <Rathann> dgilmore: +1, minus the typos ;)
17:21:09 <kalev> +1
17:21:17 * dgilmore can not type today :(
17:21:17 * contyk looks
17:21:20 <sgallagh> dgilmore: +1
17:21:31 <jforbes> +1
17:21:45 <Rathann> I bet it can all be automatically tested using in a W10 VM
17:21:50 <contyk> heh :)
17:22:03 <langdon> Rathann, i think i saw the taskotron job for that already
17:22:13 <Rathann> great
17:22:14 <langdon> (/s)
17:22:46 <dgilmore> #agreed FESCo is okay with adding Fedora on Windows disk image in f26. Assuming that its not invasive and does not take away from other deliverables (6:+1 0:0 0:-1)
17:22:58 <dgilmore> #topic Next week's chair
17:23:10 <maxamillion> I can take next week
17:23:22 <dgilmore> #action maxamillion to run next weeks meeting
17:23:24 <dgilmore> thanks maxamillion
17:23:32 <dgilmore> #topic Open Floor
17:23:34 <maxamillion> sure thing :)
17:23:48 <dgilmore> anyone have anything else to bring up?
17:24:20 * dgilmore just notcied
17:24:21 <dgilmore> Note that mmaslano and stickster are FESCo liaisons for the Environment and Stacks and Workstation WGs, respectively, and not voting FESCo members.
17:24:29 <dgilmore> in the fesco meeting page
17:24:38 <dgilmore> I wonder if we should not clean up some of the docs
17:25:02 <sgallagh> mmaslano is also inactive in Fedora at this time
17:25:07 <Rathann> you might have noticed I missed a couple of meetings lately
17:25:17 <dgilmore> Rathann: all okay?
17:25:24 <Rathann> yes, just super busy at work
17:25:38 <Rathann> which translates into coming later home
17:25:38 <dgilmore> it happens
17:26:11 <Rathann> so I was wondering if anyone would be against moving the meeting one hour later
17:26:16 <langdon> not to add another meeting to my week.. but should we change e&s -> brt & modularity?
17:26:24 * nirik is fine either way
17:26:41 * jforbes too
17:26:45 <dgilmore> langdon: likely
17:26:51 <dgilmore> I am fine with moving it out
17:27:05 <dgilmore> this is normally the last meeting for me on a Friday
17:27:09 <maxamillion> I don't really have a preference on meeting time
17:27:27 <Rathann> dgilmore: I wouldn't want to make your Fridays longer
17:27:52 <dgilmore> Rathann: its the middle of the day
17:27:58 <dgilmore> my fridays go on
17:28:05 <Rathann> right
17:28:28 <dgilmore> Rathann: want to file an issue proposing it so that the people not here this week can chime in
17:28:41 <Rathann> ok, let's keep the time as-is for now and I'll see how it goes for a couple more weeks
17:29:16 <Rathann> and open a ticket if I think I'm having trouble with attending at the current hour
17:29:53 <dgilmore> okay
17:29:57 <dgilmore> sounds like a plan
17:30:37 <dgilmore> #info Rathann to see how the meeting time works out and will file a issue if it needs to be changed
17:30:48 <dgilmore> if nothing else I will wrap up
17:31:33 <maxamillion> +1
17:31:46 <dgilmore> #endmeeting