18:00:14 <felixfontein> #startmeeting Ansible Community Meeting
18:00:14 <zodbot> Meeting started Wed Jan 19 18:00:14 2022 UTC.
18:00:14 <zodbot> This meeting is logged and archived in a public location.
18:00:14 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:14 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:14 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:14 <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:18 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:21 <felixfontein> #topic Updates
18:00:46 <samccann> o/
18:01:11 <felixfontein> #chair samccann
18:01:11 <zodbot> Current chairs: felixfontein samccann
18:01:13 <jillr> o/
18:01:22 <felixfontein> #chair jillr
18:01:22 <zodbot> Current chairs: felixfontein jillr samccann
18:01:56 <cidrblock[m]1> o/ Happy new year everyone
18:02:09 <felixfontein> #chair cidrblock[m]1
18:02:10 <zodbot> Current chairs: cidrblock[m]1 felixfontein jillr samccann
18:02:13 <felixfontein> Happy New Year cidrblock[m]1!
18:02:20 <andersson007_> o/
18:02:35 <dmsimard> o/
18:02:55 <felixfontein> #chair andersson007_ dmsimard
18:02:55 <zodbot> Current chairs: andersson007_ cidrblock[m]1 dmsimard felixfontein jillr samccann
18:03:20 <felixfontein> does anyone have updates for today?
18:03:57 <felixfontein> I think we have a vote which finished yesterday, but so far nobody counted the votes
18:04:07 <dmsimard> no particular updates from me, been busy on other things :/
18:04:38 <andersson007_> which vote felixfontein ?
18:04:44 <samccann> I have some more details on crafting better changelog fragments. still a WIP but comments welcome at - https://github.com/ansible-community/community-topics/issues/64#issue-1107241644
18:05:07 <samccann> probly should have info'd that...
18:05:15 <felixfontein> dmsimard: the one on FCQNs in docs
18:05:20 <samccann> #info comments welcome on how to craft good changelog fragments  - https://github.com/ansible-community/community-topics/issues/64#issue-1107241644
18:05:23 <felixfontein> s/FCQN/FQCN/
18:05:26 <jillr> I like this idea samccann
18:06:17 <samccann> thanks
18:06:47 <felixfontein> me too :)
18:07:12 <cidrblock[m]1> samccann: brilliant
18:07:38 <jillr> we have been using major_changes in collections, I'll add my thoughts to the ticket later this afternoon when I have time to put thought into it
18:07:40 <tadeboro> o/
18:07:43 <samccann> ;-) I'll be putting up some examples of each next. Once we all feel comfy, I can move the info into official docs
18:09:01 <felixfontein> I would use major_changes only for things that should end up in the porting guide, which seldomly happens
18:09:05 <felixfontein> #chair tadeboro
18:09:05 <zodbot> Current chairs: andersson007_ cidrblock[m]1 dmsimard felixfontein jillr samccann tadeboro
18:09:43 <felixfontein> ok, let's start with a topic :)
18:09:45 <felixfontein> #topic Establishing the roadmap for Ansible 6.0.0
18:09:45 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/56
18:09:49 <felixfontein> #info PR for roadmap proposal: https://github.com/ansible/ansible/pull/76772
18:10:02 <dmsimard> thanks for picking that up felixfontein
18:10:22 <felixfontein> I created that PR so we have somthing to talk about; I would suggest that we streamline the PR in this meeting so we have something to vote on (asyncronously), so we have a final roadmap ASAP
18:10:28 <felixfontein> does that sound good?
18:10:29 <briantist> hello, little late
18:10:29 <briantist> o/
18:10:39 <felixfontein> #chair briantist
18:10:39 <zodbot> Current chairs: andersson007_ briantist cidrblock[m]1 dmsimard felixfontein jillr samccann tadeboro
18:10:59 <felixfontein> I mostly copied the dates over from last release's roadmap and adjusted them, and I added a 'planned work' section
18:11:11 <berkhan> o/
18:11:19 <felixfontein> it might be better to drop that section if we can't decide on what should be in it, so we can at least fix the dates soon :)
18:11:37 <felixfontein> #chair berkhan
18:11:37 <zodbot> Current chairs: andersson007_ berkhan briantist cidrblock[m]1 dmsimard felixfontein jillr samccann tadeboro
18:11:57 <felixfontein> the current topic is about https://github.com/ansible/ansible/pull/76772 / https://github.com/ansible-community/community-topics/issues/56
18:12:11 <dmsimard> felixfontein: PR looks good to me at first glance though I must take some more time to properly review
18:12:23 <samccann> Added a comment about when core is pulling the branch (happening sooner than it did for 2.12)
18:13:21 <felixfontein> samccann: funnily I thought about that while working on the PR, but apparently I didn't adjust it :)
18:13:58 <samccann> :-)
18:14:13 <andersson007_> fyi: i've just counted votes in https://github.com/ansible-community/community-topics/issues/58#issuecomment-1016735278 but feel tired + at least one more counting is required
18:14:32 <felixfontein> I've updated the PR
18:14:59 * jillr counts #58
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:16:33 <felixfontein> about the roadmap, I tihnk the most (potentially) controversial parts are a) last day for collections to be submitted (one week before freeze like last time), b) the planned work items
18:16:40 <felixfontein> what do you think about these?
18:17:38 <felixfontein> I hope we can get rid of the last day for collections to be submitted by doing https://github.com/ansible-community/community-topics/issues/63 (simplify the inclusion process); so for now I would simply keep that part of the roadmap (since it is hopefully no longer necessary in a couple of weeks anyway and can then be removed)
18:17:41 <samccann> planned work could be TBD if you think there will be ..planned work coming
18:18:18 <dmsimard> I'm ok with the planned work as it is in the PR, we can always update it if we find there are other things
18:18:42 <dmsimard> I don't mind the collection review date but we need to address the lack of reviews ahead of the last week before the deadline is up
18:19:04 <felixfontein> :+1:
18:19:09 <dmsimard> We were very last minute for Ansible 5 and there's an extra collection or two that could have made it if we had gotten reviews in time
18:20:13 <felixfontein> if we get rid of the two dates per year for inclusion, and instead allow new collections in any minor release, a lot of this pressure should go away. that doesn't mean that more reviews will magically show up, but at least this "we need a review NOW or we have to wait for 6 months" goes away
18:20:26 <tadeboro> dmsimard: I really hope we can start adding collections more often to avoid the nasty situations right before the deadline.
18:20:33 <dmsimard> +1
18:20:37 <briantist> +1
18:21:13 <felixfontein> once we're done with the roadmap today we can switch to #63 so we can also start voting on that one soon :)
18:21:14 <jillr> +1
18:21:16 <tadeboro> Also, because we now know there will be no inclusions for another 5 months, no one is doneg reviews ...
18:21:27 <dmsimard> tadeboro: yeah, that
18:21:29 <felixfontein> yep, that's not really helping
18:21:29 <tadeboro> *doing
18:21:58 <felixfontein> (I'm also not doing collection reviews because I have way too many things to do anyway at the moment, but that's another topic ;) )
18:22:10 <dmsimard> I also want to do "counter" inclusion reviews
18:22:31 <dmsimard> as in, proactively check and consider if there's any collections that need to be out (community.azure comes to mind)
18:22:56 <felixfontein> ah. I was about to ask what you mean by 'counter' :) yes, that sounds good. we need some process for that first, though
18:23:29 <tadeboro> I have a feeling that all hell will break loose once we start revieweing collections that we grandfathered into ansible ;)
18:23:47 <felixfontein> +1+1+1+1
18:24:21 <andersson007_> +1
18:24:30 <felixfontein> it would also be great to regularly re-review the ones we have added (and the existing ones), but I don't think we have resources for that
18:24:46 <jillr> community.azure (and I thnk community.gcp?) are duplicates iirc, so maybe we can start easy  :)
18:25:06 <dmsimard> jillr: yeah, community.google is in a relatively similar spot as community.azure
18:25:11 <felixfontein> I mean that also in a positive way, especially for maintainers of small collections it would be good to get some more eyes on them, at least from time to time
18:25:20 * gundalow waves
18:25:25 <jillr> dmsimard: ah yeah, i forgot the exact collection name for that one
18:25:32 <dmsimard> felixfontein: we should automate the things we can but of course there's always going to be some manual/human reviewing required
18:25:37 <felixfontein> c.google has a handful of modules/plugins that are not duplicates (but not very many)
18:25:40 <felixfontein> #chair gundalow
18:25:40 <zodbot> Current chairs: andersson007_ berkhan briantist cidrblock[m]1 dmsimard felixfontein gundalow jillr samccann tadeboro
18:25:42 <samccann> is there a bot like thing that could review existing collections to at least gather stats? like issues/prs backlog growing, minimal merges etc?
18:26:17 <felixfontein> dmsimard: automated things are great, but the most helpful comments are usually the ones generated by humans, especially for maintainers of smaller collections that don't have much contact with other maintainers :)
18:26:47 <felixfontein> btw, could we please finish the roadmap topic before proceeding to another one? :)
18:27:05 <dmsimard> felixfontein: yeah but stuff like "checking that CI ran successfully recently" or "there hasn't been a commit in this collection for over a year"
18:27:26 <felixfontein> if everyone's happy with the current PR that's fine and we are done, but please say so if you think so :)
18:28:42 <dmsimard> I will review dates after the meeting, otherwise lgtm
18:28:55 <gundalow> Existing PR is good. Lets get that merged (assuming people are happy).
18:29:29 <felixfontein> should we try a quick voting period (one week)?
18:29:48 <felixfontein> then we can merge it in a week (if enough of us agree)
18:30:02 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:02 <dmsimard> yeah no need to extend it further than that I think
18:30:04 <gundalow> For the roadmap? Sounds good. It's copy paste from previous ones (apart from items at the end)
18:30:14 <tadeboro> felixfontein: Where should we state our agreement? Adding comments to the topic does not sound right since that topic is a bit wider. Maybe directly in he PR?
18:30:16 <tadeboro> *the
18:30:45 <andersson007_> maybe we create a subtopic?
18:31:44 <andersson007_> to keep everything related to vote in one place (though I'm not insisting:)
18:32:11 <gundalow> vote via GH Review on the PR
18:32:41 <felixfontein> shouldn't we keep the usual workflow, i.e. either use https://github.com/ansible-community/community-topics/issues/56 or create a new issue for it?
18:32:53 <andersson007_> +1
18:32:59 <gundalow> oh, yes,sorry
18:33:13 <felixfontein> I'll create a issue later
18:33:19 <andersson007_> thanks!
18:33:21 <felixfontein> ok, thanks everyone!
18:33:50 <felixfontein> #topic Vote ended: documentation should use FQCN also for ansible.builtin names
18:33:53 <felixfontein> #info https://github.com/ansible-community/community-topics/issues/58
18:34:10 <felixfontein> andersson007_ and jillr counted the votes, almost everyone was in favour of this
18:34:18 <felixfontein> also the ones who voted too late ;)
18:34:27 <samccann> woot
18:34:57 <samccann> I think this is related to an older PR so now I can go dig that up and approve (or ask nicely for a rebase by now)
18:35:04 <felixfontein> yep
18:35:20 <felixfontein> there was a community PR adding ansible.builtin everywhere
18:35:50 <felixfontein> #topic Simplifying the collection inclusion process
18:35:52 * dmsimard still doesn't write his own playbooks using ansible.builtin FQCN
18:35:55 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/63
18:36:01 <felixfontein> now we can continue on the inclusion process :)
18:37:16 <cidrblock[m]1> felixfontein: better late than never? :)
18:37:24 <felixfontein> :D
18:37:35 <felixfontein> you can think of all the above comments on this process in this section ;)
18:39:57 <gundalow> Are there any downsides to this?
18:40:16 <felixfontein> I don't think so
18:41:33 <samccann> Back when everything was in ansible, were new modules restricted to just major releases or happend in minor releases too?
18:41:37 <felixfontein> I guess the main reason for the current process is to have to worry about inclusions only once (except for the review process), but as we saw that doesn't work so well
18:41:49 <felixfontein> samccann: they were restricted to 'major' releases
18:43:08 <samccann> anyone recall why they were restricted or was it a bandwith thing on who could review/validate them?
18:43:09 <gundalow> Only possible downside I can think of is current process gives us a deadline (and deadlines are often motivating functions).
18:43:11 <tadeboro> But this is not really "fair" since collections that are part of the ansible package can introuce new functionality outside major version bumps while collections that want to become part of the Ansible package need to wait for a major release.
18:43:59 <gundalow> samccann: new thing was viewed as MAJOR change, even if it was net-new module (therefore couldn't be design break anything)
18:44:26 <felixfontein> gundalow: it was a minor change, but there were only bugfix and major releases :)
18:44:36 <tadeboro> gundalow: Deadlines are nice, but having only two deadlines per year makes us lazy ;)
18:44:58 <felixfontein> also collection maintainers tend to now work on early feedback since the deadline is still so far away
18:45:02 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:07 <felixfontein> (of course not everyone, but that happened multiple times already)
18:45:12 <bcoca> assasination lines, get it done or ...
18:45:19 <bcoca> deadlines are just no threat
18:45:29 <gundalow> tadeboro: haha, that's a fair point. We should (as a separate topic) think about how we can make inclusion easier for 1) reviewers 2) collection maintainers
18:45:43 <gundalow> I'm +1 to #63
18:46:26 <andersson007_> I'm generally also for simplification (in terms of time)
18:46:27 <samccann> yeah I think it's worth trying it for Ansible 6 and then see how it goes
18:46:36 <samccann> i mean Ansible 5 doh.. the current one
18:46:45 <andersson007_> (not in terms of demands)
18:47:00 <felixfontein> if we decide we'll do it, we can already start adding new collections to Ansible 5 :)
18:47:08 <felixfontein> (except if we explicitly say that we will only do this in Ansible 6)
18:48:07 <felixfontein> how about the deadline for inclusions in the next major version? right now it is one week before feature freeze; I think we can make both dates coincide (since a new collection is a new feature)
18:48:14 <felixfontein> or do you want to keep it one week in advance?
18:48:27 <bcoca> in general people care more about changes than new when it comes to versioning, something new is always nice, the problem is if something old changes behaviour
18:48:47 <felixfontein> the main reason (from my side) for the one week difference was that too much work accumulated because of all collections wanted to be reviewed for inclusions right before this date - but that's no longer happening
18:49:31 <felixfontein> bcoca: that already happens right now
18:50:41 <gundalow> I think we still need to keep a cutoff date (for the `.0.0` release)
18:51:38 <felixfontein> gundalow: yes, but it could be the same cutoff date than for new major versions of already included collections, i.e. feature freeze
18:52:04 <felixfontein> there's no longer a reason to let it be a separate date (that's one week earlier)
18:52:47 <felixfontein> if we all think this is the case, then I can add a simplified proposal to #63 with a +1 / -1 vote
18:52:57 <felixfontein> right now the vote consists of two questions, one with +1/-1 and the other with (a),(b),(c)
18:53:04 <briantist> the only possible reason I suggested having a an earlier cutoff date is if there's a (slightly?) bigger risk in introducing a new collection that would take longer to resolve, like if it caused the package not to build correctly or whatever; like if this was not caught before actually including it.
18:53:07 <briantist> But...
18:53:35 <briantist> I am not very familiar with the process, so if that's highly unlikely because it would be tested/get caught earlier, then I'm fine with having no difference
18:53:53 <briantist> I trust and will defer to the folks who know better in this case :)
18:53:58 <felixfontein> I think if that would happen, there would be a bug in antsibull that was just exposed :)
18:54:31 <felixfontein> but that can also happen with existing collections, so I don't see the need for an extra week here
18:54:48 <briantist> makes sense to me!
18:55:02 <felixfontein> most inclusions are probably already done before that week, so I would assume that it's not more than one collection that's going to be added in the last few days
18:55:05 <felixfontein> (I hope :) )
18:55:42 <felixfontein> if we notice that this is a problem, we can move the date earlier again for Ansible 7's roadmap
18:55:44 <briantist> heh
18:57:36 <briantist> sgtm
18:57:51 <felixfontein> what does everyone else think? :)
18:58:40 <gundalow> +1
18:58:59 <jillr> I don't feel strongly about the date either way, I'm good with experimenting and adjusting if we need to
18:59:14 <andersson007_> +1 for experimenting
18:59:24 <andersson007_> and adjusting if needed
18:59:45 <jillr> I have to drop for another meeting now though - thanks y'all!
18:59:57 <felixfontein> thanks jillr!
19:00:02 <cidrblock[m]1> +1 try it, revisit, try it differently, let's see what works
19:00:12 <felixfontein> ok, I'll create a simplified proposal and then let's vote :)
19:00:27 <felixfontein> I think for that one we can use the 'usual' two weeks
19:01:01 <andersson007_> 2 weeks as a default sgtm
19:01:03 <cidrblock[m]1> owned by my calendar, see you all
19:01:25 <felixfontein> :)
19:01:30 <felixfontein> #topic open floor
19:01:33 <felixfontein> let's do a mini open floor
19:01:41 <felixfontein> does anyone have a topic?
19:02:30 <samccann> this is ready for review - https://github.com/ansible/ansible/pull/76764
19:02:46 <samccann> mostly just moving files around to create separate contributor guides
19:02:51 <felixfontein> #info We have a new vote, active until next week: https://github.com/ansible-community/community-topics/issues/56
19:03:34 <samccann> you can see it in action here - http://docs.testing.ansible.com/ansible/devel/installation_guide/index.html#
19:03:59 <samccann> Goal is to move the files and merge. Then take one guide at a time and combine/shift to the docs over in the community repo for collections
19:05:00 <andersson007_> I have to go, folks. Thanks everyone! thanks felixfontein for leading the meeting!
19:05:10 <felixfontein> thanks andersson007_!
19:05:15 <felixfontein> ok, I think it's time to close the meeting :)
19:05:17 <felixfontein> thanks everyone!
19:05:19 <felixfontein> #endmeeting