15:00:47 #startmeeting modularity_wg 15:00:47 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:47 The meeting name has been set to 'modularity_wg' 15:00:52 .hello psabata 15:00:53 contyk: psabata 'Petr Šabata' 15:01:02 .hello langdon 15:01:03 langdon: langdon 'Langdon White' 15:01:04 .hello sct 15:01:07 sct: sct 'Stephen Tweedie' 15:01:12 #Chair dgilmore, cydrobolt, harald, jkurik, langdon, mikedep333, sct, tflink 15:01:13 Current chairs: cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink 15:01:32 .hello jkurik 15:01:33 jkurik: jkurik 'Jan Kurik' 15:01:40 hola amigos 15:01:42 .hello tflink 15:01:44 yo! 15:01:44 tflink: tflink 'Tim Flink' 15:01:55 .hello lkocman 15:01:55 jkurik, i just added you to the agenda.. for a scheduling update.. you cool with that? 15:01:56 lkocman: lkocman 'None' 15:02:06 .hello jkaluza 15:02:07 jkaluza: jkaluza 'Jan Kaluža' 15:02:15 .hello james 15:02:16 geppetto: james 'James Antill' 15:02:17 lkocman: cool name 15:02:31 contyk: I wanted to trick the system 15:02:42 .hello cpacheco 15:02:45 cpacheco: cpacheco 'Courtney Pacheco' 15:02:53 lkocman: try drop table next time 15:03:10 .hello nphilipp 15:03:10 nils: nphilipp 'Nils Philippsen' 15:03:17 #topic roll call ^^ 15:03:28 #topic proposed agenda 15:03:50 #info scheduling update from jkurik 15:03:51 #info idea for faq 15:03:51 #info demos 15:03:51 #info module depsolving automation [sct] 15:03:51 #info proposed "release" for flock 15:03:52 #info open floor 15:03:58 anything to add anyone? 15:04:18 (listening/watching) 15:04:33 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 make sure you look for june-2 though.. as june-9 is already getting populated :) 15:05:23 #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 ok.. moving on 15:05:39 #topic scheduling update from jkurik 15:05:46 jkurik, you have any updates? 15:06:24 ok, so from the "whenisgood" the winner is Tuesday - 11:00 AM 15:06:32 timezone? 15:06:46 there were only 3 people, who can not join (I was one of them, but I can adapt) 15:07:04 #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UTOCPHITXCRM7JH2ZH7OVIDVWWQULIMI/ 15:07:14 jkurik, im guess eastern cause that was what whenisgood defaulted too 15:07:15 tflink: Timezone: US/Eastern 15:07:36 so same time as today, only on Tuesdays 15:07:42 nils, righto.. 15:07:47 * langdon speaks from eastern ;) 15:07:53 today 15:07:54 that conflicts with #fedora-arm meeting :-( 15:07:56 Hmm --- since that whenisgood, we've scheduled a biweekly grooming meeting at that time 15:08:10 sct, i think we could just swap it 15:08:21 langdon: That's the smaller meeting with you and me, though, it might be the easier one to switch 15:08:21 yep 15:08:49 who where the people that could not make it? 15:08:50 is that starting next week? 15:08:52 ok.. so.. +1s for (argghh.. thinking utc.. /me digs) 15:09:18 langdon: we work in UTC :) 15:09:19 so.. 15h UTC on Tues 15:09:19 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 +1 from me 15:09:37 thats what i was trying to do :) .. but couldn't remember the conversion 15:09:41 tflink: that will go next 15:10:03 +1 15:10:08 jkurik, should i do something "special" to indicate a vote? 15:10:26 proposed #agreed Change weekly meeting time to .... ? 15:10:52 langdon: no 15:11:20 proposed #agreed Change weekly meeting time to 15h UTC on tuesdays 15:11:27 dgilmore: sct (due to the meeting with langdon I guess) and Vera ... and me 15:11:28 +1 15:11:31 #info proposed #agreed Change weekly meeting time to 15h UTC on tuesdays 15:11:53 I am +1 as well 15:11:54 ack/+1 15:11:59 +1 15:12:04 +1 15:12:20 #chair 15:12:20 Current chairs: cydrobolt dgilmore harald jkurik langdon mikedep333 sct tflink 15:12:42 any other voting members here? haraldh 15:12:50 so, we have sct, langdon, dgilmore, tflink, nils, jkurik as +1 15:13:00 cydrobolt, mikedep333 ? 15:13:06 that is 6 people 15:13:12 jkurik: I'm not a voting member FTR 15:13:14 FYI: http://paste.fedoraproject.org/373777/64880370/ 15:13:24 nils: ah, so we have 5 people as +1 15:13:31 geppetto, ha.. thanks! 15:13:49 jkurik, yeah.. im just worried that the same people who can't be here now can't be here then 15:13:50 One without color codes: http://paste.fedoraproject.org/373778/88041314/ 15:13:50 +1 15:14:08 but.. let's call it agreed.. and send it to the ML.. and hope? 15:14:25 langdon: unfortunatelly there is no a time slot which fits to all 15:14:34 jkurik, yeah.. i know 15:14:35 uhm, does the meeting stay on UTC, go with East Coast DST rules, ....? 15:14:37 ok.. done 15:14:42 ok, so ... 15:14:45 nils, stays utc 15:14:52 #agreed Change weekly meeting time to 15h UTC on tuesdays 15:15:16 jkurik, can you announce it? and change the mtg time in fedocal? 15:15:45 langdon: I do not have the permission to maintain the fedocal I guess... 15:15:51 langdon: let me check... 15:16:03 jkurik, ahh ok.. ill fix it while in the meeting.. 15:16:09 other people just need to talk a lot 15:16:14 ok.. lets move on.. 15:16:22 #action langdon to fix fedocal 15:16:26 langdon: one more think ... 15:16:33 #action jkurik to announce new meeting time to ml 15:16:37 do we start from the next week ? 15:16:38 jkurik, shoot 15:16:53 i would think, yes.. agree? 15:16:57 ack 15:17:14 * langdon mutters should have put that in the original proposal 15:17:24 any other opinions? -1s ? 15:17:43 ok 15:17:52 is there a majority case for whether fedora meetings stay UTC or move with US DTC? 15:18:00 ie, which is more common? 15:18:07 all the others i know of follow utc.. 15:18:29 I've only ever seen UTC 15:18:31 qa and docs follow us DTC for some reason 15:18:47 "because we've always done it that way" IIRC 15:18:51 im pretty sure council follows utc.. 15:18:57 but i may be misremembering 15:19:02 Fedocal shows you the timezone you have in your settings 15:19:07 lets just say follow utc and fix it later if nec. 15:19:15 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 #agreed time change for the meeting starts next week (making next meeting June 7 15h UTC), the meeting will follow utc 15:19:31 sure, just wondering which was more common, dtc/summer time is always a mess :-/ 15:19:39 jkurik, ok.. you are doing fedocal? 15:20:05 tflink, http://www.standardtime.com/ 15:20:08 ok.. 15:20:09 langdon: if you give me the permission to change the meeting I will do it 15:20:12 next topic i think 15:20:22 jkurik, will do .. if i can figure out how :) 15:20:33 #topic idea for faq 15:20:33 langdon: if it were up to me, DST and all its ilk would die in a fire :) 15:20:42 tflink++ 15:20:42 yselkowitz: Karma for tflink changed to 8 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any 15:20:44 tflink, +1 15:20:49 #link https://fedoraproject.org/wiki/Modularity_Working_Group/releases/Flock_2016_Release 15:20:52 oops 15:20:55 wrong link 15:20:57 #undo 15:20:57 Removing item from minutes: 15:21:28 #link https://ask.fedoraproject.org/en/question/88488/faq-for-modularity/ 15:21:53 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 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 but jwb does not appear to be here to bring it up 15:23:00 any opinions? 15:23:17 I have never used ask 15:23:17 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 dgilmore: +1 15:23:45 i've never used it much, either 15:23:54 kinda like stackoverflow.. if there are categories.. it can be a better way to track questions 15:23:57 I am not sure we have any great place for the info 15:25:28 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 wfm 15:26:01 ask has been heavily targeted by spammers 15:26:01 ok.. if i can type.. next topic 15:26:13 but so has trac and other pieces of Fedora 15:26:14 dgilmore, i actually get good info there pretty regularly 15:26:41 #topic demos 15:27:03 hoooray! 15:27:12 so.. i know there are some concerns about the demo content.. like stylistically.. so.. 15:27:33 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 and.. hopefully they will get better over time 15:27:55 but.. for now: 15:28:02 wall of text coming up 15:28:23 #link https://www.youtube.com/playlist?list=PLcwHJG45BmANqgU_Q0fZoCwqFOwE7vaUl < youtube playlist 15:28:45 #info following links are the direct links to fp.o/modularity hosted demos 15:28:51 langdon: my demo is missing 15:28:57 #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-contyk-guidelines.ogv 15:28:57 #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-cpacheco-rawhide-docker-minimization.avi 15:28:57 #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-jkaluza-fm-deps.ogv 15:28:57 #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-jstanek-pungi-pdc.webm 15:28:57 #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-karsten-pungi-pdc-install-and-usage.mkv 15:29:00 #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-lkocman-pdc-trees.mp4 15:29:02 #link https://fedorapeople.org/groups/modularity/sprint-6-demo/sprint6demo-nils-pdc-pungi-compose-docs.ogv 15:29:05 lkocman, BY DESIGN! 15:29:06 lkocman: i tried uploading your video and apparently it's a duplicate? 15:29:07 kidding 15:29:26 youtube deleted it 15:29:27 langdon: people are skipping me on purpose :-) (youtube channel only) 15:29:36 lkocman, bwhahahaha 15:29:48 cpacheco: perhaps they couldn’t handle all the new features 15:30:01 lkocman, ok.. maybe you can cpacheco can try to sort it offline? and let us know here when it is fixed? 15:30:04 sure 15:30:08 lkocman, im sure that is it! 15:30:18 any other comments/concerns on demos? 15:31:16 ok.. moving on then 15:31:25 #topic module depsolving automation [sct] 15:31:35 sct, takae it away... 15:31:41 *take even 15:31:48 OK, so this came up in discussion w/ lkocman: 15:31:54 * lkocman listens 15:32:02 * lkocman reads 15:32:13 There's a principle I'd like to see applied when we build modules, that is somewhat contrary to traditional composes. 15:32:26 Dependency resolution: 15:32:36 #chair lkocman sct 15:32:36 Current chairs: cydrobolt dgilmore harald jkurik langdon lkocman mikedep333 sct tflink 15:32:39 I really do *not* want a module build to pull in dependencies automatically 15:32:45 because 15:32:53 if a module doesn't have all that it needs to pass repoclosure, 15:33:04 then it should be a human decision to decide where the missing packages need to go 15:33:20 or whether in fact the dependency should be trimmed, eg. by subpackaging or adding weak dependencies. 15:33:31 It's especially important to combat dependency sprawl over time --- 15:33:47 if all new dependencies just get added automatically, we lose the ability to detect that sprawl and attempt to combat it. 15:33:50 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 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 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 them 15:34:37 and the module build just happens from a static manifest of packages for the module. 15:34:47 Right 15:34:58 sct: as far as modules goes … this is acceptable and makes sense. Since I’m dealing with traveling packages for years 15:34:58 and dgilmore: we thought you might have a perspective on this too; 15:35:18 sct: as far as non-module variants goes … (Everything) depsolving is very much wanted 15:35:29 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 right 15:35:38 lkocman, what do you mean by "non module variants"? 15:35:56 langdon: == traditional edition composes, I think 15:36:02 langdon: E.g. variant named Everything 15:36:02 ohh ok 15:36:18 langdon: +1 15:36:48 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 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 sct: I suspect there are many cases where we will have to use dep solving 15:37:03 langdon: I treat modules as variant type=module ... 15:37:06 sct, +1 15:37:15 dgilmore: I expect so, but I'm trying to get a picture of what those cases are 15:37:16 langdon: which is just transformation of what you’ve said 15:37:20 lkocman, right.. i want "all the things" to be modules.. 15:37:30 langdon: +1 can be 15:37:37 langdon: over time 15:37:45 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 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 langdon: keep in mind that Everything module as it is now is not achievable from rpm point of view 15:38:26 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 sct: yes, and I do not see modules as fixing that in any way shape or form 15:38:40 langdon: if you build one package with different features … you can’t have them all in single repo 15:38:42 lkocman, i would like to discuss that.. but it is orthogonal to this convo.. so let's wait 15:38:46 yup 15:38:50 sct: the issue is that eveyone makes a decision based on isolation 15:38:52 * lkocman writes note 15:39:05 sct: foo adds a dep on bar, its small and useful 15:39:17 but when you add all the foos and bars it becomes huge 15:39:28 dgilmore, but in module-land.. no one else can use bar unless they actually add it themselves 15:39:39 dgilmore: Right. And a static manifest for modules lets us detect the net impact of that small addition 15:39:40 if anything modules developed in isolation will make the big picture harder to see 15:40:07 Well, another part of the modularity plan is to be able to rebuild related modules when a dependency changes 15:40:09 sct: no it does not 15:40:13 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 so if there's a net impact on some other area, then yes, the tools *would* be able to highlight that. 15:40:39 sct: static manifest isn’t tracking buildroot changes 15:40:48 sct: otherwise +1 15:41:03 sct: its not one change in isolation though. its many small changes over time that make things creep 15:41:13 dgilmore: It's not a panacea, absolutely, but I do think it's useful. 15:42:10 well.. it does help a lot.. right.. because it is the "module's problem" not "fedora's problem" 15:42:14 ? 15:42:57 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 langdon: not as I see it 15:43:12 then this absolutely gives us notice at the right place and time to prevent that dependency from being automatically included 15:43:25 it may help in cases where other modules pull in unexpected things 15:43:42 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 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 sct: it may be that the base/core/ring (0-1) bits we manually deal with deps 15:44:38 and the outliers we just do dep solving 15:44:57 KDE is likely going to want whatever is pulle din 15:45:07 XFCE and gnome the same 15:45:08 dgilmore: Yes, I'd expect that outliers would be much less inclined to spend a lot of effort on this. 15:45:24 but core parts we may want better control 15:45:52 sct: I do then wonder how we will deal with things like systemd adding a dep on microhttpd 15:46:06 just to be clear.. depsolving is still done.. but it is part of the "module design" step .. vs the "build step"... 15:46:08 in the past thats a change forced on us that was not desired by many 15:46:19 in the end we had no choice 15:46:40 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 but in a module world how will we resolve the conflicts between upstream forcing changes and module owners not wanting it 15:47:16 That's not a new problem. :) 15:47:22 dgilmore: langdon sct: can we track some agreement here? At least as far as tooling features and default behavior goes? 15:47:38 its not a new problem, just becomes a different argument 15:47:39 dgilmore: it could change over time if we see it’s not doable 15:47:53 dgilmore: One thing that might help there, though, is better statement of high-priority requirements --- 15:47:53 lkocman: nothing is set in stone 15:47:59 dgilmore: +1 15:48:02 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 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 geppetto: I know. And there's no magic bullet. 15:48:43 it may effect our ability to produce anything if there is a conflict low down 15:49:00 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 sct: I am pretty firmly in favour of having deps be resolved automatically 15:49:19 with notifications over changes 15:49:32 but I am open to having the core pieces being manual 15:49:53 dgilmore, what is the difference between doing the depsolving at design time vs build time? 15:50:02 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 and I think depsolving should be off for most of those. 15:50:26 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 But for larger ones like gnome or anaconda, yes, it should be on. 15:50:39 sct, why? 15:50:47 like i don't understand the above question.. 15:50:51 langdon: that changes do not break composition, 15:51:11 sct To look at it another way, what does the module author do when the dep. solving fails? 15:51:14 dgilmore, it can still be automatic.. but at design time.. so that diffs are more apparent.. 15:51:24 langdon: not really 15:51:40 He basically has two options: 1) Force upstream/pkg to remove dep. 2) Do what automatic depsolving does, but manually. 15:51:41 langdon: maintainers are not always aware of teh changes 15:52:01 There are other options 15:52:07 dgilmore, i think that is the point .. we want to force them to see the impact of their changes.. 15:52:09 langdon: we can get diffs at build time 15:52:14 3) make the dep a weak dep. 15:52:19 and we have ways to make it visible 15:52:25 4) Add the dep to a lower-level module. 15:52:59 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 sct: Option #3 is option #1, but has more chance of actually happening 15:53:17 sct: there are many ways to achive it 15:53:34 geppetto: Yes, it's an additional option we have now that makes this more achievable. 15:53:42 FWIW, I don't think it'd be difficult to check for dependency change on module build 15:53:53 dgilmore: I think of this like a CI step --- 15:54:03 tflink: it should not be difficult at all 15:54:16 sct: so do I 15:54:27 i don't know how the build/push process works, but that can require manual override if the deps change 15:54:29 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 it _should_ break, so we can consider if the change is intended and desirable or not 15:55:17 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 I'm not sure breakage is required to consider whether the change is intended/desirable 15:55:35 if they reject it we need a way to easily allow them to do so before we push it out 15:55:38 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 why can't it just be flagged for "needs manual override" post-build but pre-push 15:56:04 sct: it’s very easy to do filelist diffs and these could be approved by responsible person (e.g.) 15:56:11 sct: as you say the CI step with e.g. approval 15:56:24 tflink, dgilmore if the modules are independent, what is the difference between failing the module build and "needs manual override"? 15:56:34 like we don't want to start dependent rebuilds in either case 15:56:42 sct: the probelm I think we face here is that there is never one right answer 15:56:43 Absolutely; if we can complete the build but mark it as failing a dependency test, that would work too 15:56:58 dgilmore: Right, and I'm definitely willing to see this configurable. 15:57:13 note: we already have that and it's configurable 15:57:20 langdon: one pretty much requires the author/maintainer and the other can be done by a responsible 3rd party 15:57:38 Same thing happens when an upstream adds a new build dependency, it won't build without manual intervention. 15:57:48 but that's an arguable difference 15:58:21 well, s/same/similar/ 15:58:27 sct: + configurable is what we have now 15:58:28 nils: in the world sct is proposing that will end up causing all sorts of itteration manually 15:58:32 because modules aren't packages and whatnot 15:58:35 nils: because they add the BR 15:58:50 then they have to adjust something to say the new Requiires is okay 15:59:18 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 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 dgilmore: Yes, that's the _whole point_! To get a manual interaction. 16:00:05 dgilmore, i think this may be a distinction without a difference 16:00:24 like.. we are resulting in the same "function".. just articulating it different;u 16:00:29 *differently 16:00:53 prefer different methods would be more accurate, I think 16:01:01 langdon: yeah, I am arging for making it simpler on the developers 16:01:09 but yeah, the end goal is pretty much the same 16:01:09 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 langdon: I guess I do not really, because there is really no difference, and the design changes as the distro evolves 16:02:18 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 integrating means less manual clunkiness 16:02:34 manual things people do badly 16:02:48 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 i just see that pipeline as being anitya->mirrors.. 16:03:03 sct, not really 16:03:04 something I have hit way too many times in the 11 odd years I ahve been doing Fedora 16:03:08 they can still use the old version 16:03:31 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 because it doesn't block the "release" .. just the update to one module 16:03:41 Right. 16:03:52 langdon: they may need the new thing in the base layer 16:03:54 but it will be only 6months old, right? 16:03:59 or less 16:04:13 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 sct: not really, because the build system does not work that way 16:04:34 sct, right.. exactly 16:04:45 dgilmore, after magic.. it will ;) 16:04:46 we would need to redesign how we build 16:05:00 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 Yes. 16:05:06 langdon: magic? 16:05:16 sct: then we should start at that level 16:05:21 Absolutely magic. 16:05:27 trying to bolt it in later will be a mess 16:05:27 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 lkocman, is writing all that code, right now! 16:05:39 :) 16:05:43 langdon: not necessarily 16:05:54 langdon: I have not seen him look at koji code 16:06:05 ohhh.. oops.. we are over time 16:06:06 or bodhi, or pkgdb 16:06:13 sorry.. i wasn't paying attention 16:06:14 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