14:01:04 <langdon> #startmeeting modularity_wg
14:01:04 <zodbot> Meeting started Tue Oct 31 14:01:04 2017 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:04 <zodbot> The meeting name has been set to 'modularity_wg'
14:01:28 <langdon> #meetingtopic Meeting of the Modularity Working Group (once every two weeks)
14:01:34 <langdon> #chair cydrobolt dgilmore haraldh langdon mikedep333 sct tflink
14:01:34 <zodbot> Current chairs: cydrobolt dgilmore haraldh langdon mikedep333 sct tflink
14:01:40 <langdon> #topic Roll Call
14:01:44 <langdon> .hello2
14:01:46 <zodbot> langdon: langdon 'Langdon White' <langdon@redhat.com>
14:02:15 <tflink> .hello tflink
14:02:16 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
14:02:36 * tflink has a conflict, will only be paying half attention
14:03:31 <langdon> seems like there are a lot of conflicts :/
14:05:06 <contyk> o/
14:05:11 <contyk> .hello psabata
14:05:12 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
14:05:25 <langdon> i think if it is just the 3 of us in 5m we should just cancel..
14:05:38 <langdon> contyk: did you see my PM?
14:06:16 <contyk> langdon: I did
14:06:30 <contyk> langdon: but it's unrelated to this meeting :)
14:06:36 <contyk> langdon: Igor had an agenda item
14:06:38 <langdon> true :)
14:06:43 <langdon> but he isn't here :)
14:06:57 <contyk> he will be soon; we just finished another call
14:09:09 <ignatenkobrain> .hello2
14:09:10 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
14:09:30 <contyk> there he is
14:09:48 <ignatenkobrain> https://pagure.io/modularity/issue/75
14:09:51 <sct> .hello sct
14:09:54 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
14:09:54 <ignatenkobrain> one should set up #topic
14:10:36 <langdon> ignatenkobrain: i was going to.. but waiting for you to join
14:10:43 <langdon> topic is "roll call" right now
14:10:53 <langdon> #topic agenda
14:11:20 <langdon> 1) https://pagure.io/modularity/issue/75
14:11:36 <langdon> #info  Stream naming conventions https://pagure.io/modularity/issue/75
14:11:40 <langdon> and other topics?
14:12:47 <contyk> nothing really
14:13:04 <langdon> ok... swithing to topic
14:13:20 <langdon> #topic  Stream naming conventions (https://pagure.io/modularity/issue/75)
14:13:52 <langdon> #chair ignatenkobrain
14:13:53 <zodbot> Current chairs: cydrobolt dgilmore haraldh ignatenkobrain langdon mikedep333 sct tflink
14:13:59 <langdon> ignatenkobrain: want to take it away?
14:14:33 <ignatenkobrain> well, I wrote everything in ticket
14:14:43 <ignatenkobrain> I'm in the middle of another meeting so ... ;)
14:14:56 <ignatenkobrain> so can you just copy it here
14:15:01 <ignatenkobrain> I think it contains enough information
14:15:13 <asamalik> .hello2
14:15:14 <zodbot> asamalik: asamalik 'Adam Samalik' <asamalik@redhat.com>
14:15:41 <contyk> in short we need best practices / recommendations for naming streams where one is not immediately obvious
14:15:48 <contyk> for instance for collections of random things
14:15:57 <sct> ignatenkobrain: It all depends on what you want to maintain.
14:16:02 <langdon> isn't this in the guidelines?
14:16:12 <ttomecek> I thought there was already a thread about it (and the result was: f27)
14:16:20 <sct> There was a thread internally, for sure
14:16:34 <sct> modularity is not a free-for-all
14:16:46 <sct> just because you can have 20 versions of something does not mean you _should_. :)
14:16:47 <contyk> langdon: if it's in the guidelines, can you point me to it?
14:17:08 <sct> contyk: I can probably look out the email thread from archives
14:17:34 <contyk> so a specific example is the libtom module which includes two libraries, both from the same upstream project but each with a separate life cycle and update cadence
14:17:59 <contyk> now 'f27' doesn't really make sense; this module has nothing to do with the release
14:18:09 <sct> f27 may still make sense
14:18:12 <contyk> it could be '1', incremented every time one of the libraries is updated
14:18:17 <sct> it depends on the ABI and release expectations
14:18:21 <contyk> or '1-1' or something like that
14:18:30 <sct> You need to have a stable ABI for any application that depends on the library.
14:18:36 <contyk> yes
14:18:41 <sct> So when are you going to switch the version of the library?
14:18:58 <sct> Do you really care about being able to introduce a new version halfway through f27?
14:19:12 <contyk> isn't that one of our features?
14:19:19 <sct> if not, then it should just be f27, and apps depend on it
14:19:21 <sct> contyk: Sort of
14:19:30 <sct> there is no general way to install two versions of the lib at the same time
14:19:37 <ignatenkobrain> that doesn't make sense
14:19:42 <ignatenkobrain> because arbitrary branching
14:19:50 <ttomecek> (nils wrote an e-mail about it on Oct 9th)
14:19:52 <sct> That makes two versions _available_ at the same time
14:19:58 <sct> that doesn't mean they can install together
14:20:13 <sct> this is precisely why we need a stable set of dependencies in platform
14:20:23 <contyk> sct: no one's proposing parallel installation, just having yet another stream when one of the components gets an incompatible update; such stream could be introduced anytime
14:20:24 <sct> so dependencies for different apps don't interfere with each other.
14:20:36 <sct> You can't avoid it
14:20:39 <contyk> sct: question is how to name streams for collections of multiple things with varying update cadence
14:20:51 <sct> if one app depends on the old version and another app depends on the new one, you have a parallel installation conflict.
14:21:17 <contyk> sct: module stream expansion addresses that problem
14:21:25 <sct> So the first question on "how to name it" is whether you want to deal with that situation.  If not, then for dependencies, the default answer is in many cases forced to be "it's one version for the release, so f27 is a reasonable name"
14:22:21 <sct> contyk: Stream expansion doesn't solve the installation problem, if you have two apps installed at the same time requiring different versions.
14:22:29 <sct> Bundling with scl-type repackaging solves it
14:22:32 <sct> containers solve it
14:22:42 <sct> there are various solutions but they are not transparent.
14:23:44 <contyk> sct: no, but if I have applications that require "libtom:*" and MBS builds them against both, I can then install a combination of modules with either of the tom libtom modules, avoiding conflicts
14:24:29 <contyk> sct: while this is not possible right now because the feature hasn't been implemented yet, our recommendations shouldn't be limited by the current state (which will hopefully change soonish), I think
14:25:03 <sct> contyk: For sure.  That only works if the two versions are ABI-compatible, though.  In which case, why not just upgrade to the newer of the two ABI-compatible versions in a single stream?
14:25:24 <sct> You only need to maintain a new stream if you know you are introducing incompatible changes.  Otherwise you can just rebase within the stream.
14:25:27 <contyk> sct: no, they don't need to be ABI compatible, just API
14:25:50 <contyk> sct: when you submit an MBS build with this glob-style dependency, MBS creates two separate module builds
14:25:54 <sct> contyk: The problem is lifecycle
14:26:04 <sct> what happens when there is an app out there that already built against the older ABI
14:26:31 <contyk> then you're limited to libtom with the old ABI and cannot choose
14:26:32 <sct> you cannot now rebuild any other module against the newer ABI without introducing a runtime conflict.
14:26:36 * langdon swears he had a ticket describing conventions that was to be added to the guidelines but can't find it now
14:26:36 <contyk> if you want that app
14:26:37 <sct> Exactly
14:26:51 <sct> so the wild-card API requires: only works at a single point in time
14:26:57 <sct> you need to rebuild everything if you change the ABI
14:27:08 <contyk> sct: yes; it's a build time feature
14:27:11 <sct> and modularity is supposed to make things independent, not to require mass rebuilds
14:27:32 <sct> which is why it's really the ABI properties which dictate what you can do with different streams, not API
14:27:57 <contyk> if that's true, then you can never change anything
14:28:05 <contyk> if every new stream needs to be abi compatible with the old one
14:28:11 <sct> so for the system ABI as a whole, you need to pick one ABI.  "f27" is still a reasonable stream name for that.
14:28:17 <sct> Only for dependencies
14:28:27 <sct> which is why we need a large dependency set in platform.
14:28:34 <sct> Edge modules can rebase arbitrarily
14:28:50 <sct> dependencies cause linkage/conflict between otherwise independent modules.
14:28:54 <contyk> and now we're getting to the question :)
14:29:19 <contyk> ignatenkobrain is packaging a non-platform module with more than one component and wants to know what stream name he should choose for his non-platform module
14:29:27 <sct> So for stream names it all comes down to, under what circumstances would I change to a new ABI?
14:30:12 <sct> If we need it fixed for the duration of f27 due to these dependency ABI issues, it should be called "f27" (or arguably should potentially be added to platform, because it is a de-facto part of the ABI for apps above it)
14:31:29 <contyk> weren't modules supposed to offer life cycles independent of the distro?
14:31:57 <contyk> and parallel availability?
14:32:12 <sct> Only for availability, not installability.  And installability causes major constraints here.
14:32:15 <contyk> if I'm reading you correctly, you're proposing exactly one version of a module that is bound to the base release
14:32:35 <sct> For shared dependencies.
14:32:45 <contyk> anything can be shared if it has api
14:32:55 <sct> We have additional mechanisms if we need to have multiple versions in flight at the same time
14:33:07 <sct> compat-lib packaging is a well known way to do this
14:33:12 <sct> but it's the exception, not the general case.
14:35:59 <ignatenkobrain> I still don't get it
14:36:21 <ignatenkobrain> how it is related to my problem?
14:37:03 <langdon> ignatenkobrain: is there no logical version for the the thing? e.g. httpd-2.2 ?
14:37:15 <ignatenkobrain> no
14:37:21 <contyk> that's the point :)
14:37:34 <asamalik> I would just use "1" :)
14:37:43 <langdon> Yeah.. So my argument has been it should be 1.0
14:37:57 <langdon> Or 1 rather
14:38:12 <sct> Keep it simple, certainly.
14:38:37 <sct> ignatenkobrain: Point is, if you're going to have two streams available at the same time, you need to expect conflicts if different apps require different versions.
14:38:44 <sct> ignatenkobrain: If you have a way to handle that, then great
14:39:07 <ignatenkobrain> sct: I don't care about conflicts. I just want to give ability users to use old verions
14:39:14 <sct> if not, you may be forced to keep a standard version for apps to build against; and if so, then "f27" is a simple fallback stream name that represents the default version you want f27 apps to find.
14:42:02 <ignatenkobrain> so it seems only viable solution us to use 1..2..3...
14:42:08 <ignatenkobrain> f27 doesn't make sense to me at all
14:42:14 <ignatenkobrain> because it has no relation to dstro version
14:42:20 <ignatenkobrain> it is version of module
14:42:28 <ignatenkobrain> s/version/stream/
14:42:40 <langdon> Yeah.. I would expect the "lamp module c
14:42:46 <langdon> Sorry..
14:42:59 <langdon> To also be 1,2,3, etf
14:43:12 <langdon> Goodness I can't type today
14:45:39 <sct> ignatenkobrain: User, or developer?
14:46:06 <sct> ignatenkobrain: because if you give packagers the ability to pick arbitrary conflicting versions of their dependencies, the result is a sprawl of application incompatibility.
14:46:19 <sct> ignatenkobrain: If it's just for end-users, it's a very different story.
14:46:31 <langdon> I think the rule(s) is simple.. F27 for tightly coupled to a platform version or an extension of platform, else version of major component, else, sequential from 1
14:46:35 <sct> It really does depend on what it will be used for and what combinations we want to support in parallel.
14:52:54 <langdon> so.. we really do need an action item to add this to the guidelines
14:53:03 <langdon> but.. is everyone clear here?
14:53:08 <langdon> or is there more to discuss?
14:53:47 <sct> langdon: I think there's a little more --- we should come back after f27 on some parts of this
14:54:17 <sct> as source compat and binary compat are different... the issues change a bit with arbitrary branching if we can build different binary versions based on the same source branch.
14:54:35 <sct> As long as source and binaries share the same stream name, I think the topic is well covered.
14:55:20 <langdon> well.. we only have five minutes left :)
14:55:41 <ignatenkobrain> so we agree on 1,2, 3?
14:56:57 <langdon> ignatenkobrain: i think so.. but to sct's point.. it matters a bit on the use case(s) you see for the module.. but the general rule, yes
14:58:59 <langdon> proposed: #agreed F27 for tightly coupled to a platform version or an extension of platform, else version of major component, else, sequential from 1
14:59:18 <langdon> or if we can't get to that.. maybe move to mailing list?
15:01:27 <langdon> #info tabled discussion til next time or the mailing lists
15:01:36 <langdon> #endmeeting