14:03:41 <nils> #startmeeting modularity_wg
14:03:41 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:41 <zodbot> The meeting name has been set to 'modularity_wg'
14:03:41 <nils> #meetingtopic Meeting of the Modularity Working Group (once every two weeks)
14:03:41 <nils> #chair sct tflink
14:03:41 <zodbot> Current chairs: nils sct tflink
14:03:57 <nils> A little late, sorry. Previous meeting went overtime.
14:03:59 <asamalik> .hello2
14:04:00 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:04:02 <sct> .hello sct
14:04:03 <nils> #topic Roll Call
14:04:03 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
14:04:06 <tflink> .hello2
14:04:07 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
14:04:08 <nils> .hello nphilipp
14:04:12 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
14:04:51 <nils> #topic Agenda
14:05:19 <nils> Does anybody have anything? There's nothing in the issue tracker.
14:05:29 <asamalik> 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 <nils> #info [asamalik] review proposal for adding new modules to Fedora
14:06:34 <nils> that seems to be all
14:06:50 <nils> #topic review proposal for adding new modules to Fedora
14:06:54 <nils> #chair asamalik
14:06:54 <zodbot> Current chairs: asamalik nils sct tflink
14:07:26 <sct> asamalik: Haven't looked in detail but looks good at first glance
14:08:03 <sct> 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 <asamalik> #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 <asamalik> sct thanks!
14:09:07 <asamalik> 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 <sct> asamalik: I'm a little concerned about "Repositories and branches for modules should not require any review" longer term
14:09:36 <asamalik> 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 <sct> as I think we have some basic requirements for correctness on modulemd above and beyond the rpms themselves
14:10:08 <sct> eg. representing API correctly, getting inter-module dependencies right
14:11:11 <asamalik> 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 <asamalik> 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 <asamalik> would that be enough?
14:11:42 <sct> asamalik: Not necessarily true.  A default module will be visible to dnf transparently
14:12:21 <sct> Ah, OK
14:12:45 <asamalik> sgallagh: langdon ^^ what do you think?
14:13:15 * sgallagh reads backlog. I had the time wrong.
14:13:44 <sct> 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 <tflink> sorry, I'm trying to be in 2 meetings at once, will be a bit slow
14:14:43 <sgallagh> I think asamalik's idea makes sense, yeah. No specific review needed until it becomes default
14:14:48 <sct> asamalik: I do like the idea of having as low a barrier to entry as possible for new modules
14:15:05 <sct> asamalik: though I'm wondering if copr is a better place for the "no review at all" modules
14:15:16 <tflink> yeah, it makes sense to me as well
14:17:39 <asamalik> 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 <sgallagh> sct: Well, as long as the actual delivered content is coming from fedora-approved packages, it should be fine.
14:19:04 <sgallagh> 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 <asamalik> 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 <sct> 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 <sct> 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 <sct> It's a corner case that is confusing but easily managed by dnf if the modulemd is correct up-front
14:21:41 <asamalik> sct: that would be the same case as it it was depending on something from a base
14:22:11 <asamalik> ... whic was replaced by something from a module that doesn't even have a "default" stream
14:22:25 <sct> asamalik: That's a good point... likely something we need to make sure dnf recognises regardless, in that case.
14:22:28 <asamalik> also, that's what bodhi update is for
14:22:31 <sgallagh> Yeah, that's one of those edge cases that DNF is going to have to be able to handle anyway
14:22:37 <asamalik> so people / robots can test it
14:23:26 <langdon> oops.. lost track of time.. im here.. but also double booked
14:23:37 <asamalik> 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 <sct> 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 <asamalik> langdon: just double? so you have even more time for us?!? :P
14:24:20 <langdon> right?
14:24:23 <asamalik> *make -> may
14:24:48 <sct> so +1 for keeping no modulemd review for non-default modules.
14:25:13 <langdon> ohh.. im +1 on that too
14:25:39 <sct> langdon: This was part of reviewing adam's https://fedoraproject.org/wiki/Modularity/Adding_New_Modules_and_Managing_Defaults doc
14:25:52 <langdon> yeah.. read it a day or two ago.. im in..
14:27:40 <sct> Anything else, or can we mark that one as approved?
14:27:46 <asamalik> sounds good so far :)
14:27:49 <sct> Yep!
14:27:54 <sct> nils: ^^
14:28:01 <sgallagh> hold
14:28:01 <nils> now I need to look up how to do the magic :)
14:28:03 <nils> sec
14:28:05 <sct> heh
14:28:17 <sgallagh> I don't want to approve it until that "TBD" section is answered, thoguh
14:28:26 <sgallagh> "Modules: TBD (either filing a ticket somewhere, or using the fedrepo-req tool)"
14:28:38 <sgallagh> I feel like we should just assert an approach and change it later if needed.
14:28:41 <asamalik> sgallagh: so that's just about getting the right syntax for either fedrepo-req or fedpkg
14:29:07 <asamalik> really only the mechanics
14:29:19 <sgallagh> Those are important :)
14:29:48 <asamalik> I agree :)
14:30:14 <sgallagh> I also have one more question about default profiles.
14:30:34 <sgallagh> I don't think the default profile should change outside of a Change Proposal.
14:30:44 <sgallagh> I think the *contents* of the profile can be updated as needed
14:30:46 <sct> I don't think that fixing up the exact CLI needs to block approving the overall process, though
14:31:22 <sgallagh> 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 <nils> *nod*
14:31:57 <asamalik> 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 <sct> Agreed; profiles should behave like ABIs during a release, we can add new ones but not break existing ones.
14:32:23 <sgallagh> Yes, but it would still be a significant user-visible change in behavior
14:32:46 <asamalik> 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 <sgallagh> And thus should be following the spirit of the Stable Updates guideline
14:32:58 <sct> asamalik: Changing a profile changes the results of a kickstart or Dockerfile that uses modules
14:33:33 <asamalik> true
14:33:42 <sgallagh> asamalik: No, I think it should be that changing the default profiles of any stream is forbidden post-release.
14:33:55 <sgallagh> Adding new profiles or changing the exact RPMs referenced in them is acceptable
14:34:37 <asamalik> 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 <sct> sgallagh: +1
14:35:28 <asamalik> so let me change it there
14:35:35 <sgallagh> Thanks
14:36:48 <asamalik> in the meantime, sgallagh do you require the TBD in the first step to be fixed before you approve that?
14:37:34 <sgallagh> asamalik: I'm not willing to block on it, no
14:39:05 <nils> Any preferences how the #agreed should be phrased, just "approved: <URL>"?
14:39:27 <asamalik> wiki is updated
14:40:22 <asamalik> sct: to your question about default repo, no, it's not linked to the defaults, but contyk is looking into it
14:40:26 <asamalik> *about the defaults repo
14:40:26 * asamalik can't type today :/
14:41:03 <sct> 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 <nils> I can't seem to parse "requires a Fedora Change request when" in step 4, overview.
14:43:01 <asamalik> nils: yeah let me fix that
14:43:41 <asamalik> nils: done
14:44:54 <nils> #agreed document for adding new modules and managing defaults is approved
14:44:57 <nils> ^^ ?
14:45:07 <sct> Yep!
14:45:10 <nils> good
14:45:23 <nils> anything else to discuss?
14:45:59 <asamalik> ¥o/
14:46:08 <asamalik> \o/
14:46:38 <nils> okay :)
14:46:44 <nils> thanks everybody for coming!
14:46:51 <nils> #endmeeting