15:00:00 <contyk> #startmeeting FESCO (2019-05-17)
15:00:00 <zodbot> Meeting started Fri May 17 15:00:00 2019 UTC.
15:00:00 <zodbot> This meeting is logged and archived in a public location.
15:00:00 <zodbot> The chair is contyk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:00 <zodbot> The meeting name has been set to 'fesco_(2019-05-17)'
15:00:02 <contyk> #meetingname fesco
15:00:02 <zodbot> The meeting name has been set to 'fesco'
15:00:04 <contyk> #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:04 <zodbot> Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:06 <contyk> #topic init process
15:00:14 <contyk> .hello psabata
15:00:15 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:15 <nirik> morning
15:00:19 <jforbes> .hello2
15:00:20 <zodbot> jforbes: jforbes 'Justin M. Forbes' <jforbes@redhat.com>
15:00:47 <sgallagh> .hello2
15:00:48 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:53 <mhroncok> hi
15:02:05 <contyk> yay, quorum
15:02:10 <bookwar> .hello2
15:02:10 <zodbot> bookwar: bookwar 'Aleksandra Fedorova' <alpha@bookwar.info>
15:02:42 <bcotton> .hello2
15:02:43 <zbyszek> .hello2
15:02:43 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:02:46 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:02:47 <bookwar> hi all, sorry for missing last time, was on the road
15:03:05 <contyk> no worries
15:03:20 <zbyszek> oh, I'm in a tram, I'll have to drop off for a few minutes in half an hour
15:03:26 <contyk> well, let's get this started then
15:03:29 <bowlofeggs> .hello2
15:03:30 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:03:34 <contyk> I only put two topics on the agenda anyway
15:03:45 <contyk> #topic #2128 Policy needed: Modules built against EOL Fedora releases
15:03:47 <contyk> .fesco 2128
15:03:48 <zodbot> contyk: Issue #2128: Policy needed: Modules built against EOL Fedora releases - fesco - Pagure.io - https://pagure.io/fesco/issue/2128
15:03:49 <contyk> https://pagure.io/fesco/issue/2128
15:04:16 <sgallagh> So, my proposal there was heavily-flawed, as mhroncok pointed out
15:04:39 <nirik> so perhaps s/rawhide/oldest supported stable release/ ?
15:04:50 <sgallagh> nirik: I don't love that as an answer either
15:05:08 * contyk is reading the comments
15:05:15 <bowlofeggs> why not just say it has to be built against any supported release?
15:05:18 <bowlofeggs> including epel?
15:05:23 <sgallagh> Because it means that we're shipping content on fN that doesn't have the security hardening of other packages and modules
15:05:23 <zbyszek> I guess that for fedora this isn't so bad, because support is only 13 months...
15:05:26 <mhroncok> I'm fine with "any supported release"
15:05:38 <nirik> sgallagh: well, we are still shipping that release...
15:05:55 <jforbes> Right, we are basically saying it has to be rebuilt once per year
15:06:05 <bowlofeggs> sgallagh: i think it's ok because if we thought it was a real security issue we should fix it in the release anyway, right?
15:06:08 <sgallagh> I'm not saying I won't settle for it.
15:06:18 <sgallagh> I'm making sure we understand what we're settling *on*
15:06:22 <zbyszek> bowlofeggs, mhroncok: but doesn't have the same problem that sgallagh proposal had
15:06:25 * nirik is ok with 'any supported' or 'oldest supported'
15:06:38 <zbyszek> > Packages built against older glibc etc. will work with new glibc etc., but not the other way around.
15:06:41 <zbyszek> ?
15:06:49 <contyk> there are two cases where people use this limited modular buildrequires setup
15:07:02 <contyk> one is that java case which builds on the oldest one and doesn't rebuild until they have to
15:07:05 <mhroncok> zbyszek: we keep the "make it work" part on the mainatiner
15:07:14 <contyk> the other was the rust module which only builds on rawhide and ships to older releases
15:07:30 <contyk> because they build statically and don't have the build deps in older platforms
15:07:36 <sgallagh> contyk: Does rust not link against glibc even?
15:07:50 <zbyszek> it does link
15:08:07 <bowlofeggs> zbyszek: yeah i agree with mhroncok - our policies should be about what is safe/allowed. if it doesn't work the maintainer can solve it without policy
15:08:09 <contyk> even if it does, is that an issue?
15:08:19 <sgallagh> bowlofeggs: +1
15:08:20 <contyk> they do it the other way around
15:08:46 <sgallagh> contyk: Can you add antecedents to "it" and "that" in your sentence?
15:08:52 <sgallagh> I don't know what you were replying to
15:08:57 <zbyszek> OK, in that case I'm fine with "any supported release"
15:09:22 <contyk> they build with the latest hardening flags, so that security aspect is solved
15:09:41 <sgallagh> contyk: I was concerned about it not actually running against FN-2
15:09:42 <contyk> if they build in rawhide and then ship in f29; unless the packages then don't work because of glibc incompatibility
15:09:45 <sgallagh> But that's not my problem
15:09:50 <contyk> in which case I would say it's up to the maintainer to solve it
15:09:54 <sgallagh> Agreed
15:09:57 <mhroncok> or stop doing that
15:10:17 <sgallagh> OK, let's assume that we go with "any supported release"... how do we enforce that?
15:10:25 <bowlofeggs> my module (rpick) just gets built against all releases anyway (rather than build once and ship many), and i'd think maybe most people would just do that?
15:10:34 <sgallagh> When does that enforcement occur?
15:10:43 <contyk> bowlofeggs: yes, most would and should
15:11:05 <sgallagh> If I build a module on F28 for FAnything the day before F28 goes EOL, what do we do about shipping that module on F29 and F30?
15:11:07 <contyk> but in some cases they might not want to do that and I'd like to leave that to them (and deal with breakage if it occurs)
15:11:10 <sgallagh> Do we nuke it from the repos?
15:11:16 <sgallagh> What if it's a default stream?
15:11:16 <mhroncok> sgallagh: when FN is released, (somebody|something) opens bugs for module that were only built on FN-2
15:11:41 <bowlofeggs> sgallagh: is it possible to know which release each module we ship was built against?
15:11:47 <contyk> it is
15:11:49 <mhroncok> if the module is not rebuilt on at least FN-1, it gets "orphaned"
15:11:52 <bowlofeggs> maybe s/possible/easy/ ☺
15:12:14 <mhroncok> if it is not a default stream, we nook it from the repos
15:12:16 <contyk> I think mhroncok's proposal is sane
15:12:26 <mhroncok> if it is a default stream, I have no idea
15:12:32 <bowlofeggs> how will the user know if they are using a module that got nuked?
15:12:38 <sgallagh> mhroncok: I think we probably can't nuke it, especially if it shipped in the frozwn repo
15:12:40 <sgallagh> *frozen
15:12:45 <bowlofeggs> will they just stop getting updates for it and not know it is no longer supported?
15:13:00 <contyk> just like with packages, yeah
15:13:01 <sgallagh> But we *can* make sure that they can't ship updates for it without fixing the BRs
15:13:02 <mhroncok> I'd like to follow the 6 weeks orphaned period, but I have no idea how to do that in modular world
15:13:11 <mhroncok> sgallagh: nuke from rawhide at least
15:13:14 <bowlofeggs> that seems kinda bad to me
15:13:17 <sgallagh> mhroncok: That's fair
15:14:03 <mhroncok> so in theory, we still have F28 built packages in the entire F30 life time, but that is a compormise
15:14:08 <bowlofeggs> acknowledging that this happens with rpms because maintainers disappear, it does seem "more bad" that a module i'm using could become unsupported mid release because it was built against a retired fedora, and i won't be informed
15:14:28 <sgallagh> mhroncok: I think it's a reasonable compromise.
15:15:14 <sgallagh> bowlofeggs: Well, it's not any different than a packager disappearing and no one noticing that no updates show up
15:15:18 <mhroncok> bowlofeggs: well effectively, this is the same - no updates in either scenario
15:15:37 <bowlofeggs> would this only happen *because* the maintainer disappeared?
15:15:39 <sgallagh> We never really notice until someone starts non-responsive policy or it becomes FTBFS on a mass-rebuild
15:16:00 <mhroncok> sgallagh: and even FTBFS packages stay forever
15:16:01 <bowlofeggs> it is a bit worse though because there's mroe to it than the main package
15:16:05 <sgallagh> We can also paper over this a bit during the mass-rebuild policy.
15:16:11 <bowlofeggs> because there can be CVEs in the dependencies
15:16:25 <bowlofeggs> if an RPM maintainer disappears, at least the openssl on my box is still maintainer
15:16:33 <sgallagh> We have code to detect the BRs at that point, so we can file the mass-rebuild bugs for them then
15:16:43 <mhroncok> not if the openssl maintainer disappears
15:16:49 <bowlofeggs> if a module maintainer disappears and that module has openssl, the attack surface is bigger
15:16:57 <bowlofeggs> the effect of a missing maintainer is more significant here
15:17:08 <mhroncok> in theory
15:17:16 <mhroncok> in practice, it's still the same person
15:17:24 <jforbes> not really
15:17:28 <mhroncok> either maintaining 100 java packages in one module, or in Fedora
15:17:49 <contyk> not always the same person
15:17:56 <bowlofeggs> yeah i'd say usually not the same person
15:18:05 <contyk> I could make a module that bundles openssl and anyone using my module would override the "system" version
15:18:20 <contyk> if I then stop maintaining it, they will be stuck with my version, not knowing
15:18:21 <mhroncok> contyk: you should not be able to do that IMHO
15:18:33 <sgallagh> We should *probably* also have a policy disallowing module streams of crypto libs
15:18:34 <bookwar> contyk: but this is the decision a person makes when choosing to use the module
15:18:35 <mhroncok> if we allow this, we are doomed anyway
15:18:42 <contyk> bookwar: yes
15:18:47 <sgallagh> Just as a general safety precaution
15:18:51 <bowlofeggs> it's not just crypto though - that was just an example
15:18:56 <bookwar> we can not guard people from those
15:18:59 <zbyszek> I think we're diverging from the main topic here. Let's not go into Modularity just yet.
15:19:00 <contyk> mhroncok: well, that's one aspect of modules -- ship the deps that your app needs
15:19:01 <bowlofeggs> CVEs can happen in any package
15:19:15 <bookwar> when they choose to use such a module, they need to subscibe to the news regarding it
15:19:17 <bowlofeggs> zbyszek: isn't modularity the topic here?
15:19:21 <contyk> mhroncok: if my app requires some special openssl, it would be reasonable to put in there
15:19:27 <contyk> with crypto it's highly questionable
15:19:30 <contyk> but in principle, yes
15:20:01 <zbyszek> bowlofeggs: yeah, but it's ageneral problem slash feature of modularity, it applies the same to every modular package.
15:20:09 <bowlofeggs> yes
15:20:55 <bowlofeggs> but i think allowing modules to stay around that were built n-m releases ago exacerbates this problem'
15:20:56 <mhroncok> proposal: we agree on the general rule
15:21:11 <mhroncok> and we figure out the "enforcement" later
15:21:23 <zbyszek> yes, +1
15:21:24 <nirik> perhaps at eol of a release we run reports for any modules still using that release?
15:21:31 <mhroncok> the scale of this is still so small that we can just talk to the maintainers
15:21:38 <sgallagh> mhroncok: That's fine.
15:21:44 <bowlofeggs> like if f30, at date of EOL has a module that was built when f28 was branched and that module has an openssl vuln, that seems worse than what would happen with ursine packages
15:21:47 <contyk> could you restate the general rule?
15:22:03 <sgallagh> I brought it up because it may be harder to implement than we immediately realize.
15:22:05 <zbyszek> Maybe we could just open bugs against all modules built against the old release with "please rebuild"?
15:22:08 <bookwar> bowlofeggs: we shouldn't allow this in default modules, but for custom ones - this is a choice people make. We just really need to make sure we communicate it - you are using a weird module it is your headache when it is not maintained anymore
15:22:09 <mhroncok> ...
15:23:04 <nirik> wasn't this what freshmaker was supposed to do?
15:23:07 <sgallagh> Proposal: Policy for modules in Fedora is that all modules being shipped in the stable repositories must have been built against a currently-stable platform"
15:23:12 <bowlofeggs> bookwar: that sounds like someting appropriate for copr, but not official fedora repos, imo
15:23:16 <contyk> nirik: one of many things, the scope has changed quite a bit
15:23:22 <sgallagh> -"
15:23:33 <nirik> sgallagh: does that handle the rust case tho?
15:23:34 <bowlofeggs> sgallagh: +1
15:23:36 <contyk> sgallagh: does "currently stable" include rawhide?
15:23:42 <nirik> depending on if you include rawhide there.
15:23:43 <mhroncok> Any module that is capable of building against one platform but running against all of them must be always be built against a supported platform. Modules built against EOL platform MUST be rebuilt on a newer one.
15:23:47 * sgallagh sighs
15:23:49 <sgallagh> OK, revising
15:23:49 <bowlofeggs> sgallagh: but that may be hard to deal with in practice
15:23:56 <zbyszek> mhroncok: +1
15:24:05 <sgallagh> Proposal: Policy for modules in Fedora is that all modules being shipped in the stable repositories must have been built against a currently-active release of Fedora or Rawhide"
15:24:12 <bowlofeggs> i like the policy as a rule, but i think it may be hard to implement
15:24:19 <contyk> sgallagh: +1
15:24:32 <contyk> this also deals with the EPEL case
15:24:35 <contyk> so that's good
15:24:40 <nirik> mhroncok: +1 sgallagh +1 (I think they say the same thing, pick whichever better wording)
15:24:50 <zbyszek> sgallagh: +1 too, what nirik said
15:24:51 <mhroncok> mine doesn't say fedora or epel
15:24:53 <bowlofeggs> what happens if the rebuild against supported platform fails?
15:25:05 <mhroncok> sgallagh's explicitly mentions Fedora, so it rules out EPEL IMHO
15:25:09 <sgallagh> Yeah, mine also doesn't mention epel
15:25:10 <mhroncok> I'm OK with both
15:25:11 * sgallagh sighs
15:25:15 <ignatenkobrain> .ello2
15:25:15 <sgallagh> One more try...
15:25:18 <nirik> I don't think we need to worry about epel right now... since it's not possible
15:25:24 <contyk> I'd rather exclude EPEL from this
15:25:25 <sgallagh> Proposal: Policy for modules in Fedora is that all modules being shipped in the stable repositories must have been built against a currently-active release of Fedora, EPEL or Rawhide
15:25:33 <sgallagh> grr, one sec
15:25:36 <contyk> building on EPEL and then shipping in Fedora doesn't sound right
15:25:51 <ignatenkobrain> probably one point to this, who is going to rebuild modules when some release goes EOL?
15:25:51 <sgallagh> Proposal: Policy for modules in Fedora and EPEL is that all modules being shipped in the stable repositories must have been built against a currently-active release of Fedora, EPEL or Rawhide
15:25:55 <ignatenkobrain> and change all modulemds?
15:26:06 <ignatenkobrain> probably worth deciding on this prior restricting it
15:26:06 <bowlofeggs> yeah i'm concerned abotu the rebuild too
15:26:11 <sgallagh> ignatenkobrain: We already discussed that and deferred that question
15:26:16 <bowlofeggs> both who will do it, and what will happen when it fails
15:26:21 <sgallagh> The policy can stand before we automate it
15:26:45 <bowlofeggs> because if it fails, we don't have a way to inform users that they are now using soemthing that can't be supported
15:26:45 <contyk> I think it's fine; there are basically three cases
15:26:49 <mhroncok> I'm +1 for whatever (with EPEL, without EPEL)
15:26:49 <bowlofeggs> and that can happen mid-release
15:26:52 <bowlofeggs> so that can be surprising
15:27:00 <contyk> 1. you build for all platforms and you're always fine; this is handled by releng and mass rebuilds
15:27:08 <contyk> 2. you build only in rawhide and ship everywhere, you're fine
15:27:24 <contyk> 3. you build only in the oldest release and ship everywhere, you need to update your modulemd every release and rebuild
15:27:27 <sgallagh> bowlofeggs: As I said before, that is no different than a package maintainer getting busy and not releasing the latest updates from upstream.
15:27:41 <sgallagh> If the package still *works*, great.
15:27:54 <bowlofeggs> sgallagh: i disagree - as i said before, the impact can be worse due to inclusion of deps they don't maintain
15:28:17 <bowlofeggs> i.e., it is not the same level of impact as what happens with ursine builds
15:28:44 <bowlofeggs> with ursine, one rpm is unmaintained. with this, an RPM and n of its deps are unmaintained
15:28:56 <sgallagh> bowlofeggs: The set of people doing this right now is small enough that I'm willing to assume we don't need to legislate around it yet
15:28:59 <jforbes> bowlofeggs: including deps they don't maintain inside the module gets us back to the static linking problem
15:29:09 <bowlofeggs> jforbes: yeah
15:29:46 <jforbes> And as such, it should not be allowed without an exception similar to static linking
15:30:05 <bowlofeggs> if we at least had a way to inform users that they are using a module that was built against a now-unsupported fedora release, that would help my concern a bit (but not entirely)
15:30:11 <sgallagh> jforbes: We no longer require exceptions for that. Just virtual Provides
15:31:22 <mhroncok> let's vote?
15:31:30 * nirik thinks we aren't going to solve enforcement today...needs more thought
15:31:36 <mhroncok> sgallagh's Proposal: Policy for modules in Fedora and EPEL is that all modules being shipped in the stable repositories must have been built against a currently-active release of Fedora, EPEL or Rawhide
15:31:47 <contyk> +1
15:31:49 <mhroncok> +1
15:31:51 <sgallagh> +1
15:31:57 <bookwar> +1
15:31:58 <jforbes> +1
15:32:07 <bowlofeggs> +1 (but i'm worried that we can't actually enforce it)
15:32:12 <contyk> even though technically this might mean shipping rawhide modules in EPEL
15:32:19 <contyk> we might fine tune that once someone does that
15:32:26 <nirik> +1
15:32:29 <sgallagh> contyk: If it works, do we care?
15:32:36 <contyk> maybe not
15:32:48 <sgallagh> If it doesn't work, probably the maintainer will care
15:33:29 <mhroncok> zbyszek: ?
15:33:32 <bowlofeggs> contyk: i imagine that's what the rust sig will want to do
15:33:45 <sgallagh> mhroncok: He said he'd have an outage about now
15:33:50 <mhroncok> oh
15:33:52 <contyk> okay
15:34:08 <contyk> #agree Policy for modules in Fedora and EPEL is that all modules being shipped in the stable repositories must have been built against a currently-active release of Fedora, EPEL or Rawhide (+8, 0, -0)
15:34:28 <contyk> I was expecting to spend the whole two hours on this
15:34:38 <contyk> we're super effective today
15:34:42 <mhroncok> we can spend the remaining time on the enforcment part :D
15:34:44 <contyk> #topic #2127 Election Interview Questions — FESCo (Jun 2019)
15:34:44 <bcotton> fesco++
15:34:46 <contyk> .fesco 2127
15:34:48 <contyk> https://pagure.io/fesco/issue/2127
15:34:48 <zodbot> contyk: Issue #2127: Election Interview Questions — FESCo (Jun 2019) - fesco - Pagure.io - https://pagure.io/fesco/issue/2127
15:35:21 <mhroncok> accepted by policy?
15:35:48 <contyk> seems so
15:35:48 <bowlofeggs> i'm fine with reusing the same questions we've been using the last few elections
15:35:55 <contyk> I only saw +3 when making the agenda
15:35:55 <nirik> I guess those are ok... they are a bit stale, but meh
15:36:17 <contyk> nirik: that means I can copy&paste my answers, too
15:36:18 <mhroncok> it's not like somebody has time to change them anyway, right?
15:36:52 <nirik> contyk: sure!
15:37:02 <contyk> ok, accepted by policy
15:37:19 <contyk> #agree The same set of questions will be used again (+5, 0, -0)
15:37:26 <bookwar> mhroncok: i have my answers prepared for the next round )
15:37:38 <contyk> #topic Next week's chair
15:38:10 <contyk> I won't be around next week
15:38:18 <contyk> probably
15:38:25 <zbyszek> contyk: please count me +1 to the vote on mhroncok's proposal
15:38:53 * contyk makes a mental note
15:38:59 <jforbes> I will be around for most of the meeting, depends on how long it goes.
15:39:18 <contyk> anyone going to the opensuse conference?
15:39:23 <sgallagh> I guess I can do it, if no one else is chiming in.
15:39:24 * mhroncok doesn't know yet. might not be around
15:39:35 <zbyszek> I'm not sure if I'll be around yet. I have some travelling in the evening.
15:39:53 <contyk> alright
15:40:00 <contyk> #action sgallagh will chair next meeting
15:40:02 <contyk> sgallagh++
15:40:03 <zodbot> contyk: Karma for sgallagh changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:40:08 <contyk> #topic Open Floor
15:41:18 <mhroncok> contyk: any update on default modular packages in the buildroot?
15:43:34 <contyk> mhroncok: not much new but I had a meeting with the MBS folks yesterday to brainstorm the changes needed on their side to support this
15:43:50 <contyk> there is one open technical question still but I think we can proceed
15:44:05 <sgallagh> What's the remaining technical question?
15:44:29 <contyk> MBS using inheritance to create the buildroots means you can't have those defaults that depend on conflicting streams
15:45:10 <contyk> long term we should make MBS somehow inject modular metadata into its buildroots and use dnf to resolve it but that would be a major change
15:45:17 <contyk> and it's not needed right now
15:45:19 <zbyszek> contyk: should default streams not depend on anything that conflicts with anything else, and so on transitively
15:45:26 <zbyszek> ?
15:45:41 <contyk> zbyszek: technically they can and dnf can deal with it
15:45:54 <contyk> zbyszek: e.g. A:1 and B:1 being the defaults, A:1 depending on B:2
15:46:01 <sgallagh> zbyszek: Our current policy in Fedora is that default streams may not do that.
15:46:16 <contyk> zbyszek: with dnf if you install something from A:1, you enable B:2 and make the B:1 default unavailable and vice versa
15:46:16 <sgallagh> (Though it's not enforced by any technical means)
15:46:49 <contyk> since we have this policy that sgallagh mentions, we don't have to deal with the MBS issue right away
15:47:16 <contyk> but dnf can handle it
15:48:12 <contyk> closing in a minute unless there's anything else?
15:48:22 <nirik> well, if the question is non modular build root...
15:48:45 <contyk> the non-modular buildroot is not affected by this, even without the policy
15:48:51 <nirik> we need still to make the new buildroot compose and update koji/createrepoc
15:49:27 <nirik> or wait for epel8 to test things. ;)
15:49:33 <contyk> so I think sgallagh made the changes to createrepo
15:49:45 <contyk> regarding koji I'd need to check but that was also planned out
15:49:47 <sgallagh> Yes, the 0.14 release should have the necessary changes
15:49:48 <nirik> yes, both createrepo and koji patches are done and merged.
15:49:55 <contyk> nice
15:49:57 <sgallagh> Koji had the patches merged, not sure if there has been a release
15:50:01 <nirik> but we still need to make the modular buildroot compose...
15:50:05 <contyk> then I just need to file the specific requirements for the composes :)
15:50:11 <nirik> there has not been, but we can backport.
15:50:12 <contyk> then we need that MBS change
15:50:34 <contyk> and then we can roll it all out
15:50:59 <nirik> oh right, I guess it has to use the new buildroot too... ok
15:51:26 <contyk> yeah
15:51:28 <nirik> contyk: has there been any discussion of mbs changes needed for epel8? or this would support that too?
15:51:39 <contyk> nirik: this covers EPEL8 as well
15:52:33 <contyk> as far as I know, the EPEL plan is still the same -- decompose the RHEL8+CRB content into a purely ursine tag + one tag per module, all linking to external repos
15:52:51 <nirik> ok. in epel8 the default/buildroot modules will be a bunch of external repos... in fedora it will be a buildroot repo for that?
15:52:52 <contyk> then we'll need MBS records for the RHEL8 modules, pointing to those tags
15:53:05 <contyk> a compose of RHEL8 defaults that gets linked with the ursine buildroot, just like in Fedora...
15:53:07 <contyk> and that's it
15:53:41 <contyk> nirik: in EPEL it would be the ursine tag (also an external repo) + a bunch of externalr repos for each module
15:53:57 <contyk> nirik: in Fedora an ursine tag (not an external repo) + one external repo with the default modules, all in one
15:54:01 <contyk> almost the same
15:54:06 <nirik> right.
15:54:26 <nirik> for epel8 we split the rhel8 appstream, for fedora we combine the modules into an appstream. ;)
15:54:34 <mhroncok> contyk: thanks for the update
15:54:48 <contyk> alright
15:54:52 <contyk> anything else?
15:55:29 <contyk> okay
15:55:36 <contyk> #endmeeting