15:00:47 <langdon> #startmeeting modularity_wg
15:00:47 <zodbot> Meeting started Thu Jun  2 15:00:47 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:47 <zodbot> The meeting name has been set to 'modularity_wg'
15:00:52 <contyk> .hello psabata
15:00:53 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:01:02 <langdon> .hello langdon
15:01:03 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:01:04 <sct> .hello sct
15:01:07 <zodbot> sct: sct 'Stephen Tweedie' <sct@redhat.com>
15:01:12 <langdon> #Chair dgilmore, cydrobolt, harald, jkurik, langdon, mikedep333, sct, tflink
15:01:13 <zodbot> Current chairs: cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink
15:01:32 <jkurik> .hello jkurik
15:01:33 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
15:01:40 <dgilmore> hola amigos
15:01:42 <tflink> .hello tflink
15:01:44 <lkocman> yo!
15:01:44 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:01:55 <lkocman> .hello lkocman
15:01:55 <langdon> jkurik, i just added you to the agenda.. for a scheduling update.. you cool with that?
15:01:56 <zodbot> lkocman: lkocman 'None' <lkocman@redhat.com>
15:02:06 <jkaluza> .hello jkaluza
15:02:07 <zodbot> jkaluza: jkaluza 'Jan Kaluža' <jkaluza@redhat.com>
15:02:15 <geppetto> .hello james
15:02:16 <zodbot> geppetto: james 'James Antill' <james.antill@redhat.com>
15:02:17 <contyk> lkocman: cool name
15:02:31 <lkocman> contyk: I wanted to trick the system
15:02:42 <cpacheco> .hello cpacheco
15:02:45 <zodbot> cpacheco: cpacheco 'Courtney Pacheco' <cpacheco@redhat.com>
15:02:53 <contyk> lkocman: try drop table next time
15:03:10 <nils> .hello nphilipp
15:03:10 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:03:17 <langdon> #topic roll call ^^
15:03:28 <langdon> #topic proposed agenda
15:03:50 <langdon> #info scheduling update from jkurik
15:03:51 <langdon> #info idea for faq
15:03:51 <langdon> #info demos
15:03:51 <langdon> #info module depsolving automation [sct]
15:03:51 <langdon> #info proposed "release" for flock
15:03:52 <langdon> #info open floor
15:03:58 <langdon> anything to add anyone?
15:04:18 <cliff-hm> (listening/watching)
15:04:33 <langdon> agenda is here: http://piratepad.nl/modularity-wg-agendas with lots of fancy links if you want to be a chapter ahead
15:04:56 <langdon> make sure you look for june-2 though.. as june-9 is already getting populated :)
15:05:23 <langdon> #info also, we may not have time for open floor.. so please let me know if there is something you are holding for that
15:05:30 <langdon> ok.. moving on
15:05:39 <langdon> #topic scheduling update from jkurik
15:05:46 <langdon> jkurik, you have any updates?
15:06:24 <jkurik> ok, so from the "whenisgood" the winner is Tuesday - 11:00 AM
15:06:32 <tflink> timezone?
15:06:46 <jkurik> there were only 3 people, who can not join (I was one of them, but I can adapt)
15:07:04 <jkurik> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UTOCPHITXCRM7JH2ZH7OVIDVWWQULIMI/
15:07:14 <langdon> jkurik, im guess eastern cause that was what whenisgood defaulted too
15:07:15 <jkurik> tflink: Timezone: US/Eastern
15:07:36 <nils> so same time as today, only on Tuesdays
15:07:42 <langdon> nils, righto..
15:07:47 * langdon speaks from eastern ;)
15:07:53 <langdon> today
15:07:54 <yselkowitz> that conflicts with #fedora-arm meeting :-(
15:07:56 <sct> Hmm --- since that whenisgood, we've scheduled a biweekly grooming meeting at that time
15:08:10 <langdon> sct, i think we could just swap it
15:08:21 <sct> langdon: That's the smaller meeting with you and me, though, it might be the easier one to switch
15:08:21 <sct> yep
15:08:49 <dgilmore> who where the people that could not make it?
15:08:50 <tflink> is that starting next week?
15:08:52 <langdon> ok.. so.. +1s for (argghh.. thinking utc.. /me digs)
15:09:18 <dgilmore> langdon: we work in UTC :)
15:09:19 <langdon> so.. 15h UTC on Tues
15:09:19 <jkurik> ok, so if you do not mind I would ask for voting, whether we can agree on the Tuesday - 11:00 AM (US/Eastern)
15:09:37 <tflink> +1 from me
15:09:37 <langdon> thats what i was trying to do :) .. but couldn't remember the conversion
15:09:41 <jkurik> tflink: that will go next
15:10:03 <nils> +1
15:10:08 <langdon> jkurik, should i do something "special" to indicate a vote?
15:10:26 <tflink> proposed #agreed Change weekly meeting time to .... ?
15:10:52 <jkurik> langdon: no
15:11:20 <langdon> proposed #agreed Change weekly meeting time to 15h UTC on tuesdays
15:11:27 <jkurik> dgilmore: sct (due to the meeting with langdon I guess) and Vera ... and me
15:11:28 <dgilmore> +1
15:11:31 <langdon> #info proposed #agreed Change weekly meeting time to 15h UTC on tuesdays
15:11:53 <jkurik> I am +1 as well
15:11:54 <tflink> ack/+1
15:11:59 <langdon> +1
15:12:04 <sct> +1
15:12:20 <langdon> #chair
15:12:20 <zodbot> Current chairs: cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink
15:12:42 <langdon> any other voting members here? haraldh
15:12:50 <jkurik> so, we have sct, langdon, dgilmore, tflink, nils, jkurik as +1
15:13:00 <langdon> cydrobolt, mikedep333 ?
15:13:06 <jkurik> that is 6 people
15:13:12 <nils> jkurik: I'm not a voting member FTR
15:13:14 <geppetto> FYI: http://paste.fedoraproject.org/373777/64880370/
15:13:24 <jkurik> nils: ah, so we have 5 people as +1
15:13:31 <langdon> geppetto, ha.. thanks!
15:13:49 <langdon> jkurik, yeah.. im just worried that the same people who can't be here now can't be here then
15:13:50 <geppetto> One without color codes: http://paste.fedoraproject.org/373778/88041314/
15:13:50 <jkaluza> +1
15:14:08 <langdon> but.. let's call it agreed.. and send it to the ML.. and hope?
15:14:25 <jkurik> langdon: unfortunatelly there is no a time slot which fits to all
15:14:34 <langdon> jkurik, yeah.. i know
15:14:35 <nils> uhm, does the meeting stay on UTC, go with East Coast DST rules, ....?
15:14:37 <langdon> ok.. done
15:14:42 <jkurik> ok, so ...
15:14:45 <langdon> nils, stays utc
15:14:52 <langdon> #agreed Change weekly meeting time to 15h UTC on tuesdays
15:15:16 <langdon> jkurik, can you announce it? and change the mtg time in fedocal?
15:15:45 <jkurik> langdon: I do not have the permission to maintain the fedocal I guess...
15:15:51 <jkurik> langdon: let me check...
15:16:03 <langdon> jkurik, ahh ok.. ill fix it while in the meeting..
15:16:09 <langdon> other people just need to talk a lot
15:16:14 <langdon> ok.. lets move on..
15:16:22 <langdon> #action langdon to fix fedocal
15:16:26 <jkurik> langdon: one more think ...
15:16:33 <langdon> #action jkurik to announce new meeting time to ml
15:16:37 <jkurik> do we start from the next week ?
15:16:38 <langdon> jkurik, shoot
15:16:53 <langdon> i would think, yes.. agree?
15:16:57 <jkurik> ack
15:17:14 * langdon mutters should have put that in the original proposal
15:17:24 <langdon> any other opinions? -1s ?
15:17:43 <langdon> ok
15:17:52 <tflink> is there a majority case for whether fedora meetings stay UTC or move with US DTC?
15:18:00 <tflink> ie, which is more common?
15:18:07 <langdon> all the others i know of follow utc..
15:18:29 <bconoboy> I've only ever seen UTC
15:18:31 <tflink> qa and docs follow us DTC for some reason
15:18:47 <tflink> "because we've always done it that way" IIRC
15:18:51 <langdon> im pretty sure council follows utc..
15:18:57 <langdon> but i may be misremembering
15:19:02 <jkurik> Fedocal shows you the timezone you have in your settings
15:19:07 <langdon> lets just say follow utc and fix it later if nec.
15:19:15 <jkurik> langdon: so lets move on, I will change the meeting in Fedocal starting the next week and will announce it on mailing list
15:19:25 <langdon> #agreed time change for the meeting starts next week (making next meeting June 7 15h UTC), the meeting will follow utc
15:19:31 <tflink> sure, just wondering which was more common, dtc/summer time is always a mess :-/
15:19:39 <langdon> jkurik, ok.. you are doing fedocal?
15:20:05 <langdon> tflink, http://www.standardtime.com/
15:20:08 <langdon> ok..
15:20:09 <jkurik> langdon: if you give me the permission to change the meeting I will do it
15:20:12 <langdon> next topic i think
15:20:22 <langdon> jkurik, will do .. if i can figure out how :)
15:20:33 <langdon> #topic idea for faq
15:20:33 <tflink> langdon: if it were up to me, DST and all its ilk would die in a fire :)
15:20:42 <yselkowitz> tflink++
15:20:42 <zodbot> yselkowitz: Karma for tflink changed to 8 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:20:44 <langdon> tflink, +1
15:20:49 <langdon> #link https://fedoraproject.org/wiki/Modularity_Working_Group/releases/Flock_2016_Release
15:20:52 <langdon> oops
15:20:55 <langdon> wrong link
15:20:57 <langdon> #undo
15:20:57 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7fb2368bac10>
15:21:28 <langdon> #link https://ask.fedoraproject.org/en/question/88488/faq-for-modularity/
15:21:53 <langdon> so.. basically was thinking of using ask.fp.o for the faq for modularity vs the janky wiki page linked to now
15:22:26 <langdon> jwb had a concern of fragmentation of info for modularity.. and i don't disagree... which is why nils has a card to clean some of that up :)
15:22:40 <langdon> but jwb does not appear to be here to bring it up
15:23:00 <langdon> any opinions?
15:23:17 <dgilmore> I have never used ask
15:23:17 <nils> langdon: it seems I have gotten my name off of that one when we moved it back to next/backlog? Like somebody else would pick this up ;)
15:23:25 <contyk> dgilmore: +1
15:23:45 <tflink> i've never used it much, either
15:23:54 <langdon> kinda like stackoverflow.. if there are categories.. it can be a better way to track questions
15:23:57 <dgilmore> I am not sure we have any great place for the info
15:25:28 <langdon> ok.. well... we don't have an answer from the admins yet anyway.. so why not just table it, unless there are serious -1s .. and let whoever is cleaning up content figure it out?
15:25:46 <tflink> wfm
15:26:01 <dgilmore> ask has been heavily targeted by spammers
15:26:01 <langdon> ok.. if i can type.. next topic
15:26:13 <dgilmore> but so has trac and other pieces of Fedora
15:26:14 <langdon> dgilmore, i actually get good info there pretty regularly
15:26:41 <langdon> #topic demos
15:27:03 <lkocman> hoooray!
15:27:12 <langdon> so.. i know there are some concerns about the demo content.. like stylistically.. so..
15:27:33 <langdon> i am hoping cpacheco can send out her "instructions" to the ML and put them on the wiki.. and people can comment on them
15:27:49 <langdon> and.. hopefully they will get better over time
15:27:55 <langdon> but.. for now:
15:28:02 <langdon> wall of text coming up
15:28:23 <langdon> #link https://www.youtube.com/playlist?list=PLcwHJG45BmANqgU_Q0fZoCwqFOwE7vaUl < youtube playlist
15:28:45 <langdon> #info following links are the direct links to fp.o/modularity hosted demos
15:28:51 <lkocman> langdon: my demo is missing
15:28:57 <langdon> #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-contyk-guidelines.ogv
15:28:57 <langdon> #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-cpacheco-rawhide-docker-minimization.avi
15:28:57 <langdon> #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-jkaluza-fm-deps.ogv
15:28:57 <langdon> #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-jstanek-pungi-pdc.webm
15:28:57 <langdon> #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-karsten-pungi-pdc-install-and-usage.mkv
15:29:00 <langdon> #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-lkocman-pdc-trees.mp4
15:29:02 <langdon> #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-nils-pdc-pungi-compose-docs.ogv
15:29:05 <langdon> lkocman, BY DESIGN!
15:29:06 <cpacheco> lkocman: i tried uploading your video and apparently it's a duplicate?
15:29:07 <langdon> kidding
15:29:26 <cpacheco> youtube deleted it
15:29:27 <lkocman> langdon: people are skipping me on purpose :-) (youtube channel only)
15:29:36 <langdon> lkocman, bwhahahaha
15:29:48 <lkocman> cpacheco: perhaps they couldn’t handle all the new features
15:30:01 <langdon> lkocman, ok.. maybe you can cpacheco can try to sort it offline? and let us know here when it is fixed?
15:30:04 <lkocman> sure
15:30:08 <langdon> lkocman, im sure that is it!
15:30:18 <langdon> any other comments/concerns on demos?
15:31:16 <langdon> ok.. moving on then
15:31:25 <langdon> #topic module depsolving automation [sct]
15:31:35 <langdon> sct, takae it away...
15:31:41 <langdon> *take even
15:31:48 <sct> OK, so this came up in discussion w/ lkocman:
15:31:54 * lkocman listens
15:32:02 * lkocman reads
15:32:13 <sct> There's a principle I'd like to see applied when we build modules, that is somewhat contrary to traditional composes.
15:32:26 <sct> Dependency resolution:
15:32:36 <langdon> #chair lkocman sct
15:32:36 <zodbot> Current chairs: cydrobolt dgilmore harald jkurik langdon lkocman mikedep333 sct tflink
15:32:39 <sct> I really do *not* want a module build to pull in dependencies automatically
15:32:45 <sct> because
15:32:53 <sct> if a module doesn't have all that it needs to pass repoclosure,
15:33:04 <sct> then it should be a human decision to decide where the missing packages need to go
15:33:20 <sct> or whether in fact the dependency should be trimmed, eg. by subpackaging or adding weak dependencies.
15:33:31 <sct> It's especially important to combat dependency sprawl over time ---
15:33:47 <sct> if all new dependencies just get added automatically, we lose the ability to detect that sprawl and attempt to combat it.
15:33:50 <lkocman> sct: right but with big scale of packages … it would be nice to run it in two modes (get all the missing deps…) diff outputs place newly gathered rpms set lookasides … do it again
15:34:15 <lkocman> sct: I see depsolving benefitial in order to get stuff into shape … once it’s in shape … manual mode and maintain it
15:34:17 <sct> So the idea is, we do repoclosure, we *report* what additional packages would be needed to complete dependencies, but we don't add them unless/until somebody decides where to add then
15:34:19 <sct> them
15:34:37 <sct> and the module build just happens from a static manifest of packages for the module.
15:34:47 <sct> Right
15:34:58 <lkocman> sct: as far as modules goes … this is acceptable and makes sense. Since I’m dealing with traveling packages for years
15:34:58 <sct> and dgilmore: we thought you might have a perspective on this too;
15:35:18 <lkocman> sct: as far as non-module variants goes … (Everything) depsolving is very much wanted
15:35:29 <sct> for really large modules (and eg. if we want to build a module of "all the random unclassified stuff that isn't in any other module"), we might want to enable depsolving automatically
15:35:38 <sct> right
15:35:38 <langdon> lkocman, what do you mean by "non module variants"?
15:35:56 <sct> langdon: == traditional edition composes, I think
15:36:02 <lkocman> langdon: E.g. variant named Everything
15:36:02 <langdon> ohh ok
15:36:18 <lkocman> langdon: +1
15:36:48 <langdon> i guess i would much rather see an "everything-module" which has explicit depsolving turned on.. then treat it as "not a module"
15:36:49 <sct> So question is, is the non-dep-adding mode reasonable as a default, and what corner cases exist that might need depsolving turned on manually
15:36:51 <dgilmore> sct: I suspect there are many cases where we will have to use dep solving
15:37:03 <lkocman> langdon: I treat modules as variant type=module ...
15:37:06 <langdon> sct, +1
15:37:15 <sct> dgilmore: I expect so, but I'm trying to get a picture of what those cases are
15:37:16 <lkocman> langdon: which is just transformation of what you’ve said
15:37:20 <langdon> lkocman, right.. i want "all the things" to be modules..
15:37:30 <lkocman> langdon: +1 can be
15:37:37 <lkocman> langdon: over time
15:37:45 <sct> dgilmore: because I know dependency sprawl is something we've seen repeatedly over the years, every time we try to reduce minimum fedora install sizes it's back up in a release or two.
15:38:06 <langdon> sct, dgilmore i would argue it might be interesting to see what "breaks" without depsolving.. to make sure we understand all the cases
15:38:15 <lkocman> langdon: keep in mind that Everything module as it is now is not achievable from rpm point of view
15:38:26 <sct> dgilmore: So for smaller, well-defined modules I really want to have manual intervention rather than assuming every new dependency is wanted.
15:38:33 <dgilmore> sct: yes, and I do not see modules as fixing that in any way shape or form
15:38:40 <lkocman> langdon: if you build one package with different features … you can’t have them all in single repo
15:38:42 <langdon> lkocman, i would like to discuss that.. but it is orthogonal to this convo.. so let's wait
15:38:46 <lkocman> yup
15:38:50 <dgilmore> sct: the issue is that eveyone makes a decision based on isolation
15:38:52 * lkocman writes note
15:39:05 <dgilmore> sct: foo adds a dep on bar, its small and useful
15:39:17 <dgilmore> but when you add all the foos and bars it becomes huge
15:39:28 <langdon> dgilmore, but in module-land.. no one else can use bar unless they actually add it themselves
15:39:39 <sct> dgilmore: Right.  And a static manifest for modules lets us detect the net impact of that small addition
15:39:40 <dgilmore> if anything modules developed in isolation will make the big picture harder to see
15:40:07 <sct> Well, another part of the modularity plan is to be able to rebuild related modules when a dependency changes
15:40:09 <dgilmore> sct: no it does not
15:40:13 <langdon> dgilmore, that is definitely true.. and visualization needs to be on the radar.. which is where we have been looking at insim
15:40:36 <sct> so if there's a net impact on some other area, then yes, the tools *would* be able to highlight that.
15:40:39 <lkocman> sct: static manifest isn’t tracking buildroot changes
15:40:48 <lkocman> sct: otherwise +1
15:41:03 <dgilmore> sct: its not one change in isolation though. its many small changes over time that make things creep
15:41:13 <sct> dgilmore: It's not a panacea, absolutely, but I do think it's useful.
15:42:10 <langdon> well.. it does help a lot.. right.. because it is the "module's problem" not "fedora's problem"
15:42:14 <langdon> ?
15:42:57 <sct> If we have a base runtime module and suddenly get unexpected packages needed by it; and the base maintainer's mandate includes keeping the minimum base small;
15:43:02 <dgilmore> langdon: not as I see it
15:43:12 <sct> then this absolutely gives us notice at the right place and time to prevent that dependency from being automatically included
15:43:25 <dgilmore> it may help in cases where other modules pull in unexpected things
15:43:42 <sct> and lets us figure if it's really needed, or whether it should be an optional addition installed in a separate module, for example.
15:44:20 <sct> Also, if a stack pulls in a new set of packages, how do we decide which module in that stack the new deps should best live in, even if we do want them?  That should also be a manual, not automatic, decision
15:44:29 <dgilmore> sct: it may be that the base/core/ring (0-1) bits we manually deal with deps
15:44:38 <dgilmore> and the outliers we just do dep solving
15:44:57 <dgilmore> KDE is likely going to want whatever is pulle din
15:45:07 <dgilmore> XFCE and gnome the same
15:45:08 <sct> dgilmore: Yes, I'd expect that outliers would be much less inclined to spend a lot of effort on this.
15:45:24 <dgilmore> but core parts we may want better control
15:45:52 <dgilmore> sct: I do then wonder how we will deal with things like systemd adding a dep on microhttpd
15:46:06 <langdon> just to be clear.. depsolving is still done.. but it is part of the "module design" step .. vs the "build step"...
15:46:08 <dgilmore> in the past thats a change forced on us that was not desired by many
15:46:19 <dgilmore> in the end we had no choice
15:46:40 <sct> dgilmore: Ideally, weak deps allow us to make that optional.  But yes, sometimes there will be hard discussions to have, the tools can't solve them for us -- all they can do is point them out.
15:46:57 <dgilmore> but in a module world how will we resolve the conflicts between upstream forcing changes and module owners not wanting it
15:47:16 <sct> That's not a new problem. :)
15:47:22 <lkocman> dgilmore: langdon sct: can we track some agreement here? At least as far as tooling features and default behavior goes?
15:47:38 <dgilmore> its not a new problem, just becomes a different argument
15:47:39 <lkocman> dgilmore: it could change over time if we see it’s not doable
15:47:53 <sct> dgilmore: One thing that might help there, though, is better statement of high-priority requirements ---
15:47:53 <dgilmore> lkocman: nothing is set in stone
15:47:59 <lkocman> dgilmore: +1
15:48:02 <geppetto> sct: but historically we've completely failed at it, and is one of the major reasons behind why we have dep. bloat
15:48:22 <sct> it's definitely a goal to reduce the number of updates affecting the common base (because every time we do that we need to rebuild all layered docker images, etc)
15:48:35 <sct> geppetto: I know.  And there's no magic bullet.
15:48:43 <dgilmore> it may effect our ability to produce anything if there is a conflict low down
15:49:00 <lkocman> geppetto: it’s this + people don’t really understand core packages in non-fedora … why isn’t x,y.z on that particular variant …. well because additional-devel isn’t available on this particular variant … and so on … and this is bloating distros
15:49:12 <dgilmore> sct: I am pretty firmly in favour of having deps be resolved automatically
15:49:19 <dgilmore> with notifications over changes
15:49:32 <dgilmore> but I am open to having the core pieces being manual
15:49:53 <langdon> dgilmore, what is the difference between doing the depsolving at design time vs build time?
15:50:02 <sct> Most of the modules we're starting with are fairly small and self-contained like httpd or php, or are intended to be carefully maintained like core/base
15:50:20 <sct> and I think depsolving should be off for most of those.
15:50:26 <dgilmore> sct: ideally when a package build is done, we do testing in taskotron straight away and we get really early notification that something unexpected changed
15:50:30 <sct> But for larger ones like gnome or anaconda, yes, it should be on.
15:50:39 <langdon> sct, why?
15:50:47 <langdon> like i don't understand the above question..
15:50:51 <dgilmore> langdon: that changes do not break composition,
15:51:11 <geppetto> sct To look at it another way, what does the module author do when the dep. solving fails?
15:51:14 <langdon> dgilmore, it can still be automatic.. but at design time.. so that diffs are more apparent..
15:51:24 <dgilmore> langdon: not really
15:51:40 <geppetto> He basically has two options: 1) Force upstream/pkg to remove dep. 2) Do what automatic depsolving does, but manually.
15:51:41 <dgilmore> langdon: maintainers are not always aware of teh changes
15:52:01 <sct> There are other options
15:52:07 <langdon> dgilmore, i think that is the point .. we want to force them to see the impact of their changes..
15:52:09 <dgilmore> langdon: we can get diffs at build time
15:52:14 <sct> 3) make the dep a weak dep.
15:52:19 <dgilmore> and we have ways to make it visible
15:52:25 <sct> 4) Add the dep to a lower-level module.
15:52:59 <sct> The whole _point_ is to have something in the tools that help prevent bloat from being something that just gets accepted automatically
15:53:05 <geppetto> sct: Option #3 is option #1, but has more chance of actually happening
15:53:17 <dgilmore> sct: there are many ways to achive it
15:53:34 <sct> geppetto: Yes, it's an additional option we have now that makes this more achievable.
15:53:42 <tflink> FWIW, I don't think it'd be difficult to check for dependency change on module build
15:53:53 <sct> dgilmore: I think of this like a CI step ---
15:54:03 <dgilmore> tflink: it should not be difficult at all
15:54:16 <dgilmore> sct: so do I
15:54:27 <tflink> i don't know how the build/push process works, but that can require manual override if the deps change
15:54:29 <sct> if somebody commits a change that breaks an assumption somewhere, then an automated toolchain should not just say "it's more important to try to build, I'll just work around it and pull in something new"
15:54:51 <sct> it _should_ break, so we can consider if the change is intended and desirable or not
15:55:17 <dgilmore> sct: manually dealing with it breaks things and forces people to make a decision, automatically dealling with deps and presenting it then means people can accept or reject the change
15:55:29 <tflink> I'm not sure breakage is required to consider whether the change is intended/desirable
15:55:35 <dgilmore> if they reject it we need a way to easily allow them to do so before we push it out
15:55:38 <sct> tflink: Right, _checking_ should be done in any case.  Question is whether it should only report differences as information, or should fail the build if deps are incomplete.
15:55:44 <tflink> why can't it just be flagged for "needs manual override" post-build but pre-push
15:56:04 <lkocman> sct: it’s very easy to do filelist diffs and these could be approved by responsible person (e.g.)
15:56:11 <lkocman> sct: as you say the CI step with e.g. approval
15:56:24 <langdon> tflink, dgilmore if the modules are independent, what is the difference between failing the module build and "needs manual override"?
15:56:34 <langdon> like we don't want to start dependent rebuilds in either case
15:56:42 <dgilmore> sct: the probelm I think we face here is that there is never one right answer
15:56:43 <sct> Absolutely; if we can complete the build but mark it as failing a dependency test, that would work too
15:56:58 <sct> dgilmore: Right, and I'm definitely willing to see this configurable.
15:57:13 <contyk> note: we already have that and it's configurable
15:57:20 <tflink> langdon: one pretty much requires the author/maintainer and the other can be done by a responsible 3rd party
15:57:38 <nils> Same thing happens when an upstream adds a new build dependency, it won't build without manual intervention.
15:57:48 <tflink> but that's an arguable difference
15:58:21 <nils> well, s/same/similar/
15:58:27 <lkocman> sct: + configurable is what we have now
15:58:28 <dgilmore> nils: in the world sct is proposing that will end up causing all sorts of itteration manually
15:58:32 <nils> because modules aren't packages and whatnot
15:58:35 <dgilmore> nils: because they add the BR
15:58:50 <dgilmore> then they have to adjust something to say the new Requiires is okay
15:59:18 <tflink> it would make tracking dependency change over time easier, though - just look through git history instead of some 3rd system which tracks the manual overrides
15:59:28 <dgilmore> if we automatically pull in deps and alert and require sign off, the fix the rpm build, get an alert and verify that the changes are expected and sign off on it
16:00:02 <sct> dgilmore: Yes, that's the _whole point_! To get a manual interaction.
16:00:05 <langdon> dgilmore, i think this may be a distinction without a difference
16:00:24 <langdon> like.. we are resulting in the same "function".. just articulating it different;u
16:00:29 <langdon> *differently
16:00:53 <tflink> prefer different methods would be more accurate, I think
16:01:01 <dgilmore> langdon: yeah, I am arging for making it simpler on the developers
16:01:09 <tflink> but yeah, the end goal is pretty much the same
16:01:09 <langdon> dgilmore, i think sct and i just see a clearer distinction between "design time" and "build time" but in the same pipeline you are describing
16:02:13 <dgilmore> langdon: I guess I do not really, because there is really no difference, and the design changes as the distro evolves
16:02:18 <langdon> like neither sct nor i are suggesting depsolving is done without tools.. just that those tools cant (except in some specific conditions) depsolve->build automatically without intervention if the depsolve results in a new list of deps
16:02:26 <dgilmore> integrating means less manual clunkiness
16:02:34 <dgilmore> manual things people do badly
16:02:48 <sct> langdon: I also see dgilmore's point too, though --- if we fail a Base module build for this reason, and that blocks _anyone_ from accepting updates for _any_ base component until we've resolved some deep upstream disagreement, then we're getting in the way of a lot of developers.
16:02:52 <langdon> i just see that pipeline as being anitya->mirrors..
16:03:03 <langdon> sct, not really
16:03:04 <dgilmore> something I have hit way too many times in the 11 odd years I ahve been doing Fedora
16:03:08 <langdon> they can still use the old version
16:03:31 <sct> langdon: Exactly, so they can't get any new kernel, any new glibc, any new systemd... they can't get updates for any base component.
16:03:33 <langdon> because it doesn't block the "release" .. just the update to one module
16:03:41 <sct> Right.
16:03:52 <dgilmore> langdon: they may need the new thing in the base layer
16:03:54 <langdon> but it will be only 6months old, right?
16:03:59 <langdon> or less
16:04:13 <sct> dgilmore: ^^^ But does this allay your own concerns?  The distro still builds using the old module, composes don't break, we just don't get the module updated until the dep is resolved.
16:04:34 <dgilmore> sct: not really, because the build system does not work that way
16:04:34 <langdon> sct, right.. exactly
16:04:45 <langdon> dgilmore, after magic.. it will ;)
16:04:46 <dgilmore> we would need to redesign how we build
16:05:00 <sct> dgilmore: But the whole point here is to change how the builds work.  This is the whole point of an incremental modular build chain.
16:05:05 <sct> Yes.
16:05:06 <tflink> langdon: magic?
16:05:16 <dgilmore> sct: then we should start at that level
16:05:21 <sct> Absolutely magic.
16:05:27 <dgilmore> trying to bolt it in later will be a mess
16:05:27 <langdon> dgilmore, we have to do that anyway.. right? this is true for all modules.. they need to keep building on old module-dep versions until new ones are available..
16:05:37 <langdon> lkocman, is writing all that code, right now!
16:05:39 <langdon> :)
16:05:43 <dgilmore> langdon: not necessarily
16:05:54 <dgilmore> langdon: I have not seen him look at koji code
16:06:05 <langdon> ohhh.. oops.. we are over time
16:06:06 <dgilmore> or bodhi, or pkgdb
16:06:13 <langdon> sorry.. i wasn't paying attention
16:06:14 <sct> dgilmore: Yes --- the depsolving question here _only_ applies to modules being built specifically in a modular build chain where everything works on that assumption.
16:06:22 <langdon> can we table this to the other channel?
16:06:27 <langdon> do we have any decissions?
16:06:47 <dgilmore> langdon: sct: so we should step back a little and try figure out how that is all going to work
16:06:48 <langdon> aside from.. we haven't agreed? :)
16:06:51 <sct> dgilmore: I've nearly finished a document outlining the way a modular distro compose would work; it's turning out a lot longer than I expected so is taking a while
16:07:08 <langdon> ok.. sorry.. really gotta callit
16:07:15 <sct> OK, thanks then!
16:07:28 <langdon> #topic proposed "release" for flock
16:07:38 <sct> langdon: We can come back to this using that doc as a starting point, might help to have that in our hands before continuing this conversation
16:07:38 <langdon> #link https://fedoraproject.org/wiki/Modularity_Working_Group/releases/Flock_2016_Release
16:08:14 <langdon> #info very briefly ... see the link for some ideas about what we would like to "release" by flock... more discussion at next meeting or ML or on the wiki page
16:08:20 <langdon> sct, +1
16:08:39 <langdon> #topic open floor
16:08:43 <langdon> #info ok.. going to skip open floor
16:08:48 <dgilmore> ure
16:08:49 <dgilmore> sure
16:08:53 <langdon> any last things before i close the meeting?
16:09:07 <lkocman> langdon: run forrest run
16:09:12 <sct> I'm done
16:09:12 <langdon> going twice?
16:09:29 <langdon> sct, ha.. that sounds like "done for the day" "leave me alone" :)
16:09:33 <langdon> going thrice
16:09:35 <sct> :)
16:09:47 <langdon> ok.. l8r y'all
16:09:52 <langdon> #endmeeting