18:00:09 <felixfontein> #startmeeting Ansible Community Meeting
18:00:09 <zodbot> Meeting started Wed Dec 15 18:00:09 2021 UTC.
18:00:09 <zodbot> This meeting is logged and archived in a public location.
18:00:09 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:09 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:09 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:09 <felixfontein> acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:00:14 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:19 <briantist> o/
18:00:21 <andersson007_> o/
18:00:21 <dmsimard> o/
18:00:23 <jillr> o/
18:00:24 <tadeboro> o/
18:00:44 <cybette> o/
18:01:01 <acozine> sorry, folks, I'm out today - outage triage
18:01:07 <felixfontein> #chair briantist andersson007_ dmsimard jillr tadeboro cybette acozine
18:01:07 <zodbot> Current chairs: acozine andersson007_ briantist cybette dmsimard felixfontein jillr tadeboro
18:01:39 <acozine> #unchair acozine
18:01:39 <zodbot> Current chairs: andersson007_ briantist cybette dmsimard felixfontein jillr tadeboro
18:01:41 <cyberpear> o/
18:01:46 <felixfontein> acozine: good luck!
18:01:47 <dmsimard> #topic updates
18:01:49 <felixfontein> #chair cyberpear
18:01:49 <zodbot> Current chairs: andersson007_ briantist cyberpear cybette dmsimard felixfontein jillr tadeboro
18:01:52 <acozine> thanks!
18:02:14 <dmsimard> #info ansible 4.10.0 has been released: https://groups.google.com/g/ansible-announce/c/BJxz60-mq7w -- it's the last 4.x maintenance release now that ansible 5.x is out. There's instructions included in the announcement for getting collection updates from Ansible 5 for users that wish to stay on ansible-core 2.11.x.
18:02:31 * dericcrago waves
18:02:35 <samccann> o/
18:03:41 <andersson007_> acozine cyberpear zbr could you please vote https://github.com/ansible-community/community-topics/issues/51#issuecomment-989600473 when you have time
18:03:50 <felixfontein> #chair samccann
18:03:50 <zodbot> Current chairs: andersson007_ briantist cyberpear cybette dmsimard felixfontein jillr samccann tadeboro
18:04:06 * felixfontein just finished cooking dinner
18:04:17 <dmsimard> #info We are still interested in running a monthly virtual community meetup to fill in the gap between contributor summits and ansiblefests. We should be able to confirm a first agenda soon in expectation of a first meetup around January 18th.
18:04:38 <randall> o/
18:04:47 <felixfontein> #chair randall
18:04:47 <zodbot> Current chairs: andersson007_ briantist cyberpear cybette dmsimard felixfontein jillr randall samccann tadeboro
18:05:17 <felixfontein> I'm looking forward to that
18:06:25 <cybette> #chair deric.crago
18:06:25 <zodbot> Current chairs: andersson007_ briantist cyberpear cybette deric.crago dmsimard felixfontein jillr randall samccann tadeboro
18:06:52 <dmsimard> #info A first iteration of the Ansible 5 packaging for Fedora 36 should be landing sooner rather than later, if you'd like to check it out or provide feedback it's up at https://src.fedoraproject.org/rpms/ansible/pull-request/19
18:07:02 <dmsimard> That's all from me
18:07:37 <felixfontein> cool!
18:07:47 <felixfontein> if nobody has another update, let's start with topics!
18:07:48 <felixfontein> #topic Repository instead of Changes impacting collection contributors & maintainers Issue
18:07:52 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/51
18:08:03 <felixfontein> not sure whether there's something to discuss, I just wanted to point to that this one is running pretty async now :)
18:08:14 <felixfontein> (and almost all steering committee members voted by now)
18:08:26 <andersson007_> voting options https://github.com/ansible-community/community-topics/issues/51#issuecomment-989600473
18:08:59 <dmsimard> I like the idea and it would work similar to the previous issue if people subscribe (watch) the repository so they get notifications
18:09:18 * gundalow waves
18:09:19 <felixfontein> dmsimard: there are multiple ideas :)
18:09:21 <felixfontein> #chair gundalow
18:09:21 <zodbot> Current chairs: andersson007_ briantist cyberpear cybette deric.crago dmsimard felixfontein gundalow jillr randall samccann tadeboro
18:09:38 <dmsimard> felixfontein: I know but at a high level, moving from an issue to a repo, I mean
18:09:51 <felixfontein> does anyone wants to discuss this in this meeting (since we already did that more than once I think ,and there's the async discussion)?
18:10:21 <andersson007_> yeah, in addition it should be more convenient for folks who actively work with the issue
18:10:29 <andersson007_> plus we could use labels, etc.
18:10:54 <felixfontein> indeed
18:11:36 <andersson007_> do we have enough votes now to see if it's approved / disapproved ?
18:11:42 <briantist> I'm all good with the dedicated repo with individual issues
18:12:49 <felixfontein> I haven't counted, but it seems to me that 1a and 2a seem to have the most votes. I don't know if there are enough +1s on these two though
18:14:13 <andersson007_> if i count correctly, there are 3 for 1a 2a, 4 for +0 and 3 committee members haven't voted
18:14:54 <felixfontein> hmm from the steering comittee side we have 3 x + 1, 4 x 0, 1 x -1 for 1a/2a
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:33 <felixfontein> I think only two members didn't vote (acozine and zbr)
18:16:21 <andersson007_> true
18:18:42 <andersson007_> Do we have a kind of quorum? if there's no clear winner, we could wait.
18:19:16 <felixfontein> TBH I'm not sure what the exact rules are when there are so many 0's around
18:19:44 <tadeboro> As far as I can tell, we still need one more +1 or 0 to be able to say that the result will not change.
18:19:47 <dmsimard> need to flip some of those 0's
18:19:54 <gundalow> Wonder if it's worth announcing the proposal on the existing "changes impacting contributors", readers on that issue are the ones that will be impacted the most.
18:20:21 <jillr> gundalow: +1
18:20:28 <samccann> i've always interpreted '0' to 'have no opinion'
18:20:43 <felixfontein> btw, did someone count (or estimate) how much of the announcements actually would make sense as PRs?
18:20:50 <cybette> gundalow: +1
18:21:36 <felixfontein> gundalow: +1
18:21:58 <briantist> samccann: same re: `0` votes; I would think a `-1` on the proposal is a vote for keeping the same
18:22:12 <briantist> gundalow: +1
18:22:20 <tadeboro> felixfontein: I did think about this a bit and got to the conclusion that PRs would add just enough overhead to make them pain in the butt to write compared to opening an issue.
18:22:54 <tadeboro> I would love to see things tracked as files in the repo, but I have a feeling that we are not there yet as far as maturity of community goes.
18:23:16 <briantist> felixfontein: I'm not sure how much it was evaluated, but I would vote `-1` on PRs personally. It just seems like too much for too little imo..
18:24:15 <gundalow> I personally see PRs are being for things where a permanent record is needed, ie change in rules, accepted proposals.
18:24:16 <felixfontein> tadeboro: how many of these announcements do you think are good to know later on? I think most like "ansible-test now validates xxx" are only of interest to maintainers at that moment, but not to other maintainers in the future (since their collection already had to adjust to that change)
18:24:42 <gundalow> Issues are good for things that can be resolved (remove testing of this old OS on devel)
18:25:04 <felixfontein> gundalow: what kind of rules/proposals are you thinking of? if this is about collection inclusion rules, these are already tracked in its own repo
18:26:01 <tadeboro> felixfontein: I like the file approach because things read like a yournal. But I will be the first one to admit that I am probably one of the rare people whol actually likes documenting things ;)
18:26:50 <gundalow> felixfontein: that's my point. I don't think any of this suites files or PRs
18:26:56 <felixfontein> tadeboro: I totally see why this is useful, but I'm still not sure what actually needs to be documented. for example, that ansible-test started validating X on date Y is already recorded in the changelog of ansible-core
18:27:53 <gundalow> So, as the original author of "changes impacting contributors" its purpose was to notify people to do something.
18:28:04 <tadeboro> felixfontein: Well, I must admit I never read the ansible-core changelog that carefully and relied on people telling me what do to in the issue ;)
18:28:28 <gundalow> Ie
18:28:28 <gundalow> * Update CI as we've branched ansible-core
18:28:28 <gundalow> * sign-up for contributors Summit
18:28:56 <tadeboro> felixfontein: But I imagine that changes impacting repo would contain more focused version of changelog targeted at content developer.
18:29:13 <tadeboro> But as I already voted: I think this would be an overkill for now.
18:29:33 <gundalow> It was meant to be a simple process for readers and people announcing action (news)
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:19 <gundalow> And whatever we end up needs to still be simple for those two sets of people. It's difficult enough to get people to pay attention, let alone take action
18:30:56 <briantist> I would like to keep this simplicity. It has worked well in my opinion
18:31:03 <andersson007_> +1
18:31:07 <briantist> we can alays re-evaluate something more complex that might have other benefits
18:31:16 <dmsimard> briantist: simplicity is a feature :)
18:31:16 <felixfontein> indeed. it would be a lot easier if GH issues with many comments were easier to handle :)
18:31:25 <gundalow> Maybe we need to just move out the actions where they only apply to a know specific set of repos to a different place. And keep the rest in the existing issue.
18:31:44 <tadeboro> Yep, we should start simple and complicate our lives later on ;)
18:32:03 <felixfontein> gundalow: there's still too much leftovers that GH's issue UI makes life hard
18:32:19 <felixfontein> except if we start a new issue regularly, like every 6 (or 12?) months
18:32:25 <briantist> I'm ok with moving completely to separate issues, because of what felixfontein just mentioned, and because the notification preferences are still easy
18:33:00 <briantist> you can make the notifications more fine-grained with individual issues if you want that, but if you don't, you still get notified for everything, so it's simple & comparable by default
18:33:29 <briantist> (I'm making assumptions that those subscribed to the issue now, will subscribe to the repo as a first/maybe only step)
18:33:37 <felixfontein> and by using the issue search feature you can still search
18:33:53 <briantist> search in a way that's actually effective even
18:34:04 <felixfontein> compared to right now, definitely!
18:34:38 <briantist> I wasted a lot of time trying to find those hidden comments, and as I mentioned, direct permalinks to them don't even work right so I couldn't even bookmark them really
18:34:51 <andersson007_> same for me
18:35:06 <felixfontein> same here
18:35:39 <felixfontein> that hiding feature already gets annoying in some PRs, but in that issue (but also in https://github.com/ansible/community/issues/539) it's just painful
18:35:58 <felixfontein> ok
18:36:24 <felixfontein> how about adding some more comments to that issue and mentioning it in the "Changes impacting collection contributors & maintainers" issue?
18:36:48 <gundalow> Yup, let's get different peoples views
18:36:57 <briantist> sure that makes sense
18:37:06 <felixfontein> andersson007_: since you started the topic, can you do that?
18:37:24 <andersson007_> felixfontein: i've already put it in my TODO
18:37:45 <gundalow> Also, controversial warning
18:37:45 <gundalow> The Bullhorn has been created since this started, do we still need the issue at all?
18:37:48 <felixfontein> cool, thanks!
18:38:07 <felixfontein> gundalow: I think we need it, since bullhorn usually is too late for quite a few of the announcements in there
18:38:20 <briantist> felixfontein: +1
18:38:23 <andersson007_> felixfontein: the community is always welcome:)
18:38:31 <felixfontein> if a new stable branch has been created, the version bumped in devel, or a new test added to devel, maintainers need to know right away, and not in < 3 weeks
18:38:51 <gundalow> Bullhorn may become weekly soon
18:39:00 <briantist> still not soon enough imo
18:39:03 <felixfontein> it's still up to 7 days too late then :)
18:39:06 <tadeboro> And I hope we can get more feedback on the changes if we stop dealing with one giant issue ;)
18:39:12 <gundalow> (just throwing some different options out)
18:39:23 <briantist> yup it's a good question to ask
18:39:23 <jillr> yeah faster (even that weekly) updates are valuable for the things that tend to go in that issue
18:39:44 <tadeboro> gundalow: Well, my CI will die in a day after devel is updated, so newsletter is too slow usually.
18:40:17 <briantist> if even a day; depending on PRs and scheduled runs
18:40:33 <cybette> I also think some announcements are too time critical to wait for next bullhorn
18:41:04 <felixfontein> coordinating early versions of the bullhorn with some announcements *could* also be done, but I think it would make everyone's life just more complicated for little gain
18:41:16 <cybette> plus bullhorn covers other news items, so critical stuff for maintainers may get lost in there
18:41:35 <felixfontein> true
18:41:49 <andersson007_> can there be "special" / "hot news" bullhorn releases?
18:42:05 <andersson007_> (just brainstorming)
18:42:10 <briantist> certain (few imo) issues could be appropriate in the bullhorn, but should probably be case by case
18:42:51 <briantist> I don't think we need those (and it seems like it would add to cybette 's work at a time when we're trying to reduce it),  but I'm not opposed if that's what the community wants
18:42:53 <dmsimard> There's some experimentation around more of a blog-like format, there could be standalone posts inbetween issues if appropriate ¯\_(ツ)_/¯
18:43:33 <felixfontein> usually blog posts also take longer than a simple small announcement in form of an issue, or issue comment :)
18:43:58 <felixfontein> ok, should we look at another topic?
18:44:44 <felixfontein> #topic Establishing the roadmap for Ansible 6.0.0
18:44:44 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/56
18:44:50 <dmsimard> there's the ansible 6 roadmap topic, no need to discuss now (there's no hurry) but having some eyes on it would be good, I will try to come up with tentative dates for the different milestones so we can formalize/vote on it after the holidays
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:23 <cybette> I do go through #45 to see if there are newsworthy items, but I don't want to be the bus factor either. so issues/repo is probably better for a maintainer's workflow
18:45:25 <dmsimard> If there's something you would like to see happen within the ansible 6 timeframe, it could be good to mention it as we're trying to plan what we'd like to do
18:45:27 <felixfontein> I was just about to suggest that someone (tm) should prepare a list of dates, so we can vote on that :)
18:45:39 <felixfontein> (I can also create that list if nobody else does)
18:46:28 <dmsimard> I'll get around to it if nobody tries first :p
18:46:55 <felixfontein> running sanity and unit tests sounds like a good idea. I wouldn't run integration tests though, since they usually require some special setup
18:47:27 <felixfontein> unit tests are also a bit critical, since they can depend on collections that are not dependencies of the collection (since right now there is no standard way to say "unit testing needs the following collections to run")
18:47:39 <tadeboro> One thik I wanted to say about this is to remove the inclusion dates from the timeline. I think we can start accepting new collections just like any other contribution during the non-freeze interval.
18:48:14 <felixfontein> tadeboro: I guess we should still have a cut-off date (collections not approved by XXX will have to wait for the next Ansible major release)
18:48:24 <dmsimard> felixfontein: My ansible-test is rusty, is it reasonable to think we'd be able to run sanity and unit tests without pulling in containers ? I'm not sure to what extent we can rely on that to work within (for example) the RPM build environment
18:48:58 <felixfontein> dmsimard: I would always use the default containers for sanity and unit tests. otherwise you risk random strange failures.
18:48:59 <tadeboro> felixfontein: Cut-off date would be the same as for any other collection that want to get new major version in.
18:49:19 <dmsimard> felixfontein: what about without containers at all ?
18:49:29 <felixfontein> the docker containres are the best way to have reproducable results
18:49:50 <briantist> what's the impetus for not using the containers?
18:49:50 <felixfontein> dmsimard: without containers you will have a huge PITA of making sure that the tests you run have any significance
18:50:00 <tadeboro> dmsimard: Maybe we should do something similar to what AH does? That hink runs sanity tests on import (I think it runs `ansible-test sanity --docker`, but I am not 100% sure).
18:50:35 <dmsimard> briantist: I smell a rabbithole of needing to add docker (or podman) as a build dependency for ansible on fedora and elsewhere and doing container things within the rpm spec build environment
18:50:39 <felixfontein> dmsimard: also you will miss a lot of sanity tests (like import for Python 2.6, 2.7, ...) if the distro you are running on does not support these Python versions
18:51:03 <felixfontein> dmsimard: why do you need to run these tests on RPM build? why not just run them on Ansible build time?
18:51:22 <briantist> I definitely agree that the containers are the easiest (dare I say best) way of ensuring you can run those tests consistently
18:51:35 <briantist> was also going to suggest running them outside the RPM build process
18:51:38 <felixfontein> tadeboro: right now the cut-off date for inclusion is before the major version cut-off date
18:51:47 <felixfontein> tadeboro: I guess the question is whether we want to keep them separated or not
18:51:50 <jillr> dmsimard: adding that test dependency would likely be less work than reproducing the test container environment, and keeping it up to date
18:51:51 <dmsimard> felixfontein: I'd run them both but I'm less constrained about the tarball build process than I am in the fedora package build process
18:52:09 <dmsimard> felixfontein: in the use case of fedora, it would only test the version of python the package depends on
18:52:37 <tadeboro> felixfontein: I would just unify those two dates since I see no reason for keeping them separate.
18:52:38 <dmsimard> felixfontein: by both, I mean I'd run the tests after building the tarball and fedora would run their own tests
18:53:00 <briantist> we should probably decide on a "default" (like, by default we run sanity and units) and maybe have a way of overriding that, so for collection X we would not run units (has other dependencies) or whatever. So some config file, etc.
18:53:25 <dmsimard> briantist: the intent is to test that the RPM package also passes tests and that we didn't break anything
18:53:32 <felixfontein> tadeboro: we had that for Ansible 4 and before, and tried having them different this time. I really like them being separate since as a collection maintainer who releases a new major version for every major Ansible release, I'm pretty busy around that deadline, so having the other deadline separated from that makes life easier for me :)
18:53:47 <briantist> it might be extensible enough that it could be fine-grained to say "only run these unit tests" for example if only a small number of them can't be run, I dunno
18:54:14 <felixfontein> tadeboro: but having both dates the same is also fine for me, I'll just have less time to review in these days
18:54:59 <dmsimard> jillr: I would have thought that running ansible-test without --docker would be sufficient
18:55:18 <tadeboro> felixfontein: My grand plan is to have reviews done well in advance of release. Right now, we suck waaay to much when it comes to review process ;)
18:55:20 <felixfontein> dmsimard: if you don't want to invest a LOT of work to exactly replicate the default container in the OS you run the tests in, it's a LOT easier to just use the default container :)
18:55:22 <andersson007_> fyi posted a link the "Repo instead of issue" topic in issue 45
18:55:29 <briantist> dmsimard: it definitely isn't sufficient, it really is a lot of work
18:55:43 <dmsimard> 🤦
18:55:46 <felixfontein> tadeboro: indeed. though also the applicants suck somewhat, by not making changes until the last minute :)
18:56:26 <dmsimard> ok thanks, I will revisit the testing topic later
18:56:45 <jillr> dmsimard: tl;dr: python requirements hell
18:57:09 <tadeboro> felixfontein: But this is their problem and we cannot do much about that. Having an applicant waiting for 2 months and receiving no review is what we should fix.
18:57:11 <briantist> multiplied  by multiple python versions
18:57:25 <felixfontein> tadeboro: I agree fully!
18:58:07 <felixfontein> also if we're running tests, we need to figure out when to run them
18:58:35 <felixfontein> like: a) fix the dependencies for the next Ansible release, b) run the tests, c) what do we do when some tests do not pass? continue the release process? revert to older collection versions?
18:59:07 <felixfontein> (which also means that the time between fixing the collection versions and the actual release time increases from a couple of hours to potentially a day or more)
18:59:40 <tadeboro> I am not sure if I really want to know how many collections included in ansible fails sanity tests ...
18:59:58 <felixfontein> hehehe
19:00:05 <andersson007_> feels like a right time to switch to Open floor
19:00:11 <felixfontein> #topic open floor
19:00:12 <felixfontein> indeed
19:00:33 <felixfontein> tadeboro: we could start making bets on the percentage of collections that fail ;)
19:00:51 <andersson007_> hehe
19:01:36 <cybette> do we need a repo to record the bets?
19:01:53 <felixfontein> btw, I created another discussion topic a few days ago: "community.general and community.network: reduce maintenance for old stable branches" (https://github.com/ansible-community/community-topics/issues/55). if you have an opinion on this, feel free to voice it in that issue :)
19:02:01 <jillr> cybette: :)
19:02:15 <briantist> only partially related, but at one time I thought we were considering whether we need to run sanity tests from every version of Ansible, or whether only the latest/devel/milstone is needed
19:02:20 <felixfontein> cybette: I was going to suggest blockchain, so I get closer to completing another row in bullshit bingo ;)
19:02:32 <andersson007_> :)))
19:02:38 <cybette> :D
19:03:03 <briantist> was that ever formally put up for discussion or decided? anything I can do to reduce the number of GitHub runners used is helpful
19:03:13 <tadeboro> briantist: Since ansible packages onyl supports a single ansible-core release, I would assume we would run sanity tests from that version.
19:03:24 <felixfontein> briantist: I think it's a good start to run them with the ansible-core release included in the current Ansible release
19:04:00 <briantist> I mean in general collection CI, not in the previously discussed at-release
19:04:10 <felixfontein> since our inclusion requirements require that they pass for other versions as well, it would be nice to also verify that, but that's definitely less high priority...
19:04:23 <briantist> I run them with all versions of Ansible I support, I think  most collections do
19:04:27 <briantist> right ok
19:04:54 <felixfontein> briantist: I think we require collections to do that (at least weekly), but we don't check if they actually do
19:05:15 <felixfontein> ok, I guess it's time to close
19:05:18 <felixfontein> #endmeeting