15:08:18 <langdon> #startmeeting Modularity Team Meeting
15:08:18 <zodbot> Meeting started Tue Oct  8 15:08:18 2019 UTC.
15:08:18 <zodbot> This meeting is logged and archived in a public location.
15:08:18 <zodbot> The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:08:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:08:18 <zodbot> The meeting name has been set to 'modularity_team_meeting'
15:08:30 <langdon> #meetingname modularity
15:08:30 <zodbot> The meeting name has been set to 'modularity'
15:08:37 <langdon> #topic roll call
15:08:39 <langdon> .hello2
15:08:40 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
15:08:42 <contyk> .hello psabata
15:08:43 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:08:51 <langdon> #chair contyk sgallagh
15:08:51 <zodbot> Current chairs: contyk langdon sgallagh
15:08:55 <asamalik> .hello2
15:08:56 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:09:03 <langdon> #chair asamalik
15:09:03 <zodbot> Current chairs: asamalik contyk langdon sgallagh
15:09:21 <sgallagh> .hello2
15:09:21 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:09:31 <asamalik> .chair langdon
15:09:31 <zodbot> langdon is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them.
15:10:03 <langdon> technically standing
15:10:08 <langdon> #topic agenda
15:10:16 <langdon> #info update on ursa prime
15:10:22 <langdon> any other ideas?
15:10:43 <sgallagh> hahaha
15:10:53 <contyk> is that a new feature?
15:10:59 <contyk> zodbot++
15:11:13 <sgallagh> I can update on recent libmodulemd changes
15:11:14 <langdon> im not sure how i feel about not killing him this week
15:11:23 <langdon> #info update on libmodulemd
15:12:26 <langdon> ok.. want to get to it then?
15:12:31 <sgallagh> Rock on
15:12:33 <langdon> #topic update on ursa prime
15:12:39 <langdon> contyk: i think this is yours
15:12:44 <langdon> or maybe sgallagh
15:13:05 <contyk> maybe
15:13:17 <contyk> so basically it should be functionally ready
15:13:25 <sgallagh> The major point to bring up here is our timeline for deployment
15:13:26 <contyk> there are just three things left to do
15:13:46 <contyk> ...and sgallagh suggested we aim for Monday in prod :)
15:14:08 <sgallagh> I do have more to add on that. I spoke with mboddu briefly this morning
15:14:39 <sgallagh> He'd recommend limiting the roll-out to Rawhide/F32 and EPEL8[-playground] for now
15:14:46 <sgallagh> Since we'll be in Infrastructure Freeze next week
15:14:50 <contyk> I think that was the plan
15:15:07 <sgallagh> I wanted to make sure it was in writing somewhere
15:15:37 <asamalik> maybe let's even info that
15:16:09 <sgallagh> Let's do that once we have discussed the timeline a bit.
15:16:28 <asamalik> I think it's a good thing it's just in Rawhide because it's a change
15:16:37 <sgallagh> The goal is for us to have whatever PRs are outstanding be reviewed and merged by Friday (giving us the weekend to deal with slippage)
15:16:55 <sgallagh> And then do the deployement at the beginning of next week.
15:17:19 <sgallagh> I originally suggested Monday, but I just remembered that I will not be around on Monday (due to it being a school holiday in Massachusetts)
15:17:41 <sgallagh> Though it doesn't have to block on me. I don't know who else might be missing though
15:17:42 <langdon> i bet we will be missing a bunch of people in fact
15:18:32 <sgallagh> So perhaps it would be wiser to make it Tuesday?
15:18:46 <langdon> yes
15:19:01 <sgallagh> contyk, asamalik: Does that seem workable to you?
15:21:11 <asamalik> definitely good to plan to do it outside holidays, yes :)
15:21:41 <sgallagh> #info Ursa Prime will be deployed to production next Tuesday
15:22:08 <sgallagh> #info Ursa Prime configuration will initially be limited to Rawhide/F32 and EPEL8[-playground] buildroots
15:22:15 <contyk> it does
15:22:27 <sgallagh> contyk: Could you enumerate the three remaining tasks?
15:22:34 <contyk> sure
15:22:36 <sgallagh> (#info would be best)
15:22:43 <contyk> it's all releng stuff
15:24:19 <contyk> #info The remaining tasks to be done for Ursa Prime: 1) modify the f32/rawhide platform.yaml record in MBS to enable this feature, 2) set up a repo compose based on the defaults+overrides inputs, 3) configure koji tags and targets so that the rawhide target is a merged repo containing the modular and non-modular content
15:24:47 <sgallagh> Thank you
15:25:24 <langdon> \o/
15:25:53 <sgallagh> #action contyk and sgallagh to work with nirik to finish those three tasks.
15:26:17 <contyk> we're going to discuss these steps with nirik in 30 minutes on #fedora-modularity
15:26:31 <langdon> cool
15:26:38 <langdon> move on? or is there more to say?
15:27:33 <contyk> everything's been said
15:27:34 <sgallagh> "It's been a long road, but the end is in sight"
15:27:58 <langdon> ha
15:28:01 <asamalik> is it because the bridge has fallen? or because we're actually nearly there? :P
15:28:13 <langdon> 6 of one...
15:28:35 <contyk> I should take my PTO starting next Wednesday
15:28:51 <asamalik> I took my PTO starting next Thursday afternoon
15:28:55 <asamalik> so Wednesday seems reasonable
15:29:08 <langdon> how about tues afternoon in eu?
15:29:20 <contyk> or now
15:29:24 <asamalik> for a month
15:29:24 <langdon> https://www.dictionary.com/browse/six-of-one--half-a-dozen-of-the-other
15:29:32 <langdon> ok.. moving on
15:29:33 <langdon> #topic libmodulemd update
15:29:44 <langdon> sgallagh: please enlighten us
15:30:07 * sgallagh flips the switch
15:30:42 <sgallagh> I've been working on a set of changes for the 2.8.1 and 1.8.16 releases of libmodulemd to how merging Modulemd Defaults works
15:31:10 <sgallagh> Full details of the change in behavior are in
15:31:10 <sgallagh> .link https://github.com/fedora-modularity/libmodulemd/issues/368
15:31:20 <sgallagh> #link https://github.com/fedora-modularity/libmodulemd/issues/368
15:31:37 <sgallagh> The 2.x changes are approved and landed, awaiting a release.
15:31:44 <langdon> \o/
15:31:57 <sgallagh> The 1.x changes are actually a little harder, but I plan to have them out for review today
15:32:18 <sgallagh> (I'd much prefer it if libdnf would move to the supportable API instead, but they keep kicking that can down the road)
15:32:58 <sgallagh> To the best of my knowledge, the only remaining consumers of libmodulemd 1.x are libdnf and a few older tests in the fedora-modulemd-defaults repository.
15:33:24 <asamalik> heh
15:33:45 <sgallagh> I'm strongly considering retiring it from Rawhide/F32 to force the issue.
15:33:51 <asamalik> how hard is it to migrate vs. making you maintain it... ?
15:33:58 <asamalik> +1
15:34:33 <langdon> ha
15:34:36 <sgallagh> asamalik: "I'm not scalable" is the short answer to that question
15:35:10 <langdon> you aren't that short
15:35:24 <sgallagh> Yes I am, but that's beside the point
15:35:29 <langdon> ha
15:35:31 <asamalik> lol
15:35:39 <sgallagh> Oh, hmm. Looks like COPR is still using 1.x also. le sigh
15:36:23 <asamalik> maybe they're waiting for an external motivation, possibly in F32, to move over :P
15:36:42 <langdon> or patches :/
15:37:06 <sgallagh> langdon: I've attempted to write some for libdnf, but it's incomprehensible and contains few comments.
15:37:17 <sgallagh> So I really need someone who understands that codebase to take point on it
15:37:33 <langdon> ick
15:37:41 * sgallagh notes that part of the reason for 2.x is that the design of it forbids some of the mistakes libdnf is making with 1.x
15:38:10 <sgallagh> So it's probably a slightly tougher merge for them than for others, as they have to fix some mistakes in their usage too.
15:38:13 <langdon> ha.. well.. at least we have learned
15:38:18 <sgallagh> s/merge/migration/
15:38:34 <langdon> anything for the #info'ing?
15:38:45 <sgallagh> I'll have a look at COPR after we get Ursa Prime out the door and see if that's something I can provide
15:39:00 <asamalik> langdon: maybe some naming and shaming? :P
15:39:10 <sgallagh> #action sgallagh to investigate libmodulemd 2.x migration for COPR
15:39:51 <sgallagh> #info slow migration away from libmodulemd 1.x is resulting in increasing maintenance burden
15:39:58 <langdon> proposed #info dnf and copr forcing the continued maintainance (*cannot* spell thta word .. will look up) of libmodulemd v1 ??
15:40:37 <sgallagh> "maintenance"
15:40:55 <sgallagh> langdon: I don't think we need to specifically name them. They know who they are
15:41:04 <langdon> yeah.. saw yours right after... i always want the "ai" part to be both before and after the t
15:41:04 <sgallagh> Anyway, I have one more topic to raise.
15:41:09 <langdon> sgallagh: ack
15:41:16 <langdon> ok.. you are chair if you want to #topic
15:41:37 <sgallagh> #topic Tagging Module Defaults into non-modular repo
15:41:52 <sgallagh> So, mattdm reraised this question after discussion on the devel@ list
15:42:24 <sgallagh> We originally had plans to have the contents of default module streams tagged into the non-modular repositories, but we scrapped that.
15:42:37 * langdon really needs to respond to a couple emails this afternoon
15:42:44 <sgallagh> I cannot remember the specific reasons for why (or whether they are still valid, given other changes since)
15:42:58 <sgallagh> So, please remind me :-)
15:43:07 <contyk> what are the reasons to do so?
15:43:19 <asamalik> I thought that was technically impossible for the same reasons we have "default" and "enabled" as two distinct states
15:43:37 <sgallagh> asamalik: Ahh, that may have been a big part of it, yes.
15:43:38 <langdon> i thought we *did* want them..
15:44:14 <langdon> default would only be enabled if the non-modular rpm used the content of the default module
15:44:25 <asamalik> although I'm still not 100 % clear we practically need/want those two, but that's a different topic likely
15:44:28 <asamalik> or maybe not
15:44:36 <asamalik> contyk usually knows everything
15:44:44 <asamalik> :P
15:44:48 <sgallagh> asamalik: The reason we need them is because two default modules might have non-default dependencies.
15:44:52 <langdon> we definitely need the two "states"
15:45:16 <sgallagh> *conflicting non-default dependencies
15:45:18 <contyk> so why would we want modular packages in the non-modular repo?
15:45:22 <asamalik> sgallagh: right, which back to my practicality point... byt I don't want to rabbit hole :)
15:45:25 <contyk> what problem is that solving?
15:45:30 <langdon> ohh.. i think it is because "tagging the default module in" is the equiv of "enabling the module" .. which is not quite what we want
15:45:50 <langdon> contyk: build deps on a module
15:46:03 <sgallagh> Not just build deps, but also allowing the Modular repos to be disabled entirely.
15:46:04 <contyk> that's Ursa Prime, has nothing to do with repos
15:46:21 <sgallagh> I'm not saying this is a good reason, but it is one that has come up
15:46:22 <asamalik> I remember that being discussed a very early in the process of switching to this "Modularity 2" thing, as one option, and I don't think we decided to go that way
15:46:45 <contyk> we could make just one hybrid repo, I'm all for it
15:46:54 <asamalik> +1 to a hybrid repo
15:47:02 <sgallagh> contyk: I don't think that addresses the actual issues though.
15:47:06 <contyk> which is something rather different :)
15:47:15 <contyk> sgallagh: so what are the issues?
15:47:16 <asamalik> well, if we really want Modularity to succeed
15:47:18 <sgallagh> People are suggesting this as an alternative to the default streams upgrade problem
15:47:41 <sgallagh> in other words "take default streams entirely out of the equation"
15:47:52 <asamalik> I think the problem is that Modularity is rolling critical path features gradually, making certain things like upgrades broken
15:48:34 <asamalik> making this change would mean more work, resulting in the final state to be delivered even later...
15:48:38 <sgallagh> again, I'm not advocating in favor of this approach, I'm trying to remember why we decided it wouldn't work anyway
15:48:58 <asamalik> with people having modular repos disabled potentially
15:49:02 <contyk> probably many reasons
15:49:15 <contyk> could be that distinction between defaults and enabled
15:49:33 <contyk> it's also not compatible with the failsafe mechanism (assuming it's about just tagging the packages without supplying modulemd)
15:49:58 <contyk> and if it's about upgrades, it seems more like a workaround
15:50:18 <contyk> like avoiding the actual issue by pretending there's no modularity
15:50:28 <asamalik> yep, rather than this, we need to get that "following default" thing in place
15:50:38 <asamalik> yep
15:50:41 <sgallagh> Well, there are a *lot* of voices clamoring for default streams to be disallowed in Fedora and to require that modules exist solely for alternative streams
15:51:19 <asamalik> that would brake so many assumptions Modularity is relying on, that this should be considered wisely :)
15:51:21 <sgallagh> And this would be one way that we could still allow them to build as modules so they don't have to follow two different workflows, depending on the release
15:52:10 <sgallagh> Of course, we are committed to supporting default streams for RHEL 8, so we must keep that also in mind
15:52:15 <langdon> "no defaults" could just be a policy decision.. so i am not sure it would break anything.. i think it is a terrible idea.. but i am not sure it would break things
15:52:20 <sgallagh> But RHEL doesn't really have the upgrade issue
15:52:39 <asamalik> sgallagh: but that's what CentOS Stream would be for if I got the announcement right
15:52:48 <contyk> so if I had to maintain my software twice... I wouldn't
15:52:53 <sgallagh> asamalik: Sorry, i'm not following.
15:52:58 <contyk> so I'd not use modules at all
15:53:11 <sgallagh> contyk: I've been doing it for Node.js for two years now.
15:53:12 <langdon> contyk: right
15:53:17 <sgallagh> It's not ideal, but it's not *terrible*
15:53:17 <asamalik> sgallagh: for rhel 8... but yes that still means maintaining software twice
15:54:17 <contyk> so maybe I'm missing something
15:54:28 <contyk> but with Ursa Prime putting the defaults in the buildroot
15:54:37 <contyk> and the upgrade path being fixed later on
15:54:52 <contyk> why would anyone want to force these workflows on others?
15:54:53 <asamalik> contyk: right, those two will fix it
15:55:02 <asamalik> the problem is likely the "later on"
15:55:05 <sgallagh> asamalik: We hope :-)
15:55:14 <asamalik> sgallagh: :-)
15:55:16 <langdon> we are almost out of time..
15:55:26 <contyk> I blame langdon
15:55:37 <langdon> most people do
15:55:49 <sgallagh> contyk: Ursa Prime solves the two problems we're facing today.
15:55:59 <sgallagh> Sorry, one of the problems
15:56:01 <langdon> is there a way someone representing the opinion could come to the meeting for discussion?
15:56:10 <langdon> i still think much of this is the point in time problem
15:56:13 <sgallagh> We're still trying to get a formal specification for how upgrades should work with defaults
15:56:24 <sgallagh> We understand it conceptually, but there's been pushback on my proposed spec
15:56:31 <langdon> sgallagh: we are? i thought we just had to write it up
15:56:38 <sgallagh> langdon: I wrote it up
15:56:48 <langdon> yeah.. i thought so.. i didn't see push back i guess
15:56:50 <contyk> there are still some corner cases that need to be investigated, afaik
15:56:51 <sgallagh> jmracek is not happy with it (and some others)
15:56:56 <langdon> but..  i have been out of sorts
15:57:07 <sgallagh> sort(langdon)
15:57:48 <langdon> ok.. next steps?>
15:57:56 <langdon> how can we close the meeting?
15:58:29 <sgallagh> I think I have enough information to reply about why we aren't doing the tagging-into-non-modular approach
15:59:09 <sgallagh> And I *hope* we can avoid the call to "drop defaults" if we get Ursa Prime deployed and a ratification of the upgrade proposal
15:59:21 <langdon> ok.. #info? or #action?
15:59:24 <asamalik> I feel like our answer is "no" because we want to implement a way to track defaults which will fix it
15:59:36 * sgallagh nods
15:59:43 <asamalik> so that should be our answer
15:59:52 <contyk> +1
15:59:55 <asamalik> and if there are enough people disagreeing, I think FESCo is the right place to talk
15:59:58 <asamalik> and make a decision
16:00:06 <sgallagh> +1
16:00:14 <asamalik> instead of endless arguing :)
16:00:21 <contyk> defaults are there to make things simpler for everyone
16:00:25 <asamalik> let's do #agreed?
16:00:32 <contyk> they exist so that you don't have to think about using modules
16:00:33 <langdon> ok
16:00:36 <sgallagh> contyk: I can see the smirk behind that sentence from here :)
16:00:57 <sgallagh> They're there to make things simpler for *users*. Jury is out on maintainers
16:00:59 <asamalik> contyk: the problem is that's not true now and won't be for some time, so I get why people are mad
16:01:03 <asamalik> but yes, that's the aspiration
16:01:31 <langdon> i think it is true for users
16:01:43 <sgallagh> langdon: Until they want to upgrade, sure
16:01:52 <langdon> but that is just dumb
16:02:04 <sgallagh> Upgrading?
16:02:18 <langdon> we established forever ago how that should work.. and it made sense..
16:02:24 <langdon> we are just swirling agian
16:02:29 <langdon> but.. thats for another dya
16:02:39 <langdon> do we have any agreed? i have a lunch i have to get to
16:02:42 <sgallagh> langdon: We were wrong then
16:02:49 <sgallagh> anyway, I think we're good here for now
16:02:57 <langdon> sgallagh: i don't think so :)
16:03:10 <langdon> ok.. so.. just end?
16:03:19 <langdon> asamalik: do you have an #agreed?
16:03:42 <asamalik> I don't but can write one
16:04:03 <contyk> proposed #agree to disagree
16:04:26 <langdon> i kinda wonder if #disagree is a thing
16:04:58 <asamalik> #proposed #agreed We disagree with merging default streams into the main repo as non-modular packages. Our approach is to implement a mechanism of following default stream to give people the experience they want.
16:05:05 <asamalik> it is!
16:05:37 <langdon> s/ following default stream / following default stream(s)
16:05:45 <langdon> but i agree otherwise
16:05:52 <asamalik> #proposed #agreed We disagree with merging default streams into the main repo as non-modular packages. Our approach is to implement a mechanism of following default streams to give people the experience they want.
16:05:56 <asamalik> langdon: thanks, typo, fixed
16:06:13 <langdon> +1
16:06:24 <asamalik> sgallagh, contyk: do you agree with the disagreement?
16:07:01 <sgallagh> +1
16:07:07 <contyk> oh, it's for real
16:07:11 <asamalik> +1 ftr
16:07:26 <contyk> +1
16:07:27 <langdon> ha
16:07:40 <asamalik> #agreed We disagree with merging default streams into the main repo as non-modular packages. Our approach is to implement a mechanism of following default streams to give people the experience they want. (+4 0 -0)
16:08:34 <langdon> OK.. anything else?
16:08:47 * asamalik has nothing else here
16:09:41 <langdon> OK.. going once?
16:10:04 <asamalik> 2 3 :)
16:11:53 <langdon> and three times!
16:11:58 <langdon> #endmeeting