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