15:00:00 <contyk> #startmeeting modularity
15:00:00 <zodbot> Meeting started Tue Jun 25 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 'modularity'
15:00:02 <contyk> #meetingtopic Weekly Meeting of the Modularity Team
15:00:04 <contyk> #topic Roll Call
15:00:06 <contyk> #chair sgallagh langdon contyk ignatenkobrain
15:00:06 <zodbot> Current chairs: contyk ignatenkobrain langdon sgallagh
15:00:10 <contyk> .hello psabata
15:00:11 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:29 <langdon> .hello2
15:00:30 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
15:00:34 <ignatenkobrain> .hello2
15:00:36 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:00:59 <sgallagh> .hello2
15:01:00 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:15 <contyk> so last week we talked about going through the ticket queue
15:01:27 <contyk> I don't know about you but I only went through it quickly this morning :/
15:01:40 <contyk> the good news is there are many actionable or re-assignable tasks, it just needs to be done
15:02:01 <contyk> I labeled two tickets with the meeting tag but I don't expect to resolve them here, just to raise the awareness
15:02:03 <langdon> \o/
15:02:58 <contyk> ok, so starting with this one...
15:03:02 <contyk> #topic Redefine default for branch ref:
15:03:06 <contyk> .modularity 142
15:03:07 <zodbot> contyk: Issue #142: Redefine default for branch ref: - modularity - Pagure.io - https://pagure.io/modularity/issue/142
15:03:32 <contyk> the request here was to redefine the default value for component refs so that they are the same as the branch name of the module
15:03:53 <contyk> the goal is to make modulemds simpler and easier to move between streams
15:04:12 <contyk> I understand how it could benefit packagers but I wouldn't want to change the default in the format, personally
15:04:19 <sgallagh> I don't like implicit defaults like that.
15:04:27 <contyk> I think it would be a good idea to add an API call to MBS and define it in fedpkg
15:04:35 <sgallagh> I'd be more inclined to drop defaults at all and make the field mandatory instead
15:05:36 <contyk> I'd rather not do that, that would make the situation even worse
15:05:42 <sgallagh> contyk: What do you mean by "define it in fedpkg"
15:05:52 <contyk> it wouldn't address the problems the reporter is raising and would be an unnecessary format change
15:06:05 <sgallagh> contyk: Well, the current situation is "if you don't specify it, you get `master`", which is at least consistent, but unexpected.
15:06:13 <contyk> I mean that fedpkg could pass an argument to MBS, "if ref is undefined, make it this"
15:06:43 <contyk> so if I fork a module and all its components, I don't have to change the modulemd
15:06:45 <sgallagh> Hmm
15:06:48 <contyk> and redefine the refs everywhere
15:06:58 <contyk> which is something that happens in a certain distro every quarter
15:07:29 <sgallagh> It's a reasonable idea, but I'd prefer to have an explicit reserved-word instead.
15:07:58 <sgallagh> Since the spec *does* explicitly define what we expect from the field being not present.
15:08:24 <sgallagh> so `ref: __BRANCH_SPEC__` or something would be better in my mind.
15:08:49 <contyk> perhaps that could work
15:08:57 <ignatenkobrain> actually few days ago I wanted to build some module which would specify when it builds against platform:f29 to build package from f29 branch
15:09:09 <ignatenkobrain> so basically use "base" branches for the packages
15:09:28 <contyk> that's quite different but achievable with keywords like sgallagh is proposing
15:09:34 <ignatenkobrain> so probably having some "variables" would be useful afterall in mmd
15:10:15 <sgallagh> I'd prefer to discuss that idea as a separate topic though, since it is arguably producing entirely different content with the same stream name.
15:10:47 <contyk> you could say the same for MSE, in a way
15:11:16 <sgallagh> True, but the expectation of MSE is that it's still the same stream, just built against a different platform.
15:11:25 <sgallagh> If they're vastly different content, I'd call that a bug.
15:11:41 <sgallagh> But maybe that's the way to approach ignatenkobrain's idea too
15:11:44 <contyk> we could have that discussion in the ticket
15:11:55 <contyk> it feels like a major packager experience thing
15:12:03 <sgallagh> (Assume good faith and file bugs if the streams are significantly different depending on the platform)
15:12:08 <contyk> some of your concerns might be valid but we could explore that with examples
15:13:30 <ignatenkobrain> sgallagh: basically I was building an "RPM" as a module and since it was bumping soname I thought about rebuilding some other packages which depend on librpm... but I definitely did not want to pull rawhide versions everywhere
15:14:06 <contyk> ignatenkobrain's example is basically taking it a bit further
15:14:24 <contyk> and the original request was about forking a module with the same component list without changing anything
15:14:31 <sgallagh> ignatenkobrain: Yeah, okay. That's a completely reasonable request.
15:14:40 <contyk> so, should we have that discussion in the ticket?
15:15:01 <sgallagh> It sounds like those present mostly agree it's sensible.
15:15:18 <sgallagh> So maybe the discussion should proceed towards implementation?
15:15:44 <contyk> perhaps the reporter would like to add some more input
15:15:51 <contyk> but yes, I agree
15:15:56 <sgallagh> ack
15:15:57 <contyk> the variables are probably the way to go
15:16:23 <contyk> #info We would propose solving the use case with special modulemd variables; we will discuss this more in the ticket
15:16:46 <contyk> alright
15:16:49 <contyk> #topic What is the process to change default profile name with zero down time?
15:16:54 <contyk> .modularity 141
15:16:58 <zodbot> contyk: Issue #141: What is the process to change default profile name with zero down time? - modularity - Pagure.io - https://pagure.io/modularity/issue/141
15:18:02 <contyk> I think the solution outlined in the ticket is valid
15:18:16 <sgallagh> I don't like step 3
15:18:35 <sgallagh> Within a release, I think we should disallow *dropping* a profile entirely.
15:18:53 <sgallagh> Otherwise existing scripts may break
15:19:10 <langdon> sgallagh: +1
15:19:13 <sgallagh> So I think steps 1 and 2 are the right approach
15:19:30 <contyk> and step 3 is valid for rawhide but disallowed within a stable release?
15:19:39 <sgallagh> contyk: Yes
15:19:56 <langdon> be nice if we could have synonyms though
15:20:06 <contyk> we kinda can
15:20:21 <contyk> you can include the contents from one profile in another
15:20:25 <contyk> YAML
15:21:31 <langdon> i meant add two "labels" to common one....  profiles: \n default, common: \n rpms: or something
15:21:38 <sgallagh> Thinking about it, the process for Rawhide should probably be almost the reverse.
15:22:07 <contyk> langdon: it works almost like that, just a little uglier :)
15:22:34 <sgallagh> We don't really need to do two builds; just push the changed one to Rawhide and push the defaults update. If there's a disconnect, for a brief time DNF will just report "no such profile"
15:23:03 <contyk> yeah, but that's ugly and if we have some CI, it might break
15:23:04 <sgallagh> Although (sorry, thinking on my feet), this gets troublesome with MSE.
15:23:05 <langdon> ha
15:23:11 <contyk> and I hope we'll have some CI in place for this
15:23:38 <ignatenkobrain> I think you should not remove profiles in stream
15:23:41 <sgallagh> Because I assume Jun wants to use the same YAML for FN, FN-1 and Rawhide
15:23:57 <sgallagh> ignatenkobrain: That's kind of what I'm coming to, yeah
15:24:11 <contyk> yeah, hm
15:24:25 <sgallagh> Once a profile is specified, it remains for the life of the stream
15:24:38 <ignatenkobrain> sgallagh: +1
15:24:42 <x3mboy> .hello2
15:24:43 <zodbot> x3mboy: x3mboy 'Eduard Lucena' <eduardlucena@gmail.com>
15:24:44 <sgallagh> Well, maybe not.
15:25:07 <sgallagh> We can document a Rawhide-only approach that allows dropping one, but it means not using MSE for a while.
15:25:07 <langdon> sgallagh: it really should
15:25:23 <contyk> I'd rather keep it for the life of the stream
15:25:31 <sgallagh> Yeah, that's probably easier.
15:25:41 <contyk> it's safer and is aligned with the disconnected life cycles idea
15:25:45 <langdon> yeah.. once the stream is out of rawhide... the profiles should remain...
15:25:54 <sgallagh> But we have this as an option if we *really* needed it. (Like we found out someone was naming their profiles profanely or something)
15:25:55 <langdon> but defaults can change
15:26:08 <sgallagh> langdon: You misunderstood, I think.
15:26:11 <langdon> shoot sgallagh is on to me
15:26:21 <langdon> sgallagh: where?
15:26:48 <langdon> the "on to me" was in ref to profane profile names
15:26:52 <contyk> no distinction between rawhide and stable
15:26:52 <sgallagh> contyk and ignatenkobrain are saying that once a profile appears in a stream, it doesn't go away.
15:26:56 <contyk> just keep the profiles forever*
15:27:12 <langdon> yes.. i was agreeing with that.. when you seemed to be second guessing yourself
15:27:18 <sgallagh> I'm suggesting that there *is* a way we could allow a stream to drop a profile in Rawhide only, but it means a lot of manual work
15:27:25 <langdon> but which profile is default can change in any fedora release
15:27:31 <sgallagh> So it's an option if we have great need of it
15:27:37 <contyk> yeah, defaults are a different thing
15:27:42 <langdon> sgallagh: ohh yes.. i see
15:27:48 <langdon> or.. i agree..
15:28:37 <sgallagh> Essentially it means that you can't build the stream using MSE, you need to build it for stable and Rawhide independently, from different YAML.
15:28:43 <sgallagh> Let's not document this now, though.
15:29:05 <sgallagh> We'll default to "profiles must exist for the life of the stream" and worry about that case if we actually have a strong reason for it
15:32:10 <contyk> +1
15:32:17 <ignatenkobrain> +1
15:33:18 <contyk> proposed #agreed Profiles shouldn't be removed during the lifetime of the stream; if it's necessary, we can deal with it case by case
15:33:27 <sgallagh> Patch
15:34:21 <sgallagh> proposed #agreed Profiles cannot be removed during the lifetime of the stream in order to avoid breaking scripts. Options may exist for exceptional cases on an individual basis.
15:34:34 <contyk> sgallagh: +1
15:34:44 <langdon> i think it is too wordy
15:34:49 <sgallagh> .fire langdon
15:34:49 <zodbot> adamw fires langdon
15:35:00 <langdon> proposed #agreed Profiles cannot be removed during the lifetime of a stream.
15:35:18 <sgallagh> I don't want to lose the justification.
15:35:23 <langdon> why?
15:35:27 <sgallagh> I am open to dropping the exception.
15:35:36 <sgallagh> Because I don't want to have to re-explain it every three days.
15:36:22 <langdon> ok.. i don't see why it shouldn't be "streams dont change" .. but it is fine with me then
15:38:45 * contyk grumbles about being in three meetings at the same time
15:38:51 <langdon> ha
15:39:55 <contyk> so I'm still +1 to sgallagh's wordy proposal
15:40:02 <sgallagh> As am I
15:40:05 <langdon> and me
15:40:57 <contyk> okay
15:41:06 <contyk> #agreed Profiles cannot be removed during the lifetime of the stream in order to avoid breaking scripts. Options may exist for exceptional cases on an individual basis.
15:41:13 <contyk> alright
15:41:19 <contyk> #topic Next week's chair
15:41:26 <contyk> I won't be around next week
15:41:33 <langdon> !!!
15:41:41 <langdon> what will we do without you!
15:41:49 <contyk> party
15:41:53 <langdon> ha
15:42:33 <contyk> so, no volunteers?
15:42:56 <sgallagh> I can't commit to it, sorry.
15:42:57 <langdon> i can do it
15:43:07 <contyk> langdon++
15:43:13 <contyk> #action langdon will chair next week
15:43:15 * sgallagh unfires langdon
15:43:19 <langdon> took me a while to check.. cause I keep signing up and then having a conflict i forgot about :/
15:43:19 <contyk> #topic Open floor
15:43:24 <langdon> sgallagh: :P
15:43:37 <contyk> we really need to go through that queue of tickets :)
15:43:44 <contyk> but I can't see myself doing that this week :|
15:43:54 <contyk> at least we can do something about the two we discussed today
15:45:15 <x3mboy> Hi guys
15:45:37 * sgallagh nods
15:45:46 <sgallagh> x3mboy: You have something you'd like to discuss?
15:46:18 <x3mboy> As I stated before, I want to create an infographic about Modularity,
15:46:44 <x3mboy> So, I want to ask if https://docs.fedoraproject.org/en-US/modularity/ is the right place to create the base
15:47:02 <x3mboy> And from there you can add, modify or remove content
15:47:12 <langdon> x3mboy: "base"?
15:47:41 <x3mboy> Yes, I mean, I create a ticket to design with the content I want to put IN the inforgraphic
15:47:49 <x3mboy> And they create beatiful stuff
15:48:26 <x3mboy> e.g.: https://pagure.io/design/issue/647
15:49:58 <langdon> so.. im still confused about what "create the base" means.. like.. the docs you point to are accurate and current
15:50:00 <contyk> x3mboy: you should totally talk to asamalik
15:50:04 <contyk> but he's out this week
15:50:14 <langdon> is he back next week?
15:50:17 <contyk> should be
15:50:44 <langdon> x3mboy: did you file a modularity ticket? lets just put it on the agenda for next week's meeting..
15:50:54 <langdon> maybe tag asamalik in the ticket itself
15:51:21 <contyk> x3mboy: file a modularity ticket, too, so that langdon doesn't forget :)
15:51:35 <contyk> [to put it on the agenda]
15:52:05 <langdon> contyk: the design ticket is for server anyway..
15:54:25 <contyk> okaz
15:54:33 <contyk> anything else for the open floor?
15:55:44 <contyk> closing in 3
15:55:46 <contyk> 2
15:55:48 <contyk> 1
15:55:50 <contyk> #endmeeting