15:01:00 #startmeeting modularity_wg 15:01:00 Meeting started Tue Nov 27 15:01:00 2018 UTC. 15:01:00 This meeting is logged and archived in a public location. 15:01:00 The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:00 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:01:00 The meeting name has been set to 'modularity_wg' 15:01:00 #meetingtopic Weekly Meeting of the Modularity Working Group 15:01:01 #chair dgilmore 15:01:01 Current chairs: dgilmore nils 15:01:08 \o 15:01:15 #topic Roll Call 15:01:19 .hello psabata 15:01:19 .hello nphilip 15:01:19 contyk: psabata 'Petr Šabata' 15:01:22 .hello nphilipp 15:01:22 nils: Sorry, but you don't exist 15:01:25 nils: nphilipp 'Nils Philippsen' 15:01:25 .hello2 15:01:28 bcotton: bcotton 'Ben Cotton' 15:02:13 #topic Agenda 15:02:44 #info [ignatenkobrain] #108 How do we keep rawhide sane? (re: forcing people to latest modules) 15:03:04 #info [asamalik] #112 Discussion: Module lifecycles 15:03:12 .hello2 15:03:13 asamalik: asamalik 'Adam Samalik' 15:03:17 * asamalik waves 15:03:28 #info [asamalik] #114 Stream default changes & Fedora Changes 15:03:32 hi nils 15:03:49 #info [asamalik] #115 Discussion: Stream branch ownership for packages & modules 15:03:54 Anything else? 15:04:03 nothing else for me 15:04:25 the frequency of this meeting? 15:04:29 can leave that for the open floor 15:04:36 let's put it in 15:04:45 #info [contyk] the frequency of this meeting 15:04:54 ha +1 15:05:10 #topic How do we keep rawhide sane? (re: forcing people to latest modules) 15:05:21 #link https://pagure.io/modularity/issue/108 15:05:26 #chair ignatenkobrain 15:05:26 Current chairs: dgilmore ignatenkobrain nils 15:05:47 nils: I've added this one as a topic, even though ignatenkobrain originally opened that issue 15:05:53 so I'm concerned about "module install" behaving differently depending on whether you specify the stream or not 15:05:56 scrolling to the bottom, it looks like this one could be wrapped up 15:05:59 #chair asamalik 15:05:59 Current chairs: asamalik dgilmore ignatenkobrain nils 15:06:11 although I don't have a better proposal at this point 15:06:42 contyk: so I would argue it doesn't behave differently — although it depends how you look at it 15:06:53 if you ask it to install a specific stream, it does that 15:07:00 and keeps that stream 15:07:00 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 if you ask it to install the default stream, it does that 15:07:08 it remembers your choice during upgrade in both cases 15:07:22 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 so I personally see it as consistent 15:07:27 asamalik, can you explicitly say "default stream"? 15:07:40 nils: Yes, by not specifying a stream 15:07:45 like "dnf module install somemodule:default"? 15:07:46 nils: in that proposal no, you leave out the stream 15:07:53 sgallagh, yeah, that's implicitly :) 15:08:02 So let's document it 15:08:04 nils: I disagree with that. 15:08:26 If you aren't specifying the stream, you've made a choice that the stream isn't important to you 15:08:27 yeah, that would be suboptimal 15:08:31 Leaving it out can just as well mean "I haven't thought about streams at all" 15:08:38 plus there can be streams named "default" ;) 15:08:43 ugh yeah 15:08:54 this wasn't a proposal yaknow 15:09:15 nils: And if theyhaven't, then we can reasonably assume that it means they expect that whatever they get will work 15:09:33 And if it doesn't... they can switch streams! 15:09:46 sgallagh, I'm actually concurring with you re reasonable assumptions 15:10:01 Let's skip the implicit vs. explicit semantics discussion :) 15:10:26 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 Right, I'm just enumerating for the log why I think it's safe 15:10:36 which is a bit different than installing the content with just "dnf install" 15:10:46 contyk: Not really. 15:10:50 contyk: but that's what a major distro upgrade always did 15:10:57 but I also understand it feels inconsistent if "dnf install" and "dnf module install" do different things 15:10:57 contyk, but it's the stream that changed, not the module 15:11:00 and that you want to use profiles 15:11:01 upgrading a major distro release often made incompatible changes 15:11:08 You're getting the same behavior you always did 15:11:13 yeah 15:11:18 And can opt out of it by picking a stream explicitly 15:11:27 again, innovating without making changes :) 15:11:33 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 compared to simple package installation 15:11:53 contyk: Modularity remembers your choice 15:11:55 BTW, can you opt back into having "no specified i.e. default stream"? 15:11:57 not gives you stability 15:11:58 I'm pretty comfortable with this compromise 15:12:01 that's a very important distinction 15:12:35 you can choose a specific version stream, you can choose a "latest" stream, you can choose a default stream 15:12:43 remembering choices is the thing, not stability 15:12:51 I understand your reasoning 15:12:56 I'm just not comfortable with it 15:13:12 I think you can look at it from the opposite side and it's just as reasonable 15:13:21 I don't think it is, honestly. 15:13:34 It puts too much on the end-user to understand when they have to switch modules 15:13:59 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 so what happens if I do "dnf module enable nodejs"? 15:14:01 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 contyk: Same as `dnf install nodejs` with an empty profile. 15:14:38 you get the nodejs module enabled at default stream 15:14:51 ok, so I don't think that's mentioned anywhere in the ticket 15:14:57 the ticket focuses on install 15:14:58 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 vs: you have a default, you keep a default 15:15:31 contyk: I may have been unclear, but it's really the presence or absence of ":streamname" in any command that matter 15:15:34 *matters 15:16:09 contyk: "Modules can be installed / enabled with a stream specified in one of the following three ways" <- it's there 15:16:11 sgallagh: +1 15:16:14 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 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 asamalik: +1 15:17:08 I'm not going to vote on this 15:17:45 langdon: Do you have any thoughts on the matter? 15:17:53 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 being comfortable with it 15:20:04 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 (I would have proposed it otherwise) 15:20:19 and decisions like this can't be easily changed later 15:20:21 .hello2 15:20:23 ignatenkobrain: ignatenkobrain 'Igor Gnatenko' 15:20:29 sorry, I had some $dayjob to finish 15:20:56 so I'm not going to block you guys if you feel strongly that this is the best thing to do 15:21:00 but I can't support it either :) 15:21:06 contyk: what exactly you don't like in proposals? 15:21:26 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 contyk: I do. 15:21:48 I don't think that's a tremendous amount of overhead 15:21:58 and it's a well-known syntax from the container world for example 15:22:06 podman run fedora vs. podman run fedora:29 15:22:23 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 Right, and I think this approach will provide the least surprise. 15:23:03 Remember that our users do not yet have *any* real experience with an upgrade of modules 15:23:26 So modeling the experience around the existing upgrade experience seems to me to be the least-surprising solution 15:23:43 While offering them a powerful alternative to avoid breakage on their critical apps 15:23:43 +1 15:23:52 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 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 I don't think so. 15:24:34 stickster: I think this is compatible with that. 15:24:40 stickster: it would make them even stronger 15:24:52 stickster: Even if the platform updates, I doubt very much that the default streams would change with the same frequency. 15:25:04 sgallagh: I would tend to doubt that too 15:25:21 * stickster with the caveman questions ;-) 15:25:25 Though if we start having default streams for core bits... then this would definitely help 15:25:35 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 ignatenkobrain: I put it in the ticket; it depends on how you look at it, which I find problematic 15:25:46 So yeah, I agree with asamalik. If our platforms start coming faster, this would help a LOT 15:25:53 yes, I'll just lazily edit my message to: what sgallagh says :) 15:26:13 I mean the one I was just typing saying the same thing :) 15:26:20 We should probably also consider the case of a long-term release -- I'm not sure that *weakens* this proposal, either 15:26:30 asamalik: You agree that I agree with you, then? :) 15:26:31 stickster: also very compatible 15:26:49 so in essence, the frequency of releases doesn't matter :) 15:26:59 sgallagh: I agree with you statement about me agreeing about agreeing with you that we both agree, agreed! 15:27:13 contyk: I agree with you that same command with different arguments producing different result is not reallynice 15:27:19 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 stickster, a long term release won't have changing defaults, so is kinda skidding by the problem :) 15:27:44 *nod, feels like the long-term release is more of a non-issue 15:27:52 stickster: still the same mechanics: choose "the default stream" for the current experience, or "a specific stream" for keeping the stream 15:28:07 respecting your choices in both scenarios while being compatible with the current way of things 15:28:31 just to clarify: 15:28:45 do we all agree that implicitly enabled streams can be swapped without any special command? 15:29:07 ignatenkobrain: yes if the RPMs allow it 15:29:20 obviously 15:29:26 ignatenkobrain: With the obvious proviso that it has to fail if it would introduce dependency errors, sure. 15:29:29 I proposed to make that behavior configurable but sgallagh disagreed 15:29:33 except that DNF doesn't check that at all and is considered as a right behaviour 15:29:54 .bug 1636711 15:29:55 ignatenkobrain: Bug 1636711 – Switching module streams doesn't do anything useful - https://bugzilla.redhat.com/1636711 15:29:56 contyk: I would disagree as well, that would cause inconsistent behaviors. 15:29:57 but that's different topic 15:30:16 it would behave depending on your configuration 15:30:17 ignatenkobrain: current vs. expected behavior — we're talking about the expected here :) 15:30:29 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 The outcome of this decision would help influence that, I believe 15:31:01 yes 15:31:02 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 ignatenkobrain: We can't actually use --lock for complicated reasons. 15:31:30 (That terminology has a strict meaning in RHEL errata) 15:31:31 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 ignatenkobrain: that wouldn't be good 15:31:52 ignatenkobrain: you could install nodejs:8 without --lock and then upgrade would switch you to the current default stream 15:31:53 I want to talk about it as what stream you have installed: "the default" or "a specific one" 15:32:10 a specific default one ;) 15:32:30 asamalik: He's specifically talking about dependencies of the one we selected, I think 15:32:42 I mean, what DNF remembers is "the default" or "a specific one" 15:32:54 contyk: That almost sounds like it makes the case for the proposed syntax, though :-) 15:33:09 stickster: yes, which mans --lock is pointless 15:33:17 contyk: +1 15:33:23 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 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 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 yeah, something like "module install --lock nodejs", which would lock you to whatever the default is, is more interesting 15:34:16 it's basically like specifying the stream 15:34:18 nils: like "I don't know what I have but I want to keep it?" that sounds... strange to me :) 15:34:29 but it's even more complicated 15:34:36 contyk: that's so confusing to me 15:34:41 asamalik, exactly, that's why I think such an option has no huge benefit except to confuse people :) 15:34:47 asamalik: yes, it is even worse 15:35:04 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 so that's why I *do not* want to use the words "locked" and "unlocked" 15:35:21 So we *do* have to consider how users would "lock" to a stream at a later point. 15:35:23 just to remind you why I created that ticket 15:35:31 new defaults appeared in rawhide and I did dnf update 15:35:32 sgallagh: with enable or install 15:35:38 it enabled few streams for me 15:35:47 sgallagh: yes, just using the install command, specifying the stream 15:35:47 then when I changed default, it didn't update to it 15:35:51 contyk: Yes, I agree with that. I'm just making sure we state that explicitly. 15:35:55 myself I didn't explicitly enable any stream 15:35:58 or "going from the default to a specific stream" 15:36:28 I think it's more worthwhile to get shell expansion for module name[:stream] 15:36:45 nils: shell expansion? 15:36:47 completion? 15:36:51 um yeah 15:36:58 do we wanna try voting and see what happens? 15:37:06 sure 15:37:24 asamalik: We'll probably have Russian interference in the voting process :-P 15:37:39 so +1 +0 -1 it is? 15:37:46 👍 15:37:59 asamalik: Restate the proposal for the record, please? 15:38:12 ok 15:38:43 +1 on shell completion (I know that's not the vote coming up, I'm silent there) ;-) 15:39:12 stickster: dnf already has bash/zsh completions, so we could just extend that 15:39:17 Yeah. nils: is there a BZ on shell-completion? 15:39:21 *nod 15:39:30 shoot.. Sorry all.. am afk today and lost track of time 15:39:39 sgallagh, not that I know but I can open one 15:39:49 but let's vote on this first 15:39:54 langdon: Just in time to wreck the vote! ;-) 15:40:04 don't give him ideas 15:40:05 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 nice! 15:40:07 https://pagure.io/modularity/issue/108#comment-539882 15:40:13 .hello2 15:40:14 langdon: langdon 'Langdon White' 15:40:20 I don't want the topic to resurface next week :) 15:40:39 asamalik: +1 15:40:42 +1 15:40:47 +1 15:40:51 +1! 15:40:55 "keeps the default streams" feels a bit misleading 15:40:59 even though I know what you mean 15:41:04 sorry to let you down ;) 15:41:05 sorry "keeps the default stream" 15:41:05 still, I abstain 15:41:07 typo 15:41:14 "Tracks changes in the default stream" would be better phrased, I think 15:41:23 "follows any new default" 15:41:32 yours might be better 15:41:44 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 as long as we all know what we voted for or against :) 15:41:51 +0 after rethinking what contyk said 15:42:56 I see only votes for and abstentions, the votes for outnumbering the abstentions 2:1. So we're agreed. 15:43:00 4 +1s, 2 +0s, 0 -1s so far 15:43:11 ignatenkobrain: on the wording or the concept? 15:43:43 langdon: concept, that `install nodejs` and `install nodejs:8` will do different things even nodejs:8 is default 15:43:57 langdon: I'm not against the concept, I just have doubts about the proposed implementation 15:44:09 for instance, we don't do it for rpms 15:44:17 --> #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 when user types install foo-1-1.x86_64, we do upgrade it to foo-2-1 when time comes 15:44:28 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 ignatenkobrain: RPMs don't have streams... 15:44:31 Ahh.. I see.. I understand the concern but think all other chooses are worse :) 15:44:31 (I'm only asking for wording here.) 15:44:49 langdon: Yeah, my thoughts exactly 15:45:08 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 asamalik: what about ...? 15:45:19 add artificial "default" stream 15:45:31 and then install nodejs == install nodejs:default 15:45:39 ignatenkobrain: We discussed that above. A stream named "default" may actually exist. 15:45:45 with the current workload on the DNF team, any wagers when we'll get that feature? 15:45:54 Asamalik but then it never upgrades w/o user action ;) 15:46:12 nils: f31 15:46:21 so early 2020 15:46:31 langdon, I would hope my system doesn't upgrade without action on my behalf. *pats his pets* 15:46:50 ha 15:46:57 Also, we have another <15 mins. 15:47:18 I can say for sure this will not land in f30 15:47:22 I think it's clear that we're not going to get consensus, but we do have a +4 vote. 15:47:23 Any last minute changes to the wording before I log this in? 15:47:27 and f30 will have extra long life 15:47:52 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 contyk: that's still undecided ;) 15:48:05 ;) 15:48:15 asamalik, concur 15:48:38 I want the other one voted on as well 15:48:55 --> #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 any objections against the wording? 15:49:03 5 15:49:04 4 15:49:06 3 15:49:07 2 15:49:08 can you include the votes? 15:49:10 1 15:49:12 sure 15:49:38 nils: I would mention the comment, as it describes it in more detail: https://pagure.io/modularity/issue/108#comment-539882 15:49:56 so it' clear, for example to the DNF team, what the actual proposal is 15:50:01 --> #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 although we're likely to document it 15:50:10 so might not be necessary :) 15:50:16 nils: +1 15:50:21 yeah but that doesn't have to go in the agreed line 15:50:33 right, I've just realized that 15:50:35 #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 #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 ack 15:51:05 next 15:51:10 \o/ 15:51:25 #topic Discussion: Module lifecycles 15:51:43 #link https://pagure.io/modularity/issue/108#comment-539882 15:51:47 oops 15:51:48 #undo 15:51:48 Removing item from minutes: 15:51:54 this is one I haven't managed to read yet 15:51:55 nils: ah no this one, I meant the "changing defaults vs. fedora changes" 15:51:58 #link https://pagure.io/modularity/issue/112 15:52:03 #undo 15:52:03 Removing item from minutes: 15:52:03 * contyk looks 15:52:06 #undo7 15:52:08 #undo 15:52:08 Removing item from minutes: 15:52:28 #topic Stream default changes & Fedora Changes 15:52:35 nils: thanks! 15:52:36 #link https://pagure.io/modularity/issue/114 15:52:44 quick, quick! :) 15:52:45 so, any comments or concerns or can we go straight to the vote for this one? 15:53:04 I added a comment to this one 15:53:22 contyk: ah right! 15:53:29 concur with the proposal plus contyk's comment 15:53:40 I +1 all contyk points 15:53:56 I'd say adding new defaults nor replacing anything is OK — it's like adding a new package 15:53:59 that's essentially what I have tried to do with libgit2 in F29 15:54:20 the proposal implies it but it should be explicit that defaults _added_ shouldn't need a change 15:54:22 I'd be careful with replacing traditional packages with modules mid-release at this point 15:54:31 on contyk's comment, non-modular to modular in existing stable *must* have a default stream of the non-modular version 15:54:38 nils: it only talks about future releases, rather explicitly 15:54:48 langdon: why? 15:54:52 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 langdon: the non-modular package isn't going anywhere 15:55:10 Ohh.. what? 15:55:23 contyk: ah! that's what I didn't get 15:55:25 you can keep the non-modular package and just add streams 15:55:27 then yes, +1 to both 15:55:32 definitely not how I read the 2nd graph 15:55:36 the streams don't have to be default but can be 15:55:38 but that has nothing to do with defaults :) 15:55:40 contyk: except for the buildroot. where UM should help us 15:56:13 adding non-default streams is not changing defaults 15:56:27 true 15:57:14 okay, so we could allow adding defaults to stable releases for modularized content if those defaults don't introduce significant changes 15:57:25 can someone write a new, full proposal in the ticket? 15:57:43 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 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 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 this is about introducing incompatibilities 15:58:13 contyk: yes, but we need UM 15:58:19 and submitting changes in order to communicate incompatibilities 15:58:34 if something doesn't introduce an incompatibilities, there is no change 15:58:35 ignatenkobrain: yes, agreed 15:58:50 contyk also modularizing 8, removing the rpms, in a stable release would also be not cool 15:58:51 nils: my only concern is that the maintainer will stop paying attention to the ursine package after modularizing the content 15:58:59 langdon: +1 15:59:09 langdon: you can't remove them 15:59:12 but that's out of scope of this proposal 15:59:19 langdon: I assumed we meant they would be filtered not removed. 15:59:51 ok, so looks like we'll give this one two more weeks :) 15:59:56 ok.. I think this needs clarification in the proposal.. I'm not sure we are all even clear on the idea 16:00:05 contyk, maintainers stop paying attention to their maintained content all the time (chastising my own self here ;)) 16:00:25 proposal: Reword the proposal considering stable releases in the ticket and let's revisit this next time 16:00:25 anyone up to writing that clarification? 16:00:39 contyk, +1 16:00:45 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 so there is no problem in doing so I think 16:01:02 ignatenkobrain: yeah, but UM is still an unresolved topic atm 16:03:48 so.. who is volunteering? 16:03:49 are we dead? 16:03:56 I aten't ded yet 16:04:05 I assume that means you agree with the proposal? 16:04:06 I heard UM can revive you... 16:04:14 asamalik, shall we bang our heads together tomorrow morning about the clarified wording? 16:04:39 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 ignatenkobrain: please add the note about the need for UM in that specific scenario to the ticket 16:04:51 I have a call after this meeting, so can't do it today (I guess) 16:05:21 asamalik: considering the discussions before f29, I don't think it's clear at all 16:05:34 contyk: ack 16:05:51 asamalik, but we don't announce every package version upgrade in a change yet, not saying we shouldn't :) 16:06:03 nils: all right, action me to fix it 16:06:20 nils: that's exactly what the proposal says :) 16:06:29 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 right, spotted the wildcard :D 16:06:54