15:02:03 <langdon> #startmeeting modularity
15:02:03 <zodbot> Meeting started Tue Sep 17 15:02:03 2019 UTC.
15:02:03 <zodbot> This meeting is logged and archived in a public location.
15:02:03 <zodbot> The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:03 <zodbot> The meeting name has been set to 'modularity'
15:02:22 <langdon> #meetingtopic Weekly'ish Meeting of the Modularity Team
15:02:29 <langdon> #topic roll call
15:02:34 <langdon> .hello2
15:02:34 <contyk> .hello psabata
15:02:35 <asamalik> :)
15:02:35 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
15:02:38 <asamalik> .hello2
15:02:39 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:02:40 * asamalik waves
15:02:42 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
15:02:44 <langdon> #chair contyk asamalik sgallagh
15:02:44 <zodbot> Current chairs: asamalik contyk langdon sgallagh
15:03:23 <sgallagh> I am in all-day meetings today and tomorrow.
15:03:37 <langdon> i was just about to say i thought that was true
15:03:38 <langdon> ok
15:03:42 <langdon> #topic agenda
15:03:54 <langdon> current;y we just have https://pagure.io/modularity/issue/148
15:03:57 <langdon> that i see
15:04:02 <langdon> anything else?
15:04:28 * langdon tries to move this along quickly so cipherboy can get to his other meeting
15:04:30 <contyk> 33 more tickets we should look at :)
15:04:39 <langdon> ok.. so
15:04:41 <contyk> not necessarily today, just at some point
15:04:46 <langdon> #info starting with https://pagure.io/modularity/issue/148
15:04:52 <langdon> #info all other tickets
15:04:57 <langdon> #info open floor
15:04:59 <asamalik> I'm looking for input for this: https://pagure.io/fedora-docs/modularity/pull-request/68
15:05:05 <asamalik> ...before I merge it tomorrow :)
15:05:06 <langdon> ahh ok
15:05:14 <langdon> ill put that in after 148
15:05:24 <langdon> ok.. let's goooooo
15:05:39 <langdon> #topic "Encourage following branch naming guidelines in default streams":  https://pagure.io/modularity/issue/148
15:06:58 <cipherboy> So 148 was mostly inspired by the discrepancy between the docs and how modularity is implemented in practice.
15:07:01 <sillebille> Hello everyone! this was suggested by myself and cipherboy
15:08:06 <contyk> while I agree with you, I'm uncertain about dictating this by policy
15:08:21 <contyk> I'd be happier if people decided this among themselves
15:08:25 <cipherboy> Let's start with the obvious question: is it clear? :) There's two solutions: update docs, or encourage following the current docs.
15:08:33 <langdon> well: https://pagure.io/modularity/issue/148#comment-589688 < is missing that modularity is more about "independence" than "reusability".. straight rpms are *very* reusable .. so much so that they block people from using other versions of things
15:10:08 <cipherboy> contyk: My feeling is that these guidelines should've been enforced when the module was created, but weren't.
15:10:09 <langdon> i must admit, I am not sure I understand this ticket
15:10:20 <sillebille> hmmm. When you say "independence" I presume to mean independence from Fedora releases, right? -- By reusable, I thought of "resusing the other modules/packages"
15:10:54 <langdon> sillebille: the fact that you have to apply the patch more than once is kind of a "feature"..
15:11:08 <langdon> but i think what should be happening here is more of a shared module..
15:11:46 <langdon> and i think i agree with contyk.. this seems to be a very specific set of modules and their interactions .. which may not have the same "policy" as the rest of modules in fedora..
15:11:52 <contyk> so if I understand it correctly, you'd like the, in the case default module stream to build from some "standard" branches and not its own
15:12:39 <asamalik> it's important to note that different releases have different defaults
15:12:46 <contyk> I'm not sure why it matters what branch it is or why it should be enforced as long as it can be identified and tracked
15:13:33 <asamalik> I agree with contyk
15:13:54 <asamalik> but I'm also not convinced that our current tools make it easy to connect things together...
15:14:02 <cipherboy> langdon: So, here's our problem. pki-core is a module in RHEL, but not in Fedora. we've tried modularizing it, but all our dependencies were modularized under us, in a way that didn't allow us to use them in the BUILDROOT, because they weren't API exposed, despite being in the default module stream. If we're going to enforce that the default module stream == public API for all packages, we might as
15:14:05 <cipherboy> well enforce that public API == reusable by other packages/modules/&c., and have a module-independent naming scheme for package branches.
15:15:22 <langdon> everything you said made sense to me until "and have a module-independent naming scheme for package branches." < what does branch name have to do with anything?
15:15:45 <langdon> public api *does* = reusable by everyone else
15:17:15 <cipherboy> Sure, then update the docs.
15:17:44 <langdon> you don't think the docs say public api = reusable? that has been a core tenet since near the beginning
15:17:54 <langdon> asamalik: ^^ ??
15:18:19 <cipherboy> No, I think the docs say that *package* branches should follow the version of the *package*, not that of the module. :-)
15:18:42 <langdon> wait, what? how did we get to branch names again?
15:19:24 <asamalik> langdon: sorry, not sure what you mean by public api = reusable
15:19:41 <contyk> the branch names shouldn't matter, just the api
15:20:02 <langdon> any rpm listed in the "api" block of a module metadata are promised to be "supported" by the module maintainer..
15:20:25 <asamalik> but yes the docs say that package branches should reflect the package version as I remember, but the branch name of packages is not visible to users anyway and is independent of a package being an api or not I'd say
15:20:27 <langdon> in the case of a library, that would mean you can reuse it in your module
15:20:37 <cipherboy> Because branch names encourage reusablity or hinder it; if the package branch is named "my-pet-module", then someone else building $TOOL won't contribute to that package. If its a more general name like "package:version", then my view is that it'll *encourage* community contributions.
15:21:04 <contyk> that's a fair point
15:21:07 <asamalik> cipherboy: yes that makes sense
15:21:18 <contyk> although "my-pet-module" is vastly different from a branch named after the module :)
15:21:36 <langdon> ohhhh... maybe i see.. i think thte package branch names *should* reflect the name/version of the package.. not the moduel.. and, in fact, thought that was what the docs did say
15:22:04 <cipherboy> Think of it from the POV from the SIG: if these public API'd packages (that we co-maintain as ursine packages) get dropped into the default module stream's API... would the SIG be likely to contribute to the javapackages-tools-201901 module stream... or would we be more likely to contribute to a apache-commons-lang:2.10 stream? :)
15:22:09 <langdon> only if the package has some weird spike for a particular module..
15:22:16 <contyk> the thing is the package branches might not matter as much for the overall stack or application, so naming them after the module might make more sense
15:22:37 <contyk> rather than having a new branch whenever there is an update of one of your components
15:23:13 <langdon> contyk: i think that is unlikely .... even when the use cases are different the lib/code is likely built the same way
15:23:20 <asamalik> langdon: yes, agree, that's what we've been encouraging since the beginning and what's also in the docs... but I also agree with what contyk is saying that it's not practical in some cases
15:23:49 <cipherboy> contyk: Right, the motivation here is the modularization of a lot of the Java libraries. They're part of default module streams, and not in any way specific to the modules they're used in. The SIG has gone and copied many of the modules updates and shipped them in the Ursine variants. In other places, we've updated past where the module is at, by a minor version or two.
15:23:49 <contyk> cipherboy: now that sounds like you'd like to have a module for every package
15:24:26 <asamalik> I think the problem is not the branch name, I think it's what our tools show us
15:24:58 <cipherboy> contyk: No, the java modules can continue to exist as-is; just that by shipping packages in the default module streams, we should *contribute* to those libraries, not duplicate the work.
15:25:17 <asamalik> if I opened pagure, went to the "httpd" package, and saw "pizza", "salad", and "fish" branches but it would clearly tell me that the "salad" branch is what's shipped in f30 and f31 as a default, that would basically solve our problem, right?
15:25:35 <contyk> cipherboy: it's just your "apache-commons-lang:2.10 stream?" that I found a bit misleading :)
15:26:39 <asamalik> the branch names are not a problem, but since they're now release independent, having back the ability to easily connect them back with a release (or multiple releases) they're going into is what we basically need
15:26:49 <cipherboy> contyk: It is a 2.10 version of the apache-commons-lang package; the java module would say, well, to build say, ant, I need to pull apache-commons-lang at version 2.10 -- and if we eventually need say, apache-commons-lang at version 3, we could create a separate stream. If it continues to be shipped in the default module stream, then it might break packages, but whoever is broken can modularize and
15:26:50 <asamalik> I might be wrong, but that's what I see here
15:26:52 <cipherboy> dep on the 2.10 branch.
15:27:20 <langdon> i also think this is a reflection of not having default-module-streams in the buildroot in fedora..
15:27:23 <cipherboy> asamalik: There is only one java package branch; it is shipped on every platform everywhere. (f29+?) so that's not the issue.
15:27:29 <langdon> asamalik: i was already hungry for lunch
15:28:05 <langdon> contyk don't forget everything in Java land has long, cumbersome names
15:28:43 <contyk> it's just that, as far as I know, we haven't used the term "stream" for packages, just for modules
15:29:01 <contyk> I know what you mean, just why I thought it was a bit misleading
15:29:24 <contyk> anyway, I agree it would make it easier to navigate if package branches following this naming scheme
15:29:52 <contyk> although it would also mean editing the modulemd file's refs all the time
15:30:11 <contyk> and lots and lots of branches
15:31:28 <langdon> only when they are weirdly versioned.. I'm not sure apache-commons needs 2.1 vs just 2
15:31:53 <contyk> that's another question
15:31:54 <cipherboy> Depends on how frequently the deps are updated. What the Stewardship SIG found was that a *lot* of deps were *very* out of date, and "maintained" mostly meant keeping it in Fedora, at the same version. :)
15:32:22 <langdon> but this was the tagging idea we discussed some while ago about having a pointer at latest branch u could use in a modulemd
15:32:23 <mbooth> cipherboy: Such packages should be retired IMO
15:32:44 <cipherboy> mbooth: We've retired a bunch and others we have updated.
15:33:14 * asamalik has definitely heard the term "stream" in connection with packages... and the 2.1.1 vs 2.1 vs 2 granularity is a part of the deal — maybe that's where we need to be more clear
15:33:37 <cipherboy> asamalik:  I think it comes from RHEL... There we have "stream-1.0-module-name" branches on our packages.
15:34:06 <langdon> we could just tell the whole open source software world to start being consistent
15:34:26 <cipherboy> langdon: g'luck!
15:34:40 <contyk> cipherboy: that's for special RH RCM reasons :)
15:34:41 <asamalik> langdon: can I action you on that? do you need the whole week until Friday or can you do that by Thursday? :P
15:35:11 <langdon> ha
15:35:20 <cipherboy> contyk: Right, but it is perhaps where people started calling package branches "streams" :-)
15:35:23 <contyk> so personally I wouldn't be against having a branch for every single upstream release
15:35:35 <contyk> and then just making sure the modulemd points to the right places
15:35:46 <langdon> +1
15:35:53 <contyk> but branch creation must be easy
15:36:00 <langdon> esp if it was automatica
15:36:12 <asamalik> to clarify, I heard the "package stream" in reference to the package versions, not the module stream
15:37:03 <langdon> w/ packages it may be more accurate anyway
15:37:22 <mbooth> The docs say, about creating package branches: "BRANCH — name of the stream branch of the package and the module"
15:37:26 <mbooth> Is this incorrect?
15:37:28 <langdon> assuming sometimes packages are built differently despite being the same version
15:37:42 <asamalik> contyk: I agre partially... from a practical standpoint, we as a community might be able to come up with resources to maintain let's say two or three of those, but if there are ten+ branches, it might be confusing to decide which ones to contribute to
15:38:18 <contyk> asamalik: at that point the tooling could be enhanced to make it more visible which of those are used and where, as you suggested
15:38:34 <asamalik> contyk: that's a very fair point
15:38:38 <langdon> we would need a visualization of the ecosystem.. so you could easily see which branches are actually in use in fedora
15:38:42 <cipherboy> I think people will contribute to whichever version they need... And sorting branches by "most recent commit" might help. :)
15:38:42 <langdon> ha..
15:38:59 <asamalik> contyk: actually, those two together I'd definitely +1
15:39:01 <contyk> and hide the rest; but at some point someone might want to make a historical app module that uses old content... and why not
15:39:39 <contyk> yeah, I think this might be a sustainable way to do things
15:40:01 <asamalik> yeah like show "active branches: '6.1' in f29 and f30, '7.5' in f31; non-active (hidden) branches '6.2', ..."
15:40:18 <asamalik> or something like that
15:40:35 <contyk> mapping it to releases might not be necessary
15:40:53 <asamalik> or either three categories of default, non-default, not used
15:41:24 <asamalik> maybe mapping to module streams might be enough, yeah
15:41:46 <asamalik> or both releases and module streams... but I might be digging to deep at this moment :)
15:42:39 <asamalik> cipherboy: sorting branches by recent commit could definitely help, too, yes!
15:43:19 <asamalik> now we just need to find someone to design it, code it, test it, and deploy it :)
15:46:49 * asamalik points out he would love to do that, but can't commit to that with all of the other things going on...
15:46:55 <asamalik> maybe the design part I could do!
15:48:33 <contyk> so perhaps we should review the docs and make sure these best practices are mentioned clearly
15:48:51 <contyk> in a guidelines sort of way
15:49:23 <contyk> then I wonder if it should be approved by FPC
15:49:39 <contyk> but technically it's not packaging
15:50:14 <cipherboy> Modules aren't packaging? :)
15:50:22 <contyk> branching is not packaging
15:50:28 <asamalik> has anything modularity-related been approved by FPC?
15:50:47 <asamalik> but yes it's just branching, it has no effect on the output
15:51:30 <contyk> we can certainly bring it to fpc for discussion
15:51:37 <asamalik> and the docs say this, but possibly in a little cryptic way, so updating that part might help a bit
15:52:22 <contyk> it might make it more official; I've seen those opinions about our docs, saying they're not binding
15:52:40 <asamalik> yep :)
15:52:44 <contyk> langdon says his connection dropped
15:52:53 <contyk> fyi
15:53:37 <asamalik> so what's the next action? :)
15:53:42 <contyk> so okay, if we agree that we should branch for every release of a package and then adjust modulemd accordingly
15:53:52 <contyk> and that's how it should be done by everyone
15:53:59 <langdon> ah ha.. im back!
15:54:01 * langdon reads
15:54:02 <contyk> I can raise that with FPC and see what they think, if they want to bless it
15:54:05 <langdon> thats what i was going to ask.. any #agreed or #info? or a response for the ticket?
15:54:20 <contyk> making it user friendly in our tooling is another step
15:54:47 <asamalik> that might be actually a step before enforcing that
15:54:50 <langdon> fpc & council have determined that modularity team determines packaging rules for modules
15:55:07 <langdon> asamalik: which might?
15:55:15 <asamalik> langdon: 1/ agreement, 2/ tooling, 3/ enforce
15:55:44 <langdon> ahh.. 1 = fpc agreement? does it need devel@agreement (or discussion)?
15:56:05 <asamalik> because that would otherwise add a lot of manual labour which wouldn't help Modularity being loved and used :)
15:56:19 <langdon> right?
15:56:25 <asamalik> I'd say 1/ was a general agreement including FPC, Modularity Team, etc
15:56:28 <langdon> oops... no "?"
15:56:39 <asamalik> ha
15:57:15 <contyk> well, for #1, I'd still go to FPC
15:57:25 <asamalik> yep agree
15:57:44 <contyk> then we can ensure the docs appropriately reflect that and do the rest
15:57:55 * asamalik points out we have 2 mins left
15:58:07 <langdon> proposed #agreed modularity team recommends packages get a branch per upstream "version" ; proposed #action contyk to run the idea by the FPC
15:58:17 <contyk> +1, +1
15:58:24 <asamalik> +1 +1
15:58:31 <langdon> #agreed modularity team recommends packages get a branch per upstream "version"
15:58:44 <contyk> try it without the space
15:58:45 <langdon> #agreed modularity team recommends packages get a branch per upstream "version"
15:58:50 <langdon> yeah.. surprised by that
15:58:55 <asamalik> 
15:59:00 <asamalik> you can only send a space!
15:59:06 <langdon> although.. still didn't seem to help
15:59:06 <langdon> #action contyk to run the idea by the FPC
15:59:24 <asamalik> I don't think there's feedback for that from zodbot
15:59:39 <langdon> yeah.. guess not.. should be in the log either way
15:59:46 <asamalik> zodbot++
15:59:48 <langdon> ok.. so.. thats about all we have time for..
15:59:55 <asamalik> maybe not alive :P
16:00:01 <asamalik> thanks all!
16:00:01 <langdon> contyk: do you want to update the ticket after you have talked to fpc?
16:00:42 <contyk> sure
16:00:52 <contyk> next week's chair?
16:01:29 <langdon> i can do it
16:01:49 <langdon> #info langdon to chair next week (sept 24)
16:01:55 <langdon> end meeting?
16:02:01 * contyk nods
16:02:07 <langdon> #endmeeting