15:01:13 <asamalik> #startmeeting modularity
15:01:13 <zodbot> Meeting started Tue Apr  2 15:01:13 2019 UTC.
15:01:13 <zodbot> This meeting is logged and archived in a public location.
15:01:13 <zodbot> The chair is asamalik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:13 <zodbot> The meeting name has been set to 'modularity'
15:01:14 <asamalik> #meetingtopic Weekly Meeting of the Modularity Team
15:01:14 <asamalik> #topic Roll Call
15:01:20 <contyk> .hello psabata
15:01:22 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:25 <asamalik> .hello2
15:01:26 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:01:26 <sgallagh> .hello2
15:01:29 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:02 * asamalik waves
15:02:51 <asamalik> #topic Agenda
15:02:51 <asamalik> #info 128 Discussion: naming common streams and profiles
15:02:51 <asamalik> #info 129 UX design of setting module EOL — please review
15:03:17 <asamalik> do we have anything else to discuss?
15:03:55 <sgallagh> The UX thread I started on devel@?
15:04:15 * contyk hasn't read it yet
15:04:16 <sgallagh> Also, I'd like to talk about translations
15:04:26 <asamalik> #info Modularity UX Questions
15:04:30 <asamalik> #info translations
15:05:13 <asamalik> all right, let's start
15:05:21 <asamalik> #topic 128 Discussion: naming common streams and profiles
15:05:21 <asamalik> #link https://pagure.io/modularity/issue/128
15:05:34 <langdon> .hello2
15:05:35 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
15:05:50 <asamalik> Two things I want to discuss here:
15:05:50 <asamalik> * Last call to make changes in the proposal before it goes to the docs
15:05:50 <asamalik> * Ideas about how to align existing modules — renaming streams and profiles will potentially break things
15:06:10 <contyk> so I don't really like that "dev" proposal
15:06:15 <contyk> for two reasons
15:06:31 <contyk> one is I don't like naming things with abbreviations
15:06:46 <contyk> but if we have to, then we should use the ones we're already using elsewhere (devel)
15:07:13 <contyk> the other reason is that I wouldn't understand what that means; it evokes some stream with development files, headers and tools and whatnot
15:07:19 <contyk> not something experimental
15:07:38 <langdon> i would have both :)
15:07:49 <langdon> dev = experimental; devel = to build with
15:08:03 <contyk> why would I need a special stream to provide development files?
15:08:14 * langdon also reading comments he had missed
15:08:14 <contyk> builds normally produce devel subpackages
15:08:24 <asamalik> contyk: yeah it's true that we use "devel" for things with development files etc in fedora... and having something similar for a very different purpose might be confusing
15:08:36 <langdon> sorry.. i was talking about profiles.. not streams
15:08:40 <asamalik> langdon: having both, sure.. naming them similar, please no no no :D
15:09:00 <contyk> I'm talking about streams, that's where the "dev" was proposed :)
15:09:12 <langdon> i like "rolling" for streams..
15:09:12 <asamalik> contyk: any better idea for a name?
15:09:22 <contyk> I personally don't even know what I would rename my dwm:latest to -- rolling or dev? it's just following upstream master
15:09:38 <contyk> so I don't really understand the distinction to begin with
15:09:49 <sgallagh> FWIW, I dislike "dev" as a stream name entirely.
15:10:01 <sgallagh> It's too much collision with -devel subpackages
15:10:18 <contyk> yes
15:10:29 <asamalik> so looks like we're not going with dev — and I agree with contyk and sgallagh, I haven't realized that when proposing the name
15:10:32 <langdon> not to totally blow things up.. but we could use arbitrary words a la debian
15:11:07 <sgallagh> contyk: Re: latest vs rolling, as I noted in https://pagure.io/modularity/issue/128#comment-562827, "latest" has implications on timing.
15:11:11 <langdon> which would definitely be clearer.. but not fedora traditional
15:11:32 <sgallagh> I like it better than "stable", but I think "rolling" is the better of the three.
15:11:33 <contyk> or name everything aladeen
15:11:59 <contyk> sgallagh: I'm not arguing against rolling
15:12:03 <asamalik> or use the summary in quotes
15:12:19 <contyk> sgallagh: I'm just staying that if we standardize on rolling and dev, I wouldn't know which to choose
15:12:27 <contyk> sgallagh: because they seem virtually identical to me
15:12:30 <langdon> i would still argue for arbitrary :)
15:13:12 <sgallagh> contyk: I think the implication was "rolling" == "latest stable that I've managed to package" and  "dev" == "upstream unstable releases"
15:13:36 <sgallagh> I'd suggest "prerelease" as an alternative to "dev"
15:13:38 <sgallagh> Which might be more clear
15:13:50 <asamalik> "rolling" if its meant to be used by end users, "dev" if it's meant to be tested by hackers
15:13:56 <langdon> prerelease is pretty good
15:14:01 <sgallagh> (With a policy decision that prerelease streams may not be default without an exception)
15:14:02 <asamalik> I like prerelease!
15:14:05 <contyk> sgallagh: but the proposal says rolling is for software without versioning scheme, so not sure what the latest stable would be there
15:14:34 <asamalik> contyk: not all modules need to have these
15:14:37 <sgallagh> contyk: If there's only one branch, it's pretty obvious
15:14:45 <contyk> asamalik: I'm not saying that
15:15:02 <asamalik> contyk: dwm would have prerelease I guess
15:15:02 <sgallagh> If they have no versioning scheme, then the master branch == rolling, IMHO
15:15:15 <asamalik> and... that, yes
15:15:20 <contyk> but if you have software that has no releases and package it as foo:rolling and it's just following upstream git
15:15:24 <sgallagh> Some projects have a master branch and a "next" branch or the like.
15:15:24 <langdon> i would say "rolling" !=  for end users
15:15:33 <contyk> and then you have bar:rolling, which is some frozen "latest stable"
15:15:35 <sgallagh> langdon: I disagree
15:15:36 <contyk> there's inconsistency
15:15:58 <sgallagh> contyk: Yes and no.
15:16:01 <langdon> what about  "master"?
15:16:15 <sgallagh> There's inconsistency for the packager, but for the user experience it would be identical to what they get from ursine packages
15:16:36 <sgallagh> langdon: complaints when it's not updated in lock-step with upstream
15:16:51 <contyk> I don't know
15:16:59 <contyk> as a user I just wouldn't know what to expect
15:17:05 <contyk> and would need to dig in deeper
15:17:13 <contyk> which doesn't sound like practical and intuitive naming
15:17:20 <langdon> sgallagh: well.. it should be, right? as the packager has time, or we automate
15:17:43 <sgallagh> contyk: If naming was practical and intuitive, it wouldn't be a Hard Problem :TM:
15:18:12 <sgallagh> langdon: "as the packager has time" is the boundary condition
15:18:22 <sgallagh> It will almost never be the same as the upstream releases
15:18:35 <sgallagh> So "master" would be a misnomer in the majority of places we might use it
15:18:51 <langdon> master-- ;)
15:19:30 <sgallagh> .fire langdon
15:19:30 <zodbot> adamw fires langdon
15:19:56 <langdon> ha
15:19:59 <asamalik> avocado             latest
15:19:59 <asamalik> avocado             stable
15:19:59 <asamalik> ninja               latest
15:19:59 <asamalik> ninja               master
15:20:05 <asamalik> it won't be worse than this for example ^^
15:20:38 <asamalik> I think there definitely is a demand for two rolling streams — one for users, and one preview/prerelease
15:20:49 <langdon> i will definitely install ninja:master... just on principle
15:21:01 <asamalik> without naming those, do we agree we need both?
15:21:09 <langdon> i do like preview/prerelease
15:21:12 <asamalik> langdon++
15:21:13 <langdon> i think so
15:21:41 <sgallagh> langdon++
15:21:41 <zodbot> sgallagh: Karma for langdon changed to 7 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:21:44 <sgallagh> Yes, I concur
15:21:49 <langdon> im gonna get another .fire .. how about "<module>:.next" ;)
15:22:09 <contyk> . is not allowed
15:22:11 <langdon> actually... "next" isn't terrible
15:22:27 <langdon> and much shorter than "pre" words
15:23:13 <sgallagh> langdon: No, not  "next"
15:23:14 <asamalik> contyk: you didn't seem convinced we need both.. are you still not convinced? :)
15:23:43 <sgallagh> Because not everything in a prerelease actually makes it to a stable release.
15:23:52 <sgallagh> It can get kicked back out, reworked, etc.
15:24:33 <asamalik> "lets-see" :P
15:24:39 <langdon> sgallagh: +1
15:24:43 <contyk> I'm not convinced with any of this, no
15:24:48 <langdon> asamalik: love it!
15:25:10 <contyk> feels like replacing some words with other words without actually changing the situation
15:25:31 <sgallagh> contyk: The situation exists. The goal of changing the words is to more accurately communicate that situation
15:25:35 <asamalik> contyk: the words are part of that situation actually
15:25:41 <contyk> yes, it exists
15:25:52 <contyk> but I don't see the proposal making it any better
15:26:21 <contyk> but if we need to vote on something today, go ahead :)
15:26:38 <langdon> so... no one wants to pursue arbitrary?
15:26:44 <sgallagh> no
15:26:46 <contyk> no, I think that's the worst
15:26:49 <asamalik> we definitely don't need to vote today, because renaming streams will break things... we need to get it right first
15:26:58 <contyk> I'd like to look at the stream name and know what I'm getting
15:27:12 <contyk> arbitrary isn't helping in any way there
15:27:13 <langdon> well.. i think people do with debian.. it just takes time
15:27:49 <asamalik> also, we have three more topics and just half the time left.. so what's next here?
15:27:55 <contyk> it was said "latest" is confusing because it could mean the latest upstream master or the latest release
15:28:03 <asamalik> contyk you don't feel convinced... wanna help me build a better proposal for next week?
15:28:06 <contyk> "rolling" is essentially the same thing, just a different word
15:28:07 <sgallagh> asamalik: Could you summarize the current proposal in the ticket and we can continue it there?
15:28:18 <langdon> which is also true for whatever words we choose.. the problem with the words is that a) they already have meaning in fedora b) they already have meaning in software dev .. so we are fighting with those poorly defined terms elsewhere
15:28:18 <asamalik> sgallagh: the description is up-to-date
15:28:28 <contyk> and "dev" is just... no
15:28:28 <sgallagh> contyk: I don't think "rolling" carries the same implication as "latest".
15:28:30 <asamalik> sgallagh: I'm keeping it up-to-date and writing a log of changes there
15:28:46 <contyk> sgallagh: but it's defined exactly like that in the proposal and you even said that here
15:29:06 * sgallagh sighs
15:29:18 <sgallagh> You're confusing "the message we tell the user" and "the packager view"
15:29:22 <sgallagh> They *are* different things
15:29:23 <langdon> asamalik: for me, it would be helpful  if it is a clone with edits rather than just edits.. or can we get a PR that would show diffs and update the PR with each change?
15:29:33 <contyk> I'm only considering the users' view
15:29:42 <sgallagh> For the packager, "rolling" means "the most recent thing I have packaged up".
15:29:43 <contyk> I'm not sure if packagers' view is different
15:29:52 <contyk> but as I user I want to list the modules and know what I'm getting
15:29:58 <contyk> and neither rolling nor latest tell me that
15:29:59 <sgallagh> For the user it means "I just want the most recent version in the distro"
15:30:20 <contyk> especially if it means different things for different modules
15:30:40 <contyk> asamalik: to your question -- I don't actually have better proposals
15:30:45 <contyk> so I'm not sure what to offer you
15:30:50 <contyk> I just know I don't like these :)
15:30:51 <asamalik> langdon: I'd rather just keep it there for now, but if we end up discussing it forever and changing it all the time, then git might be a good idea.. but I hope that won't happen
15:31:11 <contyk> so to me it feels like a change just for the sake of a change, not improvement
15:31:28 <sgallagh> contyk: It's change for the sake of consistency.
15:31:53 <langdon> asamalik: yeah.. i hear ya.. can you just clone the whole block so i don't get confused again?
15:32:26 <asamalik> contyk: we know have "latest", "stable", "master"... used interchangeably and for multiple different things... having two, clearly defined and consistent feels like more than "change for the sake of change"
15:32:45 <sgallagh> asamalik++
15:32:46 <contyk> oh I agree with that this needs to be merged into something else
15:33:00 <contyk> but I also think we already have guidelines for that
15:33:14 <contyk> the old naming doc
15:33:26 <contyk> it's just that people are not following them
15:33:41 <ignatenkobrain> .hello2
15:33:42 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:33:43 <langdon> so the requirement is more beatings? not more changes? :)
15:33:47 <asamalik> it's not really old, it's current, but it's confusing a bit https://docs.fedoraproject.org/en-US/modularity/making-modules/naming-guidelines/
15:34:10 <contyk> yeah
15:34:11 <contyk> that's the one
15:34:23 <contyk> it says you should use "latest", not master or such
15:34:40 <contyk> so we can do s/latest/rolling/ (it even has the same definition in the text already)
15:34:47 <contyk> but I'm not sure that will fix anything
15:35:05 <asamalik> contyk: yes, people don't follow it because the "latest" there covers somehow both use cases we talk about here... the rolling for users and the preview... so packagers understand it somehow, and then pick anything else for the second one they might have
15:35:19 <asamalik> and that's why they're not following it and that's why it's not consistent
15:36:31 <ignatenkobrain> I feel it is important to bring it here, but for example flatpak uses master to ship latest builds
15:36:44 <asamalik> so it's clear to me at this point we won't reach a decision today, that's fine... but let's have a next step
15:36:59 <langdon> sidebar, is everyone else getting a 500 here? https://pagure.io/fm-orchestrator/tree/e79f15ce97bc7092c4088a70f2c0d1c6eb60ab48
15:37:25 <contyk> langdon: yes
15:37:31 <langdon> :( thanks
15:39:03 <asamalik> ignatenkobrain: so I'm proposing two streams... without naming them, one is for "rolling that is meant for users" and the other one is for "unstable/prereleasemeant for preview"... do you think we need both? some of us think we do, but some think the're the same... I'd like to know what you think also
15:39:34 <langdon> ignatenkobrain: quick q.. is flatpak:master "latest for users" or "beta"/"alpha"
15:39:58 <ignatenkobrain> asamalik: depends how you define "for preview"
15:41:00 <sgallagh> ignatenkobrain: For example, I have a module stream (now retired) for `hub` that was called 'prerelease' which included the upstream git master because it had been two years since a stable release.
15:41:02 <asamalik> ignatenkobrain: almost like nightly
15:41:25 <sgallagh> I kept the stable version in fedora proper and included `prerelease` as an optional stream
15:42:17 <ignatenkobrain> asamalik: sgallagh if there are some kind of alpha/rc which is kinda considered like stable but is missing release, I'd put it into the same stream as the latest stable
15:42:37 <ignatenkobrain> so basically in sgallagh case, I'd actually put it into same stream as latest release of "hub"
15:42:50 <ignatenkobrain> asamalik: for nightly, I'd actually call stream "master"
15:43:53 <sgallagh> ignatenkobrain: Well, the situation there was that every once in a while, a stable release also got cut from the old branch point
15:44:17 <sgallagh> This particular project no longer follows that strategy, but it's not unheard-of
15:44:45 <asamalik> I think there is a room for packager's judgement.. bcause they know what they package much better than the user does... they can help the user recognize if this stream is meant for production use or for preview... I think that's the distinction... it might vary case by case where a master branch ends up
15:45:33 <sgallagh> I agree with asamalik here. There are two use-cases here. We don't have to define how they're separated, just how to name them
15:45:41 <ignatenkobrain> for every packager, "production use or preview" is really different :)
15:46:09 <ignatenkobrain> there are people scared of any changes in production, some are less conservative and there are people like me running latest stuff in production
15:46:19 <ignatenkobrain> I think predefining this by packager is bad idea
15:46:37 <asamalik> ignatenkobrain: I trust Fedora packagers, that's why I use Fedora :) and we can fine-tune the wording to make the meaning more obvious
15:47:10 <asamalik> so there might be additional guidance, that's a good point
15:47:24 <asamalik> but anyway... sorry to do this but we need to go to the next topic
15:47:28 <asamalik> time is running out
15:47:46 <asamalik> let's continue in the ticket and revisit next week
15:48:06 <asamalik> #action asamalik to summarize the naming discussion so we can continue in the ticket
15:48:34 <asamalik> #info 129 UX design of setting module EOL — please review
15:48:34 <asamalik> #link https://pagure.io/modularity/issue/129
15:48:34 <asamalik> This feels final, just need a formal +1 from the group
15:49:14 <asamalik> contyk, sgallagh, langdon, ignatenkobrain ^
15:49:25 * langdon re-reads for final edits
15:50:00 <sgallagh> I'm +1 after the edits you made from my comments
15:50:16 <asamalik> I'm also +1 ftr
15:51:06 <sgallagh> asamalik: Oh, actually I have one more question about epel
15:51:12 <langdon> love it! +1'd in the ticket
15:51:23 <sgallagh> Should it be `epel:el8.3` or `epel8:el8.3` ?
15:51:25 <contyk> how would I unset eol?
15:51:33 <sgallagh> `fedpkg module-eol fedora`
15:51:44 <sgallagh> See "Set the EOL to forever..."
15:51:45 <contyk> is that the default?
15:51:47 <sgallagh> Yes
15:51:50 <contyk> ok
15:51:57 <contyk> that isn't clear
15:52:03 <asamalik> sgallagh: that's for the EPEL people to decide I'd say, so out of scope here at this very moment?
15:52:08 <sgallagh> Not specifying it defaults to “forever or until I say otherwise”.
15:52:12 <contyk> it feels like you need to run module-eol and pick one and until you do, it's undefined
15:52:15 <sgallagh> In the last section
15:52:20 <contyk> ok
15:52:33 <sgallagh> asamalik: I think it matters, honestly
15:52:34 <contyk> +1 then
15:52:47 <langdon> asamalik: i would think it is better to NOT specify "epel8:el8.3" because it implies server implementation
15:52:56 <ignatenkobrain> +1
15:53:01 <sgallagh> asamalik: Because we might want it to expire with epel8:el8.8 and epel9:el9.1
15:53:07 <asamalik> sgallagh: I'd say that adding new platforms/releases/products/whatever-we-name-these will include defining the syntax here
15:53:07 <langdon> why would the cli care what server the epel-ness is on?
15:53:12 <asamalik> but epel 8 doesn't exist yet
15:53:38 <sgallagh> asamalik: Maybe just add a line that says "the epel example is a placeholder"
15:53:41 <sgallagh> Then I'm fine
15:53:51 <asamalik> sgallagh: will do! that's a good point
15:54:00 <langdon> sgallagh: with that example we would need f29:0.1 && f30:0.7
15:54:19 <langdon> hmm... im still not convinced .. but im +0
15:54:39 <langdon> why not just have multiple eols?
15:54:50 <asamalik> langdon: you said +1 already, so are you changing to 0 now?
15:55:00 <langdon> asamalik: just on this change
15:55:02 <sgallagh> asamalik: I think he meant wrt changing the EPEL definition
15:55:07 <langdon> eg. module-eol el8.8 & el9.1
15:55:08 <asamalik> ah ok
15:55:33 <asamalik> #agreed approved UX design of setting module EOL +4 0 -0
15:55:37 <langdon> i would rather allow the user to specify multiple eols
15:55:56 <sgallagh> langdon: -1, but I don't have time to go through why
15:55:58 <asamalik> #action asamalik adds sgallagh's note "the epel example is a placeholder" in the ticket
15:56:04 <langdon> maybe open this part as a new ticket? as it isn't imperative
15:56:51 <asamalik> #topic Modularity UX Questions
15:56:51 <asamalik> sgallagh it's yours! but we're running out of time here :(
15:56:54 <sgallagh> langdon: tl;dr: Fedora is a project with releases F30, F31, etc. EPEL 8 and EPEL 9 are different projects with releases el8.1, el9.2, etc.
15:57:16 <asamalik> sgallagh: +1
15:57:45 <sgallagh> Mostly I just wanted to see what people thought of my last suggestion in that thread:
15:57:46 <asamalik> do we want to keep talking and go over time? or finish on time?
15:57:57 <sgallagh> Disallow profiles with zero packages in them
15:58:14 <asamalik> sgallagh: I agree with that!
15:58:21 <langdon> sgallagh: im confused.. last suggestion where?
15:58:27 <sgallagh> That is a legacy of the original default implementation
15:58:42 <sgallagh> langdon: devel @ thread
15:59:06 <langdon> im soooo confused .. did we change topics to new UX topic?
15:59:11 <sgallagh> We supported it originally because the “default” stream was going to be a special case name.
15:59:13 <asamalik> sgallagh: disallow means fedora policy, or tooling ignoring it/throwing an error?
15:59:32 <sgallagh> This was before we had the Defaults objects which are superior in all regards
15:59:38 <asamalik> because we need to expect it will eventually get into a 3rd party repo somewhere
15:59:59 <sgallagh> asamalik: good question. I was thinking about having libmodulemd reject it.
16:00:25 <sgallagh> But we probably need to confirm that none of the current frozen repos contain such cases.
16:00:26 <langdon> you would never want it as a placeholder?
16:00:45 <asamalik> I would personally allow it on the technical side — people have weird use cases sometimes — but forbid it by Fedora policy, and maybe have tooling to throw a warning
16:00:52 <langdon> an empty profile i mean.. i think i finally understand what is going on
16:00:53 <asamalik> so we're not too clever
16:00:57 <sgallagh> For compat, we could always just treat an empty one as nonexistent and drop the name from the table
16:01:30 <sgallagh> If we allow it to be returned, DNF needs to know what to do with it.
16:02:07 <langdon> what does it hurt to have an empty profile?
16:02:12 <sgallagh> I’m suggesting we make it so that DNF et al will just not see the empty profile.
16:02:22 <sgallagh> langdon: what does it *mean*?
16:02:23 <asamalik> I'd say install all the packages listed there... so none... and don't error out... it's a weird choice someone has made and they might have reasons
16:02:34 <langdon> right..
16:02:39 <langdon> i like the warning on build though
16:02:41 <sgallagh> If we allow it, we need to define its behavior
16:02:58 <sgallagh> How do you warn on build?
16:03:04 <langdon> you "installed" a profile.. but it didn't "do anything"..
16:03:09 <asamalik> I mean warn when installing
16:03:42 <sgallagh> Then it’s inconsistent with our answer for “no default profile”
16:03:45 <langdon> oh.. i don't know why the user would care on install.. they don't care if the profile reqd any rpms.. just thta the use case is satisified..
16:04:04 <langdon> as a module maker, i would like ot know that I may have forgotten to put in the rpms in an empty profile
16:04:33 <sgallagh> Which is an argument for making it an error in libmodulemd
16:04:33 <langdon> you get "no rpms" from profiles all the time.. because you already have them
16:04:34 <asamalik> sgallagh: I'd say in this case it isn't an inconsistency... no default profile means "this module is not installable, it's meant to be used as a repo" basically
16:04:46 <langdon> eg. server profile on postgres; then client profile; nothing installed
16:05:27 <sgallagh> langdon: That's different, in my eyes
16:05:35 <langdon> asamalik: wait, what? is this the "there are no profiles" or "the profile has no rpms"? those are quite different
16:05:53 <asamalik> langdon: "the profile has no rpms"
16:05:56 <sgallagh> langdon: I said above that I think it's inconsistent between those cases.
16:06:06 <langdon> "<sgallagh> Disallow profiles with zero packages in them"
16:06:17 <sgallagh> We more or less agreed that "this module has no default profile" should throw an error on install without profile specified.
16:06:38 <sgallagh> But if the default profile is an empty list? Apparently that's still okay?
16:06:41 <sgallagh> Unclear to me.
16:06:56 <langdon> meh.. ish.. sure.. personally i think "no default profile" should be a warn not an error but +0
16:07:10 <langdon> if any profile is empty.. that seems fine to me..
16:07:36 <sgallagh> And so we just treat is as "no rpms added to the transaction, ergo it's already satisfied"?
16:07:44 <sgallagh> So in this case, does it enable the module stream?
16:07:45 <sgallagh> Should it?
16:07:58 <sgallagh> It didn't need to make any changes, so...
16:08:01 <asamalik> sgallagh: BTW I'm not having a strong position here... written communication :)
16:08:26 <asamalik> sgallagh: yeah you're probably right...
16:08:48 <asamalik> I mean enable is still here, right?
16:08:50 <ignatenkobrain> so what would I do in case of libgit2?
16:09:11 <sgallagh> ignatenkobrain: More detail, please?
16:09:12 <ignatenkobrain> I do not want to have any profiles for libgit2 which means I don't want to have any default profile
16:09:42 <asamalik> ignatenkobrain: so enable + package install?
16:09:52 <sgallagh> ignatenkobrain: In that case, what we're suggesting is that `dnf module install libgit2:stream` should throw an error and suggest that you meant to do `dnf module enable libgit2:stream` instead
16:09:57 <ignatenkobrain> https://pagure.io/releng/fedora-module-defaults/blob/master/f/libgit2.yaml#_7
16:10:00 <ignatenkobrain> is this good enough?
16:10:14 <langdon> sgallagh: i think installation of an empty profile or a no-profile module should just warn "hey i got no rpm for you" and enable the module
16:10:15 <ignatenkobrain> sgallagh: my question was mostly if I should do this in f-m-d or no
16:11:02 <sgallagh> langdon: That's a valid opinion. I wanted to make sure you understood the problem we were trying to solve, because I wasn't sure you did at the beginning
16:11:27 <sgallagh> ignatenkobrain: I'm not sure which part you're asking about
16:11:29 <langdon> sgallagh: i definitely didn't at the beginning :) i didn't realize we had moved to a *different* UX topic :/
16:11:47 <ignatenkobrain> sgallagh: should I put in fedora-module-defaults `$stream: []`
16:11:49 <ignatenkobrain> or not
16:12:01 <sgallagh> ignatenkobrain: That's one of the open questions on the thread.
16:12:12 <sgallagh> I vote "yes", so it's clear that the lack of a profile is intentional
16:12:27 <sgallagh> And we can write automation to detect when it's missing from the defaults
16:12:42 <sgallagh> But that's not decided conclusively yet.
16:12:51 <sgallagh> It will never be *wrong* to do so.
16:13:00 <sgallagh> The discussion will be whether it's mandatory
16:13:08 <sgallagh> ignatenkobrain: Does that help?
16:13:16 <langdon> just on my earlier point.. i am not sure why the end user should be concerned about the packager choice of distribution style.. like what will the end user do with an error that says "you can't use this command *this* time you have to use that command" .. that just sounds annoying
16:14:08 <sgallagh> langdon: The feedback we keep getting is that people don't like `dnf module install <something>` and have it not actually try to install anything
16:15:02 <langdon> sgallagh: yeah.. i don't really understand that position.. like i don't get angry at my computer because I try to install something i already have..
16:16:00 <langdon> we could just change the messaging "we installed the module but no rpms weree required"
16:16:21 <ignatenkobrain> sgallagh: I think we need to be consistent with dnf install. It doesn't error out if something what you try to install is already installed
16:16:41 <sgallagh> Sorry folks, I need to switch to another meeting.
16:16:55 <langdon> i think the confusion is that "installation of a module" is not considered a "install event" .. and so the users are looking for rpms
16:17:42 <langdon> so.. tabling til next week?
16:18:24 <langdon> asamalik: ?
16:19:20 <langdon> #chairs
16:19:24 <langdon> #chair
16:21:43 <langdon> #endmeeting
16:22:46 <ignatenkobrain> heh
16:23:01 <ignatenkobrain> that is the answer about Modularity UX, right? :)
16:23:04 <ignatenkobrain> langdon: ^^
16:24:29 <langdon> ignatenkobrain: something very weird happened with my irc.. so i missed last
16:24:32 <langdon> i am not even sure i am back now
16:24:40 <bcotton> langdon: you're a ghost now
16:24:57 <langdon> bcotton: it is entirely possible
16:25:30 <sgallagh> asamalik: You need to close the meeting
16:25:57 <asamalik> OMG I'm so sorry I got pulled into a meeting and got distracted there :/ langdon ignatenkobrain
16:26:09 <asamalik> that's what happens when we go over time
16:26:27 <asamalik> we'll revisit next time!
16:26:41 <langdon> asamalik: lol..
16:27:01 <langdon> asamalik: i couldn't get any zodbot commands to work.. so i couldn't figure out what was going on
16:27:37 <asamalik> #info we'll continue next week!
16:27:38 <asamalik> #endmeeting