15:01:51 <asamalik> #startmeeting modularity
15:01:51 <zodbot> Meeting started Tue Apr 23 15:01:51 2019 UTC.
15:01:51 <zodbot> This meeting is logged and archived in a public location.
15:01:51 <zodbot> The chair is asamalik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:51 <zodbot> The meeting name has been set to 'modularity'
15:01:51 <asamalik> #meetingtopic Weekly Meeting of the Modularity Team
15:01:51 <asamalik> #topic Roll Call
15:01:51 <asamalik> #chair sgallagh langdon contyk ignatenkobrain
15:01:51 <zodbot> Current chairs: asamalik contyk ignatenkobrain langdon sgallagh
15:01:51 <asamalik> .hello2
15:01:52 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:02:11 <ignatenkobrain> .hello2
15:02:12 <sgallagh> .hello2
15:02:12 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:02:16 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:33 <ignatenkobrain> I might be lagging due to being in train with poor inet connection
15:03:44 <asamalik> #topic Agenda
15:04:11 <asamalik> We don't have anything on the agenda today. Does anyone need to discuss something live?
15:04:28 * asamalik has nothing at this moment
15:04:31 <sgallagh> https://github.com/fedora-modularity/libmodulemd/issues/269 might be worth discussing
15:04:32 <asamalik> /me is also quite distracted with other stuff today :(
15:05:05 <sgallagh> same
15:05:54 <asamalik> #info libmodulemd: Redefine default branch for ref
15:06:32 <ignatenkobrain> that one kinda makes sense, but someone will have to fix existing modulemds
15:06:41 <asamalik> ok so let's try this one and see what happens
15:06:48 <asamalik> #topic libmodulemd: Redefine default branch for ref
15:06:48 <asamalik> #link https://github.com/fedora-modularity/libmodulemd/issues/269
15:07:38 <sgallagh> ignatenkobrain: Existing modulemds mostly have explicit refs
15:08:06 <sgallagh> So I'm not sure changing it will be much effort
15:08:26 <ignatenkobrain> sgallagh: just saying that somebody will need to do that :)
15:08:38 <asamalik> yeah it kind of makes sense..
15:09:15 <asamalik> since, with streams, there are multiple "masters" for each one
15:09:28 <asamalik> ... if that makes sense :)
15:09:32 <sgallagh> ignatenkobrain: Also if we make it fall back to master if the named branch doesn't exist, then we need not change anything
15:10:09 <asamalik> sgallagh: or should it fail if that branch doesn't exist? to prevent mistakes? people shouldn't consume master anyway
15:10:13 <asamalik> because that's rawhide
15:10:13 <ignatenkobrain> sgallagh: I am definitely against such "fallbacks"
15:10:23 <ignatenkobrain> because it makes everything much worse
15:10:40 <ignatenkobrain> asamalik: why people should not consume master branch?
15:11:01 <sgallagh> There's nothing wrong with consuming the master branch
15:11:11 <asamalik> ignatenkobrain: let me rephrase... I don't think people should use master branch for module builds, because master branch indicates it's a traditional package for fedora rawhide
15:11:22 <asamalik> at least that's my thinking
15:11:40 <asamalik> but maybe it's useful in some cases?
15:11:49 <sgallagh> I can see an argument for making the change all-or-nothing, but I prefer cleaner upgrade paths
15:12:08 <ignatenkobrain> asamalik: Yes, but if I don't build packages in rawhide, that means I can't use release-monitoring.org integration and such standard fedora development processes
15:12:12 <sgallagh> asamalik: I use it in several places because I know I will always need the latest version, so tracking what's in Rawhide makes sense.
15:12:18 <ignatenkobrain> asamalik: you probably never created big modules =)
15:12:43 <sgallagh> Then I just use the Rawhide version of my dep for my alternative streams on stable releases.
15:12:59 <sgallagh> (e.g. http-parser for Node.js)
15:13:16 <asamalik> ignatenkobrain: I'm just curious.. :) what if you have two streams that you want to use release-monitoring for?
15:14:11 <ignatenkobrain> asamalik: for crates (which are build-time only) I don't need that. but this is actually one of things which are not implemented in modularity world and I hope it will be at some point :)
15:14:27 <asamalik> but now I see some valid cases and I don't want to distract from the original topic
15:15:43 <asamalik> so I'd prefer taking the stream name over master, and don't have a strong preference if do/don't fall back to master
15:16:19 <sgallagh> I have a weak preference for falling back to master, if only to avoid breaking anyone's current behavior
15:16:42 <ignatenkobrain> what if you have incomplete repo cloned?
15:16:53 <asamalik> although... should that be dealt with on the libmodulemd level? or on the MBS level via config? so different distros could set different rules?
15:17:02 <ignatenkobrain> just one of branches, it will do something else from what you expected because it was incomplete at time of clone
15:17:08 <ignatenkobrain> IMO it should be explicit
15:18:46 <sgallagh> asamalik: None of this is at the libmodulemd level.
15:19:10 <sgallagh> libmodulemd merely ensures that the value is a YAML scalar if present. It does no other validation on it.
15:19:18 <sgallagh> It does not store it as "master" internally.
15:19:34 <sgallagh> That logic is currently implemented in MBS
15:19:47 <asamalik> sgallagh: ah cool, then I was just confused by where the bug was reported originally... it was a bit surprising I must admit :)
15:20:05 <sgallagh> asamalik: That's why I had them report it against fm-orchestrator in my comment :)
15:20:30 * asamalik needs more coffee :)
15:20:59 <sgallagh> asamalik: Since you get apparently random funding, why not head to Brazil? :-P
15:22:52 <sgallagh> anyway.
15:23:08 <sgallagh> Sounds like we pretty much all agree that the standard behavior should be to use the stream name.
15:23:13 <asamalik> sgallagh: lol, I wish
15:23:57 <asamalik> +1 to the stream name
15:24:28 <sgallagh> I'll open a slightly wider discussion on devel@ regarding this and what to do about the current behavior
15:24:45 <asamalik> makes sense
15:25:00 <sgallagh> e.g. do we do a mass-update to explicitly set it to master for anyone who has it blank or do we include the fallback?
15:26:34 <asamalik> yeah that sounds like a good question for the list... I expect the answer to be yes (if people even leave that empty)
15:27:02 <sgallagh> All of our packaging examples set it explicitly, so I doubt it's empty in many places.
15:27:26 <sgallagh> (I didn't even honestly know about the fallback; that portion of the spec predates libmodulemd)
15:27:58 <ignatenkobrain> I think discussing this on devel@ won't bring much because most of the people there don't use modularity (yet?)
15:29:06 <asamalik> ignatenkobrain: there are many topics that are not for *most* of the people there... and it's getting more and more popular :P
15:30:52 <sgallagh> ignatenkobrain: I don't have a better list for such a question, honestly
15:31:04 <sgallagh> Too many eyes > too few
15:32:20 <asamalik> it's definitely more visible than the ticket which is MBS-specific
15:32:33 <asamalik> and it targets the right group — fedora packagers
15:32:54 <asamalik> we don't have a dedicated modularity list anyway
15:33:04 <asamalik> so.. anything else here?
15:35:05 <sgallagh> I have nothing
15:35:58 <asamalik> #topic Next meeting's chair
15:36:10 <asamalik> #action langdon has volunteered to chair the next meeting
15:36:14 <asamalik> :)
15:36:19 <ignatenkobrain> I can do it
15:36:19 <asamalik> #topic Open floor
15:36:21 <ignatenkobrain> ah, okay :0
15:36:38 <asamalik> ah! next-next time ignatenkobrain?
15:36:52 <sgallagh> asamalik: Are we having next-next-time?
15:37:03 <sgallagh> That falls during Red Hat Summit, so I know most of us are unavailable
15:37:38 <asamalik> yeah good question
15:37:53 <asamalik> let's figure it out next time :)
15:38:24 <sgallagh> ack
15:38:44 <ignatenkobrain> asamalik: yes!
15:39:39 <asamalik> ignatenkobrain: cool!
15:39:52 <asamalik> anyway, I guess that's it for today
15:40:02 * asamalik leaves 60 sec before closing
15:41:07 <asamalik> #endmeeting