15:01:00 <nils> #startmeeting modularity_wg
15:01:00 <zodbot> Meeting started Tue Nov 27 15:01:00 2018 UTC.
15:01:00 <zodbot> This meeting is logged and archived in a public location.
15:01:00 <zodbot> The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:00 <zodbot> The meeting name has been set to 'modularity_wg'
15:01:00 <nils> #meetingtopic Weekly Meeting of the Modularity Working Group
15:01:01 <nils> #chair dgilmore
15:01:01 <zodbot> Current chairs: dgilmore nils
15:01:08 <nils> \o
15:01:15 <nils> #topic Roll Call
15:01:19 <contyk> .hello psabata
15:01:19 <nils> .hello nphilip
15:01:19 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:22 <nils> .hello nphilipp
15:01:22 <zodbot> nils: Sorry, but you don't exist
15:01:25 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:01:25 <bcotton> .hello2
15:01:28 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:02:13 <nils> #topic Agenda
15:02:44 <nils> #info [ignatenkobrain] #108 How do we keep rawhide sane? (re: forcing people to latest modules)
15:03:04 <nils> #info [asamalik] #112 Discussion: Module lifecycles
15:03:12 <asamalik> .hello2
15:03:13 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:03:17 * asamalik waves
15:03:28 <nils> #info [asamalik] #114 Stream default changes & Fedora Changes
15:03:32 <dgilmore> hi nils
15:03:49 <nils> #info [asamalik] #115 Discussion: Stream branch ownership for packages & modules
15:03:54 <nils> Anything else?
15:04:03 <asamalik> nothing else for me
15:04:25 <contyk> the frequency of this meeting?
15:04:29 <contyk> can leave that for the open floor
15:04:36 <nils> let's put it in
15:04:45 <nils> #info [contyk] the frequency of this meeting
15:04:54 <asamalik> ha +1
15:05:10 <nils> #topic How do we keep rawhide sane? (re: forcing people to latest modules)
15:05:21 <nils> #link https://pagure.io/modularity/issue/108
15:05:26 <nils> #chair ignatenkobrain
15:05:26 <zodbot> Current chairs: dgilmore ignatenkobrain nils
15:05:47 <asamalik> nils: I've added this one as a topic, even though ignatenkobrain originally opened that issue
15:05:53 <contyk> so I'm concerned about "module install" behaving differently depending on whether you specify the stream or not
15:05:56 <nils> scrolling to the bottom, it looks like this one could be wrapped up
15:05:59 <nils> #chair asamalik
15:05:59 <zodbot> Current chairs: asamalik dgilmore ignatenkobrain nils
15:06:11 <contyk> although I don't have a better proposal at this point
15:06:42 <asamalik> contyk: so I would argue it doesn't behave differently — although it depends how you look at it
15:06:53 <asamalik> if you ask it to install a specific stream, it does that
15:07:00 <contyk> and keeps that stream
15:07:00 <nils> contyk, maybe if we document it better that "no stream" means "default stream, not whatever happens to be default at the time"?
15:07:01 <asamalik> if you ask it to install the default stream, it does that
15:07:08 <asamalik> it remembers your choice during upgrade in both cases
15:07:22 <sgallagh> contyk: The best reply I can give is that we had a long discussion with UXD folks and this was the best solution we could find to maintaining users' preferences.
15:07:23 <asamalik> so I personally see it as consistent
15:07:27 <nils> asamalik, can you explicitly say "default stream"?
15:07:40 <sgallagh> nils: Yes, by not specifying a stream
15:07:45 <nils> like "dnf module install somemodule:default"?
15:07:46 <asamalik> nils: in that proposal no, you leave out the stream
15:07:53 <nils> sgallagh, yeah, that's implicitly :)
15:08:02 <nils> So let's document it
15:08:04 <sgallagh> nils: I disagree with that.
15:08:26 <sgallagh> If you aren't specifying the stream, you've made a choice that the stream isn't important to you
15:08:27 <contyk> yeah, that would be suboptimal
15:08:31 <nils> Leaving it out can just as well mean "I haven't thought about streams at all"
15:08:38 <contyk> plus there can be streams named "default" ;)
15:08:43 <nils> ugh yeah
15:08:54 <nils> this wasn't a proposal yaknow
15:09:15 <sgallagh> nils: And if theyhaven't, then  we can reasonably assume that it means they expect that whatever they get will work
15:09:33 <sgallagh> And if it doesn't... they can switch streams!
15:09:46 <nils> sgallagh, I'm actually concurring with you re reasonable assumptions
15:10:01 <nils> Let's skip the implicit vs. explicit semantics discussion :)
15:10:26 <contyk> so to me it feels like "I explicitly installed a module but then it changed, I wasn't expecting that", even if they didn't specify the stream
15:10:30 <sgallagh> Right, I'm just enumerating for the log why I think it's safe
15:10:36 <contyk> which is a bit different than installing the content with just "dnf install"
15:10:46 <sgallagh> contyk: Not really.
15:10:50 <asamalik> contyk: but that's what a major distro upgrade always did
15:10:57 <contyk> but I also understand it feels inconsistent if "dnf install" and "dnf module install" do different things
15:10:57 <nils> contyk, but it's the stream that changed, not the module
15:11:00 <contyk> and that you want to use profiles
15:11:01 <sgallagh> upgrading a major distro release often made incompatible changes
15:11:08 <sgallagh> You're getting the same behavior you always did
15:11:13 <contyk> yeah
15:11:18 <sgallagh> And can opt out of it by picking a stream explicitly
15:11:27 <asamalik> again, innovating without making changes :)
15:11:33 <contyk> but the difference is that I'm explicitly using the module command and modularity is supposed to give me that stability, you know :)
15:11:42 <contyk> compared to simple package installation
15:11:53 <asamalik> contyk: Modularity remembers your choice
15:11:55 <nils> BTW, can you opt back into having "no specified i.e. default stream"?
15:11:57 <asamalik> not gives you stability
15:11:58 <sgallagh> I'm pretty comfortable with this compromise
15:12:01 <asamalik> that's a very important distinction
15:12:35 <asamalik> you can choose a specific version stream, you can choose a "latest" stream, you can choose a default stream
15:12:43 <asamalik> remembering choices is the thing, not stability
15:12:51 <contyk> I understand your reasoning
15:12:56 <contyk> I'm just not comfortable with it
15:13:12 <contyk> I think you can look at it from the opposite side and it's just as reasonable
15:13:21 <sgallagh> I don't think it is, honestly.
15:13:34 <sgallagh> It puts too much on the end-user to understand when they have to switch modules
15:13:59 <sgallagh> As modules become more ubiquitous, the set of them that users specifically care about will be a smaller and smaller percentage of the whole
15:14:00 <contyk> so what happens if I do "dnf module enable nodejs"?
15:14:01 <asamalik> contyk: you could, but that would be a very different view than the one we already have in Fedora — major upgrades change versions
15:14:30 <sgallagh> contyk: Same as `dnf install nodejs` with an empty profile.
15:14:38 <nils> you get the nodejs module enabled at default stream
15:14:51 <contyk> ok, so I don't think that's mentioned anywhere in the ticket
15:14:57 <contyk> the ticket focuses on install
15:14:58 <asamalik> and then you have the question of "so you have a default stream... do you remember how did you install it, so the upgrade either keeps it or not?"
15:15:09 <asamalik> vs: you have a default, you keep a default
15:15:31 <sgallagh> contyk: I may have been unclear, but it's really the presence or absence of ":streamname" in any command that matter
15:15:34 <sgallagh> *matters
15:16:09 <asamalik> contyk: "Modules can be installed / enabled with a stream specified in one of the following three ways" <- it's there
15:16:11 <asamalik> sgallagh: +1
15:16:14 <contyk> yeah, I think I was explicitly asking about module commands locking the stream and you confirmed that but it might have changed since then
15:16:47 <asamalik> contyk: that was original sgallagh's proposal, I've tweaked it a little bit, and it turned out that's what we both wanted
15:16:59 <sgallagh> asamalik: +1
15:17:08 <contyk> I'm not going to vote on this
15:17:45 <sgallagh> langdon: Do you have any thoughts on the matter?
15:17:53 <asamalik> contyk: what would make you vote on this? :)
15:18:07 * sgallagh is kind of surprised langdon hasn't chimed in at some point before this
15:19:43 <contyk> being comfortable with it
15:20:04 <contyk> I don't like either of the proposals and feel like we could do something better, even though I don't have anything specific
15:20:10 <contyk> (I would have proposed it otherwise)
15:20:19 <contyk> and decisions like this can't be easily changed later
15:20:21 <ignatenkobrain> .hello2
15:20:23 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:20:29 <ignatenkobrain> sorry, I had some $dayjob to finish
15:20:56 <contyk> so I'm not going to block you guys if you feel strongly that this is the best thing to do
15:21:00 <contyk> but I can't support it either :)
15:21:06 <ignatenkobrain> contyk: what exactly you don't like in proposals?
15:21:26 <sgallagh> contyk: I do, honestly. It still gives anyone who wants to behave as you describe the option to do so, simply by adding :streamname
15:21:42 <asamalik> contyk: I do.
15:21:48 <sgallagh> I don't think that's a tremendous amount of overhead
15:21:58 <asamalik> and it's a well-known syntax from the container world for example
15:22:06 <asamalik> podman run fedora vs. podman run fedora:29
15:22:23 <nils> If either option bears a certain risk to surprise users, I don't see a way around choosing one and documenting it.
15:22:42 <sgallagh> Right, and I think this approach will provide the least surprise.
15:23:03 <sgallagh> Remember that our users do not yet have *any* real experience with an upgrade of modules
15:23:26 <sgallagh> So modeling the experience around the existing upgrade experience seems to me to be the least-surprising solution
15:23:43 <sgallagh> While offering them a powerful alternative to avoid breakage on their critical apps
15:23:43 <asamalik> +1
15:23:52 <nils> Especially if we document it the right way. E.g. "if you don't specify a stream, the respective default one will be used. If you upgrade your OS, this default can change and will be followed."
15:24:10 <stickster> sgallagh: asamalik: Would a more frequent release cycle for Fedora -- like a platform update every month or even every week -- change your feelings about this approach at all?
15:24:33 <nils> I don't think so.
15:24:34 <sgallagh> stickster: I think this is compatible with that.
15:24:40 <asamalik> stickster: it would make them even stronger
15:24:52 <sgallagh> stickster: Even if the platform updates, I doubt very much that the default streams would change with the same frequency.
15:25:04 <stickster> sgallagh: I would tend to doubt that too
15:25:21 * stickster with the caveman questions ;-)
15:25:25 <sgallagh> Though if we start having default streams for core bits... then this would definitely help
15:25:35 <nils> Just a gut feeling, the more we move to modules, the more it will be a majority of modules where users will want to follow the default and just a select set where they want to lock the stream.
15:25:38 <contyk> ignatenkobrain: I put it in the ticket; it depends on how you look at it, which I find problematic
15:25:46 <sgallagh> So yeah, I agree with asamalik. If our platforms start coming faster, this would help a LOT
15:25:53 <asamalik> yes, I'll just lazily edit my message to: what sgallagh says :)
15:26:13 <asamalik> I mean the one I was just typing saying the same thing :)
15:26:20 <stickster> We should probably also consider the case of a long-term release -- I'm not sure that *weakens* this proposal, either
15:26:30 <sgallagh> asamalik: You agree that I agree with you, then? :)
15:26:31 <asamalik> stickster: also very compatible
15:26:49 <contyk> so in essence, the frequency of releases doesn't matter :)
15:26:59 <asamalik> sgallagh: I agree with you statement about me agreeing about agreeing with you that we both agree, agreed!
15:27:13 <ignatenkobrain> contyk: I agree with you that same command with different arguments producing different result is not reallynice
15:27:19 <sgallagh> stickster: In the case of a long-term release, I think it's mostly irrelevant. We don't want to have mid-release default-stream changes. So this would just be less frequent.
15:27:25 <nils> stickster, a long term release won't have changing defaults, so is kinda skidding by the problem :)
15:27:44 <stickster> *nod, feels like the long-term release is more of a non-issue
15:27:52 <asamalik> stickster: still the same mechanics: choose "the default stream" for the current experience, or "a specific stream" for keeping the stream
15:28:07 <asamalik> respecting your choices in both scenarios while being compatible with the current way of things
15:28:31 <ignatenkobrain> just to clarify:
15:28:45 <ignatenkobrain> do we all agree that implicitly enabled streams can be swapped without any special command?
15:29:07 <asamalik> ignatenkobrain: yes if the RPMs allow it
15:29:20 <ignatenkobrain> obviously
15:29:26 <sgallagh> ignatenkobrain: With the obvious proviso that it has to fail if it would introduce dependency errors, sure.
15:29:29 <contyk> I proposed to make that behavior configurable but sgallagh disagreed
15:29:33 <ignatenkobrain> except that DNF doesn't check that at all and is considered as a right behaviour
15:29:54 <ignatenkobrain> .bug 1636711
15:29:55 <zodbot> ignatenkobrain: Bug 1636711 – Switching module streams doesn't do anything useful - https://bugzilla.redhat.com/1636711
15:29:56 <asamalik> contyk: I would disagree as well, that would cause inconsistent behaviors.
15:29:57 <ignatenkobrain> but that's different topic
15:30:16 <contyk> it would behave depending on your configuration
15:30:17 <asamalik> ignatenkobrain: current vs. expected behavior — we're talking about the expected here :)
15:30:29 <sgallagh> ignatenkobrain: The DNF team agrees that's an issue, last I spoke to them, but they're viewing it as a new feature (which is fair) and is on their radar but not immediate.
15:30:45 <sgallagh> The outcome of this decision would help influence that, I believe
15:31:01 <asamalik> yes
15:31:02 <ignatenkobrain> what if we make compromise? anything which is installed explicitly will keep stream unlocked and htere would be `--lock` which would lock module to stream?
15:31:17 <sgallagh> ignatenkobrain: We can't actually use --lock for complicated reasons.
15:31:30 <sgallagh> (That terminology has a strict meaning in RHEL errata)
15:31:31 <asamalik> ignatenkobrain: I really don't like the "lock" and "unlock" terminology here... I've just put a comment in the ticket about that.
15:31:35 <contyk> ignatenkobrain: that wouldn't be good
15:31:52 <contyk> ignatenkobrain: you could install nodejs:8 without --lock and then upgrade would switch you to the current default stream
15:31:53 <asamalik> I want to talk about it as what stream you have installed: "the default" or "a specific one"
15:32:10 <ignatenkobrain> a specific default one ;)
15:32:30 <sgallagh> asamalik: He's specifically talking about dependencies of the one we selected, I think
15:32:42 <asamalik> I mean, what DNF remembers is "the default" or "a specific one"
15:32:54 <stickster> contyk: That almost sounds like it makes the case for the proposed syntax, though :-)
15:33:09 <contyk> stickster: yes, which mans --lock is pointless
15:33:17 <asamalik> contyk: +1
15:33:23 <nils> From a UX POV, I don't see if you don't know what stream default is (then you could specify it), that you can say you want to stay "locked" on it
15:33:58 <sgallagh> The usage there would just be `dnf module install nodejs` and then later `dnf module enable nodejs:8` and now you're "locked"
15:34:01 <nils> So I don't see a huge benefit to add an option to "lock the default stream without having to know what it is"
15:34:04 <contyk> yeah, something like "module install --lock nodejs", which would lock you to whatever the default is, is more interesting
15:34:16 <contyk> it's basically like specifying the stream
15:34:18 <asamalik> nils: like "I don't know what I have but I want to keep it?" that sounds... strange to me :)
15:34:29 <contyk> but it's even more complicated
15:34:36 <asamalik> contyk: that's so confusing to me
15:34:41 <nils> asamalik, exactly, that's why I think such an option has no huge benefit except to confuse people :)
15:34:47 <contyk> asamalik: yes, it is even worse
15:35:04 <sgallagh> I think the point here though is that you may not have the information at install-time whether you will want to be upgraded to the next version or not until later.
15:35:14 <asamalik> so that's why I *do not* want to use the words "locked" and "unlocked"
15:35:21 <sgallagh> So we *do* have to consider how users would "lock" to a stream at a later point.
15:35:23 <ignatenkobrain> just to remind you why I created that ticket
15:35:31 <ignatenkobrain> new defaults appeared in rawhide and I did dnf update
15:35:32 <contyk> sgallagh: with enable or install
15:35:38 <ignatenkobrain> it enabled few streams for me
15:35:47 <asamalik> sgallagh: yes, just using the install command, specifying the stream
15:35:47 <ignatenkobrain> then when I changed default, it didn't update to it
15:35:51 <sgallagh> contyk: Yes, I agree with that. I'm just making sure we state that explicitly.
15:35:55 <ignatenkobrain> myself I didn't explicitly enable any stream
15:35:58 <asamalik> or "going from the default to a specific stream"
15:36:28 <nils> I think it's more worthwhile to get shell expansion for module name[:stream]
15:36:45 <contyk> nils: shell expansion?
15:36:47 <contyk> completion?
15:36:51 <nils> um yeah
15:36:58 <asamalik> do we wanna try voting and see what happens?
15:37:06 <contyk> sure
15:37:24 <sgallagh> asamalik: We'll probably have Russian interference in the voting process :-P
15:37:39 <asamalik> so +1 +0 -1 it is?
15:37:46 <nils> 👍
15:37:59 <sgallagh> asamalik: Restate the proposal for the record, please?
15:38:12 <asamalik> ok
15:38:43 <stickster> +1 on shell completion (I know that's not the vote coming up, I'm silent there) ;-)
15:39:12 <contyk> stickster: dnf already has bash/zsh completions, so we could just extend that
15:39:17 <sgallagh> Yeah. nils: is there a BZ on shell-completion?
15:39:21 <stickster> *nod
15:39:30 <langdon> shoot.. Sorry all.. am afk today and lost track of time
15:39:39 <nils> sgallagh, not that I know but I can open one
15:39:49 <nils> but let's vote on this first
15:39:54 <sgallagh> langdon: Just in time to wreck the vote! ;-)
15:40:04 <nils> don't give him ideas
15:40:05 <asamalik> The comment in the following URL is the proposal we vote on. Simplified, "dnf module install nodejs" installs the default streams, and keeps the default stream during a major system upgrade. "dnf module install nodejs:8" installs the speicfic stream 8, and keeps the specific stream 8 during a system upgrade. It's either "give me the default" or "give me a specific stream" and remember my choice.
15:40:07 <langdon> nice!
15:40:07 <asamalik> https://pagure.io/modularity/issue/108#comment-539882
15:40:13 <langdon> .hello2
15:40:14 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
15:40:20 <nils> I don't want the topic to resurface next week :)
15:40:39 <sgallagh> asamalik: +1
15:40:42 <asamalik> +1
15:40:47 <nils> +1
15:40:51 <langdon> +1!
15:40:55 <contyk> "keeps the default streams" feels a bit misleading
15:40:59 <contyk> even though I know what you mean
15:41:04 <langdon> sorry to let you down ;)
15:41:05 <asamalik> sorry "keeps the default stream"
15:41:05 <contyk> still, I abstain
15:41:07 <asamalik> typo
15:41:14 <sgallagh> "Tracks changes in the default stream" would be better phrased, I think
15:41:23 <langdon> "follows any new default"
15:41:32 <langdon> yours might be better
15:41:44 <asamalik> yes, the proposal speicfically says "If a user doesn't specify a stream, they get the default stream and they will stay on a default stream during a major distro upgrade — potentially switching to a new default stream."
15:41:47 <nils> as long as we all know what we voted for or against :)
15:41:51 <ignatenkobrain> +0 after rethinking what contyk said
15:42:56 <nils> I see only votes for and abstentions, the votes for outnumbering the abstentions 2:1. So we're agreed.
15:43:00 <asamalik> 4 +1s, 2 +0s, 0 -1s so far
15:43:11 <langdon> ignatenkobrain: on the wording or the concept?
15:43:43 <ignatenkobrain> langdon: concept, that `install nodejs` and `install nodejs:8` will do different things even nodejs:8 is default
15:43:57 <contyk> langdon: I'm not against the concept, I just have doubts about the proposed implementation
15:44:09 <ignatenkobrain> for instance, we don't do it for rpms
15:44:17 <nils> --> #agreed if users don't specify a stream, the will get the current default one which, on upgrade of the system, can be changed if the default changes. <-- ?
15:44:26 <ignatenkobrain> when user types install foo-1-1.x86_64, we do upgrade it to foo-2-1 when time comes
15:44:28 <asamalik> ignatenkobrain: yes, because what if you want to keep 8 that's accidentally a default, too? you need to make that distinction
15:44:29 <sgallagh> ignatenkobrain: RPMs don't have streams...
15:44:31 <langdon> Ahh.. I see.. I understand the concern but think all other chooses are worse :)
15:44:31 <nils> (I'm only asking for wording here.)
15:44:49 <sgallagh> langdon: Yeah, my thoughts exactly
15:45:08 <asamalik> it's the same as in containers (I've said that before when langdon wasn't here) "podman run fedora" vs. "podman run fedora:29"
15:45:11 <ignatenkobrain> asamalik: what about ...?
15:45:19 <ignatenkobrain> add artificial "default" stream
15:45:31 <ignatenkobrain> and then install nodejs == install nodejs:default
15:45:39 <sgallagh> ignatenkobrain: We discussed that above. A stream named "default" may actually exist.
15:45:45 <nils> with the current workload on the DNF team, any wagers when we'll get that feature?
15:45:54 <langdon> Asamalik but then it never upgrades w/o user action ;)
15:46:12 <contyk> nils: f31
15:46:21 <contyk> so early 2020
15:46:31 <nils> langdon, I would hope my system doesn't upgrade without action on my behalf. *pats his pets*
15:46:50 <langdon> ha
15:46:57 <nils> Also, we have another <15 mins.
15:47:18 <contyk> I can say for sure this will not land in f30
15:47:22 <sgallagh> I think it's clear that we're not going to get consensus, but we do have a +4 vote.
15:47:23 <nils> Any last minute changes to the wording before I log this in?
15:47:27 <contyk> and f30 will have extra long life
15:47:52 <asamalik> all right, we have a consensus, let's do the #agreed thing and move on? we're not deciding about the target release here
15:47:59 <ignatenkobrain> contyk: that's still undecided ;)
15:48:05 <contyk> ;)
15:48:15 <nils> asamalik, concur
15:48:38 <asamalik> I want the other one voted on as well
15:48:55 <nils> --> #agreed if users don't specify a stream, they will get the current default one which, on upgrade of the system, will track the respective new default. <--
15:49:00 <nils> any objections against the wording?
15:49:03 <nils> 5
15:49:04 <nils> 4
15:49:06 <nils> 3
15:49:07 <nils> 2
15:49:08 <contyk> can you include the votes?
15:49:10 <nils> 1
15:49:12 <nils> sure
15:49:38 <asamalik> nils: I would mention the comment, as it describes it in more detail: https://pagure.io/modularity/issue/108#comment-539882
15:49:56 <asamalik> so it' clear, for example to the DNF team, what the actual proposal is
15:50:01 <nils> --> #agreed 4 votes for, 2 abstentions, 0 against: if users don't specify a stream, they will get the current default one which, on upgrade of the system, will track the respective new default. <--
15:50:03 <asamalik> although we're likely to document it
15:50:10 <asamalik> so might not be necessary :)
15:50:16 <asamalik> nils: +1
15:50:21 <nils> yeah but that doesn't have to go in the agreed line
15:50:33 <asamalik> right, I've just realized that
15:50:35 <nils> #agreed 4 votes for, 2 abstentions, 0 against: if users don't specify a stream, they will get the current default one which, on upgrade of the system, will track the respective new default.
15:50:53 <nils> #link https://pagure.io/modularity/issue/108#comment-539882 detailed proposal
15:50:56 * contyk prefers the condensed way of expressing the votes but that's fine
15:50:59 <contyk> ack
15:51:05 <nils> next
15:51:10 <asamalik> \o/
15:51:25 <nils> #topic Discussion: Module lifecycles
15:51:43 <nils> #link https://pagure.io/modularity/issue/108#comment-539882
15:51:47 <nils> oops
15:51:48 <nils> #undo
15:51:48 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fe4fef82490>
15:51:54 <contyk> this is one I haven't managed to read yet
15:51:55 <asamalik> nils: ah no this one, I meant the "changing defaults vs. fedora changes"
15:51:58 <nils> #link https://pagure.io/modularity/issue/112
15:52:03 <nils> #undo
15:52:03 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fe4fd8ee450>
15:52:03 * contyk looks
15:52:06 <nils> #undo7
15:52:08 <nils> #undo
15:52:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7fe4fca8fd90>
15:52:28 <nils> #topic Stream default changes & Fedora Changes
15:52:35 <asamalik> nils: thanks!
15:52:36 <nils> #link https://pagure.io/modularity/issue/114
15:52:44 <nils> quick, quick! :)
15:52:45 <asamalik> so, any comments or concerns or can we go straight to the vote for this one?
15:53:04 <contyk> I added a comment to this one
15:53:22 <asamalik> contyk: ah right!
15:53:29 <nils> concur with the proposal plus contyk's comment
15:53:40 <ignatenkobrain> I +1 all contyk points
15:53:56 <asamalik> I'd say adding new defaults nor replacing anything is OK — it's like adding a new package
15:53:59 <ignatenkobrain> that's essentially what I have tried to do with libgit2 in F29
15:54:20 <nils> the proposal implies it but it should be explicit that defaults _added_ shouldn't need a change
15:54:22 <asamalik> I'd be careful with replacing traditional packages with modules mid-release at this point
15:54:31 <langdon> on contyk's comment, non-modular to modular in existing stable *must* have a default stream of the non-modular version
15:54:38 <contyk> nils: it only talks about future releases, rather explicitly
15:54:48 <contyk> langdon: why?
15:54:52 <nils> asamalik, I think it's okay if the module-stream is "the same thing", i.e. no material change just where content comes from
15:54:54 <contyk> langdon: the non-modular package isn't going anywhere
15:55:10 <langdon> Ohh.. what?
15:55:23 <asamalik> contyk: ah! that's what I didn't get
15:55:25 <contyk> you can keep the non-modular package and just add streams
15:55:27 <asamalik> then yes, +1 to both
15:55:32 <langdon> definitely not how I read the 2nd graph
15:55:36 <contyk> the streams don't have to be default but can be
15:55:38 <asamalik> but that has nothing to do with defaults :)
15:55:40 <ignatenkobrain> contyk: except for the buildroot. where UM should help us
15:56:13 <asamalik> adding non-default streams is not changing defaults
15:56:27 <contyk> true
15:57:14 <contyk> okay, so we could allow adding defaults to stable releases for modularized content if those defaults don't introduce significant changes
15:57:25 <langdon> can someone write a new, full proposal in the ticket?
15:57:43 <contyk> like modularizing non-modular nodejs-8 and making nodejs:8 the defualt in a stable release would be okay, making nodejs:10 the default in a stable release would not
15:57:52 <sgallagh> If a user wants to move from ursine to module in a release, they can, but should have to verify that the new stream meets the stable updates policy for the original rpm.
15:58:00 <nils> while technically adding a default which is "the same" as the existing ursine content could be permissible, I don't see the point for Fedora really, just drag ursine around for the remainder of the release and be done with it
15:58:06 <asamalik> this is about introducing incompatibilities
15:58:13 <ignatenkobrain> contyk: yes, but we need UM
15:58:19 <asamalik> and submitting changes in order to communicate incompatibilities
15:58:34 <asamalik> if something doesn't introduce an incompatibilities, there is no change
15:58:35 <contyk> ignatenkobrain: yes, agreed
15:58:50 <langdon> contyk also modularizing 8, removing the rpms, in a stable release would also be not cool
15:58:51 <contyk> nils: my only concern is that the maintainer will stop paying attention to the ursine package after modularizing the content
15:58:59 <asamalik> langdon: +1
15:59:09 <contyk> langdon: you can't remove them
15:59:12 <asamalik> but that's out of scope of this proposal
15:59:19 <sgallagh> langdon: I assumed we meant they would be filtered not removed.
15:59:51 <asamalik> ok, so looks like we'll give this one two more weeks :)
15:59:56 <langdon> ok.. I think this needs clarification in the proposal.. I'm not sure we are all even clear on the idea
16:00:05 <nils> contyk, maintainers stop paying attention to their maintained content all the time (chastising my own self here ;))
16:00:25 <contyk> proposal: Reword the proposal considering stable releases in the ticket and let's revisit this next time
16:00:25 <asamalik> anyone up to writing that clarification?
16:00:39 <nils> contyk, +1
16:00:45 <ignatenkobrain> if we have UM, then it's not a problem anymore because modular version will be in buildroot and on user systems
16:00:51 <ignatenkobrain> so there is no problem in doing so I think
16:01:02 <contyk> ignatenkobrain: yeah, but UM is still an unresolved topic atm
16:03:48 <langdon> so.. who is volunteering?
16:03:49 <contyk> are we dead?
16:03:56 <nils> I aten't ded yet
16:04:05 <contyk> I assume that means you agree with the proposal?
16:04:06 <langdon> I heard UM can revive you...
16:04:14 <nils> asamalik, shall we bang our heads together tomorrow morning about the clarified wording?
16:04:39 <asamalik> so it already says "Module stream defaults should be only changed in an upcoming Fedora release" and it's about changing streams, not introducing new ones, so I think it's complete
16:04:50 <contyk> ignatenkobrain: please add the note about the need for UM in that specific scenario to the ticket
16:04:51 <nils> I have a call after this meeting, so can't do it today (I guess)
16:05:21 <contyk> asamalik: considering the discussions before f29, I don't think it's clear at all
16:05:34 <ignatenkobrain> contyk: ack
16:05:51 <nils> asamalik, but we don't announce every package version upgrade in a change yet, not saying we shouldn't :)
16:06:03 <asamalik> nils: all right, action me to fix it
16:06:20 <asamalik> nils: that's exactly what the proposal says :)
16:06:29 <asamalik> nils: "Changes of stream defaults should be communicated by a Fedora Change based on the change's significance and its maintainer's best judgement."
16:06:42 <nils> right, spotted the wildcard :D
16:06:54 <contyk> I think it's great for the future releases, it should just be explicit when it comes to defaults in stable
16:06:55 <nils> #action asamalik (and nils) clarify the proposal in time for next WG meeting
16:07:31 <nils> given what we have left on the agenda, I don't think we need to tweak the mtg frequency just now...
16:07:54 <contyk> I was going to propose having the meeting every week
16:08:00 <nils> aah!
16:08:02 <langdon> ha
16:08:06 <nils> in that case, let's
16:08:20 <nils> #topic the frequency of this meeting
16:08:22 <nils> #chair contyk
16:08:22 <zodbot> Current chairs: asamalik contyk dgilmore ignatenkobrain nils
16:08:30 <contyk> so, yeah
16:08:36 <langdon> we should do the rule changes for the WG asap too
16:08:53 <contyk> I think we have plenty of topics and not enough time to discuss them all; there's also a potential of getting more and more with the new objective
16:09:01 <nils> yeah, but let's put that on next week's agenda (<- see what I did there?)
16:09:08 <nils> langdon, ^^
16:09:10 <langdon> ha
16:09:10 <contyk> I would therefore propose meeting every week, replacing the "office hours" slot with a proper WG meeting
16:09:24 <ignatenkobrain> contyk: I've put updated text in last ticket
16:09:30 <contyk> ignatenkobrain: thanks
16:09:32 <nils> yeah, office hours wasn't very frequented anyway, people should hit us up on IRC whenever
16:09:40 <ignatenkobrain> contyk: was that objective already accepted?
16:09:53 <asamalik> contyk: +1
16:09:54 <contyk> I would also propose sending our agenda to devel@ at least one day before the meeting, plus summary afterwards
16:09:55 <nils> contyk, +1 to that proposal
16:10:01 <langdon> +1
16:10:11 <nils> contyk, that's assuming the agenda is ready by that time :)
16:10:39 <langdon> ha
16:10:52 <contyk> ignatenkobrain: yes, afaik, although stickster can confirm
16:11:05 * stickster reads back
16:11:07 <nils> given that fedocal failed to send out the meeting invites for the last three months anyway, we can switch to manual invites and include the agenda
16:11:13 <nils> (IMO)
16:11:21 <asamalik> +1 about the agenda
16:11:22 <stickster> contyk: ignatenkobrain: yes, confirmed -- the Lifecycle objective was approved by council
16:11:42 <contyk> nils: the agenda can be changed; it works for fesco, for instance
16:12:10 <langdon> sorry y'all.. I have to run
16:12:13 <contyk> but mailing the list of topics draws attention and gives people time to prepare
16:12:18 <nils> contyk, I have no objections holding a meeting where the agenda isn't on the agenda so to speak :)
16:12:22 <nils> langdon, see ya
16:12:24 <asamalik> yes, it worked this time :)
16:12:30 <asamalik> and doing it even earlier would be better
16:13:21 <nils> so, proposal #1: meet every week, ditch "office hours", #2: "send out agenda 1 day in advance to devel@lists.fp.o"
16:13:25 <contyk> ok, so we all agree here? every week, agenda mails at least a day before?
16:13:33 <contyk> nils: +1
16:13:37 <nils> +1 on both from me
16:13:41 <asamalik> nils: +1 +1
16:13:45 <stickster> +1 +1
16:13:58 <contyk> proposed #action Nils will edit the calendar event
16:14:04 <asamalik> who mails the agenda?
16:14:08 <langdon> +1
16:14:22 <contyk> good question; usually it's the chair
16:14:27 <contyk> which is always nils here
16:14:34 <nils> #action nils will edit the calendar event
16:14:36 <asamalik> is nils the chair always? or do we wanna rotate like in FESCo?
16:14:48 <nils> I'm rotating alright as it is :)
16:14:58 <langdon> he got suckered in a long time ago
16:15:01 <contyk> asamalik: that might be something to change as we propose/implment new rules for the WG, as langdon was saying
16:15:29 * asamalik is fine with nils mailing the agenda forever :P
16:15:42 <contyk> nils might get hit by a bus
16:15:43 <nils> I need to script that
16:16:03 <langdon> I think it needs Easter eggs
16:16:15 <nils> let's cross that... crosswalk when we get to it
16:16:28 <nils> langdon, don't give me ideas :)
16:17:10 * stickster notes we're 77min in and counting here
16:17:34 <langdon> u just wanted to say 77
16:17:42 <nils> #agreed 5 votes for, 0 abstentions or against: hold the WG meeting every week and send out the agenda 1 day in advance to the devel mailing list
16:18:02 <contyk> yay
16:18:07 <asamalik> wheeee!
16:18:19 <asamalik> so about the composes, I wanted to ask... :) kidding, bye!
16:18:24 <nils> #info the remaining agenda items are postponed to next meeting, next week: #112, #115
16:18:34 <nils> thanks everybody!
16:18:37 <nils> #endmeeting