14:03:41 #startmeeting modularity_wg 14:03:41 Meeting started Tue Mar 20 14:03:41 2018 UTC. The chair is nils. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:41 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:03:41 The meeting name has been set to 'modularity_wg' 14:03:41 #meetingtopic Meeting of the Modularity Working Group (once every two weeks) 14:03:41 #chair sct tflink 14:03:41 Current chairs: nils sct tflink 14:03:57 A little late, sorry. Previous meeting went overtime. 14:03:59 .hello2 14:04:00 asamalik: asamalik 'Adam Samalik' 14:04:02 .hello sct 14:04:03 #topic Roll Call 14:04:03 sct: sct 'Stephen Tweedie' 14:04:06 .hello2 14:04:07 tflink: tflink 'Tim Flink' 14:04:08 .hello nphilipp 14:04:12 nils: nphilipp 'Nils Philippsen' 14:04:51 #topic Agenda 14:05:19 Does anybody have anything? There's nothing in the issue tracker. 14:05:29 nils: I have a topic, would like to review and get approved my proposal for adding new modules to Fedora: https://fedoraproject.org/wiki/Modularity/Adding_New_Modules_and_Managing_Defaults 14:06:02 #info [asamalik] review proposal for adding new modules to Fedora 14:06:34 that seems to be all 14:06:50 #topic review proposal for adding new modules to Fedora 14:06:54 #chair asamalik 14:06:54 Current chairs: asamalik nils sct tflink 14:07:26 asamalik: Haven't looked in detail but looks good at first glance 14:08:03 asamalik: I didn't realise we had the https://pagure.io/releng/fedora-module-defaults , nice! Is that linked into compose yet? 14:08:04 #link https://fedoraproject.org/wiki/Modularity/Adding_New_Modules_and_Managing_Defaults I have written a proposal for a proces of adding new modules to Fedora 14:08:04 sct thanks! 14:09:07 short story: I believe that all new packages to Fedora should go through the formal review we have today — regardless of them being in the base or in the application stream 14:09:20 asamalik: I'm a little concerned about "Repositories and branches for modules should not require any review" longer term 14:09:36 I also believe that if the packages went through a formal review, we don't need to do any other review for the module itself, because it won't add any new software 14:09:41 as I think we have some basic requirements for correctness on modulemd above and beyond the rpms themselves 14:10:08 eg. representing API correctly, getting inter-module dependencies right 14:11:11 sct: one thing: adding modules into the application stream will only make them available when people explicitly request them by enabling a stream... it won't affect the default installation in any way... 14:11:36 only when a stream becomes default, then we should check it a bit more probably — and I'm proposing a Fedora change for manipulating defaults 14:11:40 would that be enough? 14:11:42 asamalik: Not necessarily true. A default module will be visible to dnf transparently 14:12:21 Ah, OK 14:12:45 sgallagh: langdon ^^ what do you think? 14:13:15 * sgallagh reads backlog. I had the time wrong. 14:13:44 asamalik: That does make sense, yes, but it didn't come across that way in the wiki page --- maybe we should explicitly state that the change request to add a default will need to involve a review of the modulemd as well as of the profile change? 14:13:45 * asamalik loves DST 14:14:09 sorry, I'm trying to be in 2 meetings at once, will be a bit slow 14:14:43 I think asamalik's idea makes sense, yeah. No specific review needed until it becomes default 14:14:48 asamalik: I do like the idea of having as low a barrier to entry as possible for new modules 14:15:05 asamalik: though I'm wondering if copr is a better place for the "no review at all" modules 14:15:16 yeah, it makes sense to me as well 14:17:39 sct: but thinking about it... what else is left to review if all the pacakges in the modules have been already reviewed? the package review we have today is mostly about licensing and the initial specfile structure if I understand it correctly 14:17:49 sct: Well, as long as the actual delivered content is coming from fedora-approved packages, it should be fine. 14:19:04 The primary reason for review is for permissible content; the secondary reason is to ensure that RPMs are built that are maintainable. But the modules are basically a grouping mechanism. 14:19:18 dependencies? they might change over time anyway and we won't review that... install profiles? why? ... I couldn't find anything of importance in the module itself 14:20:33 asamalik: Install profiles is no big deal. I'm thinking of cases like a module depending on content in a default stream of some other module, without declaring that dependency 14:20:55 which will cause user confusion/errors if they try to install that module when a non-default version of the dependency has already been enabled. 14:21:18 It's a corner case that is confusing but easily managed by dnf if the modulemd is correct up-front 14:21:41 sct: that would be the same case as it it was depending on something from a base 14:22:11 ... whic was replaced by something from a module that doesn't even have a "default" stream 14:22:25 asamalik: That's a good point... likely something we need to make sure dnf recognises regardless, in that case. 14:22:28 also, that's what bodhi update is for 14:22:31 Yeah, that's one of those edge cases that DNF is going to have to be able to handle anyway 14:22:37 so people / robots can test it 14:23:26 oops.. lost track of time.. im here.. but also double booked 14:23:37 I think the consensus is that enabling a non-default stream make sometimes brake other things.. there is no way of preventing this if we can replace packages 14:24:01 OK, that all sounds reasonable. The change request for the default gives us a place where we can identify any odd interactions like that, and the tools will have to handle the routine cases anyway 14:24:11 langdon: just double? so you have even more time for us?!? :P 14:24:20 right? 14:24:23 *make -> may 14:24:48 so +1 for keeping no modulemd review for non-default modules. 14:25:13 ohh.. im +1 on that too 14:25:39 langdon: This was part of reviewing adam's https://fedoraproject.org/wiki/Modularity/Adding_New_Modules_and_Managing_Defaults doc 14:25:52 yeah.. read it a day or two ago.. im in.. 14:27:40 Anything else, or can we mark that one as approved? 14:27:46 sounds good so far :) 14:27:49 Yep! 14:27:54 nils: ^^ 14:28:01 hold 14:28:01 now I need to look up how to do the magic :) 14:28:03 sec 14:28:05 heh 14:28:17 I don't want to approve it until that "TBD" section is answered, thoguh 14:28:26 "Modules: TBD (either filing a ticket somewhere, or using the fedrepo-req tool)" 14:28:38 I feel like we should just assert an approach and change it later if needed. 14:28:41 sgallagh: so that's just about getting the right syntax for either fedrepo-req or fedpkg 14:29:07 really only the mechanics 14:29:19 Those are important :) 14:29:48 I agree :) 14:30:14 I also have one more question about default profiles. 14:30:34 I don't think the default profile should change outside of a Change Proposal. 14:30:44 I think the *contents* of the profile can be updated as needed 14:30:46 I don't think that fixing up the exact CLI needs to block approving the overall process, though 14:31:22 But we shouldn't be okay with having e.g. samba change from having a default profile of "file-sharing" to "domain-controller" mid-release 14:31:44 *nod* 14:31:57 sgallagh: my argument is that changing a profile won't influence other things that use that module as a dependency, as dependencies are on the individual package level... 14:32:15 Agreed; profiles should behave like ABIs during a release, we can add new ones but not break existing ones. 14:32:23 Yes, but it would still be a significant user-visible change in behavior 14:32:46 sgallagh: that's probably a good point... so let's change it to "changing profiles of a *default* module requires a review"? 14:32:48 And thus should be following the spirit of the Stable Updates guideline 14:32:58 asamalik: Changing a profile changes the results of a kickstart or Dockerfile that uses modules 14:33:33 true 14:33:42 asamalik: No, I think it should be that changing the default profiles of any stream is forbidden post-release. 14:33:55 Adding new profiles or changing the exact RPMs referenced in them is acceptable 14:34:37 I'm fine with that.. I just couldn't see a reason to add a potential friction to the process, but this makes perfect sense to me 14:34:44 sgallagh: +1 14:35:28 so let me change it there 14:35:35 Thanks 14:36:48 in the meantime, sgallagh do you require the TBD in the first step to be fixed before you approve that? 14:37:34 asamalik: I'm not willing to block on it, no 14:39:05 Any preferences how the #agreed should be phrased, just "approved: "? 14:39:27 wiki is updated 14:40:22 sct: to your question about default repo, no, it's not linked to the defaults, but contyk is looking into it 14:40:26 *about the defaults repo 14:40:26 * asamalik can't type today :/ 14:41:03 asamalik: OK. Was just curious about that; it doesn't affect the doc as it stands, it's "just" an implementation detail :) 14:41:31 I can't seem to parse "requires a Fedora Change request when" in step 4, overview. 14:43:01 nils: yeah let me fix that 14:43:41 nils: done 14:44:54 #agreed document for adding new modules and managing defaults is approved 14:44:57 ^^ ? 14:45:07 Yep! 14:45:10 good 14:45:23 anything else to discuss? 14:45:59 ¥o/ 14:46:08 \o/ 14:46:38 okay :) 14:46:44 thanks everybody for coming! 14:46:51 #endmeeting