19:08:57 <jillr> #startmeeting ansible core irc public meeting
19:08:57 <zodbot> Meeting started Tue Feb 18 19:08:57 2020 UTC.
19:08:57 <zodbot> This meeting is logged and archived in a public location.
19:08:57 <zodbot> The chair is jillr. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:08:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:08:57 <zodbot> The meeting name has been set to 'ansible_core_irc_public_meeting'
19:09:02 <sdoran> o/
19:09:21 <jillr> looks like the agenda is clear
19:09:32 <zodbot> jillr: Error: Can't start another meeting, one is in progress.
19:09:39 <jillr> erm  :)
19:09:41 <jillr> #topic open floor
19:10:00 * sdoran dances
19:11:58 <cyberpear> What will the standard be for collections to be included in ACD?
19:12:35 <cyberpear> And what will be the mechanism?
19:12:55 <cyberpear> git submodules?
19:13:50 <sdoran> I don't think it will be submodules. It will be a build artifact, not an single repository of repsitories.
19:15:04 <sdoran> As far as criteria for inclusion, I'm not sure that has been enumerated.
19:15:37 <sdoran> Or how long ACD will be a thing.
19:15:58 <jillr> my understanding has been generally something along the lines of whatever ships today
19:16:03 <sdoran> It's evolving.
19:16:52 <sdoran> It's meant to be a short term solution to ease the transition to collections.
19:17:59 <sdoran> Ideally, the shift to using collections will happen naturally since modules in collections will have updates that will be release faster than ACD.
19:18:31 <sdoran> s/release/released
19:19:10 <cyberpear> I fear folks will be forced into something akin to RPython, with missing useful modules like ini_file... especially if the collections don't end up packaged as RPMs
19:20:25 <sdoran> There are a lot of concerns. Change is not easy.
19:20:27 <cyberpear> (Which is why ACD is critical to have, given kicking out the community modules)
19:22:32 <cyberpear> Hopefully we can answer these questions before releasing a 2.10 without community modules
19:23:38 <sdoran> Is your primary concern being able to have the modules distributed in an rpm?
19:24:39 <cyberpear> I'm concerned about fragmentation, and having my roles work everywhere even offline networks
19:25:39 <cyberpear> Ideally, I'd like to see a process of getting a module added to core, such as supporting diff_mode, check_mode, and having unit and integration tests for all of the module's features.
19:26:22 <jillr> there will be ways to get collections into offline networks, that's going to be a common scenario
19:29:04 <cyberpear> Just don't want to force lots of extra steps, and RPMs are well understood, with virtualenv's being possible but less desirable
19:29:28 <sdoran> How do you distribute roles today?
19:29:48 <sdoran> Collections aren't much different. A folder full of folders and files.
19:32:05 <cyberpear> git or RPMs, depending on the stage
19:34:25 <sdoran> I understand your concern, but don't think distributing collections will be that much more difficult that roles.
19:34:29 <sdoran> That's the goal, anyway.
19:34:57 <sdoran> I want to look at making installation from a requirements file with both roles and collections work in one go.
19:35:14 <sdoran> It's a bit fragmented today, though you can have a single requirements file.
19:35:34 <sdoran> I imagine it will be much harder to solve than I think, like most things in software. :)
19:35:54 <cyberpear> Doesn't work with git now, either...
19:37:33 <agaffney> cyberpear: it's trivial to create custom RPMs with extra stuff with a tool like FPM
19:38:58 <sdoran> Hmmm, I bet there is a good reason for that. Collections seem to be very artifact-based.
19:39:11 <sdoran> Would be nice to be able to install from a git repo, though.
19:44:38 <jillr> There's going to be an adjustment period to work all those things out, so we have ACD for that transitionary period.
19:44:59 <jillr> Anything else for today?
19:47:25 <jillr> ok, thanks folks for dropping by  o/
19:47:29 <jillr> #endmeeting