18:00:18 <felixfontein> #startmeeting Ansible Community Meeting
18:00:18 <zodbot> Meeting started Wed Feb  9 18:00:18 2022 UTC.
18:00:18 <zodbot> This meeting is logged and archived in a public location.
18:00:18 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:18 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:19 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:19 <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:23 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:26 <felixfontein> #topic Updates
18:00:27 <cyberpear> o/
18:00:27 <briantist> o/
18:00:28 <jillr> o/
18:00:28 <felixfontein> hi everyone!
18:00:38 <felixfontein> #chair cyberpear briantist jillr
18:00:38 <zodbot> Current chairs: briantist cyberpear felixfontein jillr
18:00:41 <dmsimard> \o
18:00:48 <cybette> o/
18:00:54 <felixfontein> #chair dmsimard cybette
18:00:54 <zodbot> Current chairs: briantist cyberpear cybette dmsimard felixfontein jillr
18:01:07 <acozine> o/
18:01:09 <apollo13> the agenda should probably point to https://github.com/ansible/community/issues/645 instead of the closed ticket :)
18:01:24 <dmsimard> apollo13: good catch
18:01:28 <acozine> heh, welcome to 2022!
18:01:35 <felixfontein> #chair acozine apollo13
18:01:35 <zodbot> Current chairs: acozine apollo13 briantist cyberpear cybette dmsimard felixfontein jillr
18:01:42 <felixfontein> haha, good point :) gotte update my paste txt :)
18:01:58 <andersson007_> o-
18:02:04 <andersson007_> o/
18:02:06 <felixfontein> #chair andersson007_
18:02:06 <zodbot> Current chairs: acozine andersson007_ apollo13 briantist cyberpear cybette dmsimard felixfontein jillr
18:02:26 <samccann> o/
18:02:38 <felixfontein> #chair samccann
18:02:38 <zodbot> Current chairs: acozine andersson007_ apollo13 briantist cyberpear cybette dmsimard felixfontein jillr samccann
18:02:50 <gundalow> Hi folks
18:03:02 <felixfontein> #chair gundalow
18:03:02 <zodbot> Current chairs: acozine andersson007_ apollo13 briantist cyberpear cybette dmsimard felixfontein gundalow jillr samccann
18:03:54 <felixfontein> so, what do you want to discuss about today? :)
18:04:06 <sanjai28[m]> Hi, This is sanjai from ibm spectrum virtualize team.
18:04:06 <sanjai28[m]> We have raised a request to include ibm.spectrum_virtualize ansible collection to ansible community release but we did get any response for last 3 months. Please check the thread at https://github.com/ansible-collections/ansible-inclusion/discussions/35
18:04:07 <sanjai28[m]> Please validate and let us know the next step to move forward.
18:04:57 <felixfontein> #chair sanjai28[m]
18:04:57 <zodbot> Current chairs: acozine andersson007_ apollo13 briantist cyberpear cybette dmsimard felixfontein gundalow jillr samccann sanjai28[m]
18:06:17 <felixfontein> sanjai28[m]: reviews are done by volunteers, it looks like currently nobody has enough time to do all the reviews
18:07:37 <dmsimard> we should find the time to do a round of reviews, it's not the only review with lack of feedback
18:08:01 <sanjai28[m]> felixfontein: Thanks. When can we expect our collection to be included in Ansible community release ?
18:08:26 <dmsimard> sanjai28[m]: we can't commit to an ETA at this time
18:08:59 <dmsimard> however, we have recently agreed on a simplification of the community inclusion process which means it could land before ansible 6 (whereas previously it could only be included in Ansible 6 at the earliest)
18:10:05 <dmsimard> I appreciate your patience as we work through existing reviews (including yours)
18:10:11 <andersson007_> dmsimard: sounds good about inclusion review day, and i think it makes sense to divide things, i.e. for example, 2 reviewers per collection to avoid the situation when 1 collection has 5 reviews and the rest 0
18:10:26 <sanjai28[m]> dmsimard: Ok. Thanks for the update !!
18:10:52 <andersson007_> to spread limited human-time resources more evenly
18:11:03 <dmsimard> andersson007_: sounds like something we could do
18:13:44 <dmsimard> we may have skipped ahead and over updates, was there any ?
18:14:10 <andersson007_> i could try to handle c.sap and ibm on Friday or on Monday
18:14:15 <andersson007_> ok ok
18:14:20 <felixfontein> I don't have one, looks like nobody else has one either :)
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:29 <dmsimard> nothing immediately comes to mind either
18:16:42 <felixfontein> we currently have some active discussions:
18:16:50 <felixfontein> 1) https://github.com/ansible-community/community-topics/issues/66 How to handle moving of content from collections inside the Ansible package to collections outside the Ansible package?
18:16:58 <felixfontein> 2) https://github.com/ansible-community/community-topics/issues/65 which directories / files / file patterns should be excluded from the Ansible installation?
18:17:06 <felixfontein> 3) https://github.com/ansible-community/community-topics/issues/64 Crafting better changelog fragments
18:17:23 <felixfontein> should we talk about one (or more) of these?
18:17:43 <dmsimard> I did want to mention that there's been a lot of discussion in this thread: https://github.com/ansible-collections/news-for-maintainers/discussions/4 -- notably whether or not there should be a centos8-stream container image as a successor to the centos8 one (that is now EOL)
18:18:02 <felixfontein> 4) https://github.com/ansible-collections/news-for-maintainers/discussions/4 :)
18:18:11 <felixfontein> good point :)
18:18:33 <dmsimard> I've already met and talked to people about it because it's come up internally as well and I hope to come back with more answers after meeting with various folks tomorrow
18:18:40 <felixfontein> I sometimes wonder whether there shouldn't be more containers for other distros, than yet another RHEL derivate
18:19:10 <dmsimard> felixfontein: yes, in fact, there are some other distros that aren't tested -- like while we test ubuntu we don't test debian
18:19:22 <felixfontein> exactly...
18:19:24 <dmsimard> so there is somewhat of an overarching or broader discussion to have
18:20:18 <dmsimard> more on that later
18:24:23 <samccann> I'm up for talking about changelog fragments if there's a lull in the conversation?
18:24:28 <felixfontein> :)
18:24:33 * samccann ponders if it's a lull or just my client lagging
18:24:41 <felixfontein> it's pretty quiet right now
18:24:49 <dmsimard> I was reading through the discussions that felixfontein linked (thanks for bringing those up)
18:25:04 <samccann> #info added changelog examples to https://github.com/ansible-community/community-topics/issues/64
18:25:46 <felixfontein> let's talk about changelogs then :)
18:25:56 <felixfontein> #topic Crafting better changelog fragments
18:26:01 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/64
18:26:21 <samccann> So I'm looking for feedback on the examples (are they good? cuz these will go in the docs) and also, do we need to debate the definitions of the categories of changelogs. Like there was some discussion yesterday on whether the Python 3.8 requirement was  a Breaking change or a Major change (or even a minor change)
18:26:31 <andersson007_> speaking about https://github.com/ansible-community/community-topics/issues/66, i hope c.sap will get a part of the package soon:) But maybe it's worth discussing this case anyway (not now but in general)
18:26:45 <samccann> i still need to dig up github issues for a number of the examples
18:27:28 <felixfontein> samccann: quite a few examples in https://github.com/ansible-community/community-topics/issues/64#issuecomment-1015770590 do not stick to our guidelines of how to format the entries
18:28:08 <samccann> heh there's an action item for me - to RTD and update to match our own guidelines!
18:28:29 <felixfontein> hehe :)
18:29:31 <felixfontein> breaking vs. major changes is a hard one...
18:29:32 <andersson007_> the difference between breaking_changes and major_changes feels a bit subtle
18:29:53 <andersson007_> ah felixfontein you as always are a bit faster:)
18:29:58 <acozine> Overall, what's our goal? To create better docs for "How to craft good changelog fragments"? To implement a review process for changelogs? To enforce some kind of rules on new changelogs? To agree on stylistic suggestions (like "use past tense" or "no more than N characters"? All of the above?
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:27 <felixfontein> acozine: enforcing is hard (since there's not really a way to enforce his), but having better and more clear guidelines is definitely a good thing
18:30:28 <samccann> to me a major change means I can CHOOSE to do something differently. A breaking change means I MUST do something differently
18:30:37 <felixfontein> samccann: I agree
18:30:57 <felixfontein> and for me, dropping support for Python < 3.8 does mean I have to do something if I don't have Python 3.8 installed yet :)
18:31:09 <acozine> samccann: that's a nice, clear description of the difference
18:31:27 <andersson007_> breaking and major changes can be released in major releases, correct?
18:31:30 <samccann> acozine: the initial goal has been to give developers a better idea of what makes for a good changelog (includes the issue link, workarounds for known issues, etc etc).
18:31:48 <felixfontein> andersson007_: breaking - yes. major - depends whom you ask :)
18:31:49 <andersson007_> it can confuse folks (it relates to my last statement)
18:32:01 <acozine> excellent, thanks samccann
18:32:08 <felixfontein> some people announce new modules or some new features as major changes also in feature releases
18:32:09 <andersson007_> felixfontein: sounds confusing:)
18:33:02 <felixfontein> I personally keep major_changes for major releases, *except* for important announcements that should end up in the porting guide, which don't come with code changes
18:33:21 <felixfontein> like EoL for stable-1/stable-2 branches of c.g :)
18:33:30 <andersson007_> me too
18:34:03 <samccann> i'm confused. I thought semantic markup made those decisions for us (whether a major change has to be in a major release or not)??
18:34:49 <felixfontein> samccann: it only makes the decision for code changes. but not necessarily which changelog fragment to use for a change :) in particular if there is no code change
18:35:48 <andersson007_> yep, sometimes we need to announce something
18:36:04 <andersson007_> like coming breaking / major changes
18:36:35 <felixfontein> which are not strictly deprecations, so not a deprecated_features
18:37:18 <samccann> ok I'm still stuck on - if something is a major change in the changelog, does that mean it needs to be a major version update in the matching collection?
18:37:25 <felixfontein> for example https://github.com/ansible-collections/community.general/blob/stable-1/CHANGELOG.rst#v1313
18:37:28 <samccann> s/needs/MUST/ to use official terms
18:37:48 <felixfontein> it's a major change, but appears in a bugfix release
18:38:38 <samccann> oh interesting. So using the major change category to get some attention to the EOL announcement, but strickly speaking, not requiring a major version jump to the collection.
18:38:39 <felixfontein> it doesn't violate semver since there is no code change - in fact no change in behavior, except that the patch level of the version is increased
18:38:45 <felixfontein> yes
18:38:54 <acozine> ah, semantic versioning, not semantic markup
18:38:58 <samccann> heh
18:39:10 <samccann> it's all just... ait for it.... wait for it.... semantics!
18:39:11 <acozine> I was thoroughly confused for a bit
18:39:27 <felixfontein> :)
18:39:44 * samccann scrolls back to realize what she typed ...doh!
18:40:19 <acozine> you two seemed to both understand what was going on, so I just waited for enlightenment to dawn
18:40:26 <samccann> So can we say breaking changes MUST happen in major versions of a collection?
18:40:38 <samccann> acozine: I didn't even realize I'd typed it that way!
18:40:40 <felixfontein> samccann: yes
18:40:58 <andersson007_> +1
18:41:08 <felixfontein> I can't think of a breaking changes fragment without an actual breaking code change
18:41:26 <samccann> ok thanks. I've got enuf feedback to take next steps if y'all want to hit on another topic
18:41:46 <acozine> +1 for breaking changes MUST go with a major release
18:42:47 <acozine> a fragment (ahem) of clarity in a topic that isn't always so neatly defined
18:42:49 <markuman[m]> <felixfontein> "some people announce new modules..." <- does it mean, when I introduce just a new parameter to an existing module, I need to make a new major release? Or is someone doing it like this?
18:42:57 <andersson007_> alternatively we could use our own versioning breaking.major.minor.patch:)
18:43:11 <markuman[m]> acozine: +1
18:43:15 <felixfontein> markuman[m]: no, adding new parameters or new features is a minor_change, and only requires a minor version bump
18:43:26 <felixfontein> andersson007_: lol!
18:43:44 <samccann> definition of minor change - Minor changes to ansible-core, modules, or plugins. This includes new features, new parameters added to modules, or non-breaking behavior changes to existing parameters, such as adding additional values to choices[]. Write in present tense.
18:44:45 <felixfontein> I can imagine that some collection authors/maintainers disagree of a new feature being 'minor', and thus use major_changes for new features
18:45:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:09 <samccann> yeah I don't see us enforcing this. They are guidelines only
18:45:28 <samccann> though I could agree that Breaking changes is a firm MUST.
18:45:46 <andersson007_> felixfontein: what would consider a minor change than..
18:45:59 <andersson007_> s/than/then/
18:46:11 <felixfontein> andersson007_: no idea :)
18:46:43 <markuman[m]> How long must be breaking changes announced? Maybe its a bit off-topic
18:46:48 <samccann> I can pull out the 'new features' part of that
18:47:32 <jtanner> major/minor is subjective. this is why in core, it was always bugfix/feature/refactor, with the latter 2 not getting backported
18:47:43 <andersson007_> markuman[m]: i don't know if there are rules. I usually try to plan them at least in 6 months after announcing
18:48:02 <andersson007_> via a changelog
18:48:28 <andersson007_> marked as major_changes
18:48:30 <felixfontein> jtanner: the categories major/minor come from core :)
18:49:23 <jtanner> does the bot label PRs as major or minor?
18:49:58 <felixfontein> no, but there are changelog fragments, and these are minor or major changes (or bugfixes or ...)
18:50:32 <briantist> I think they are guidelines rather than rules, I try to give 6 months as well, but if it's a month after a major release and there's 5 months until the next one, I'm not going to wait 11 months to make the change just to make a hard 6 month minimum, not necessarily anyway, it does depend somewhat on the expected impact of the breakage, not all breakages are created equal!
18:50:49 <samccann> we do have minor AND bugfixes as changelog categories. And yeah, shades of grey which one to use
18:51:20 <felixfontein> yeah, there's always some discretion :)
18:52:17 <samccann> I see the distinction as a bugfix fixes... wait for it... a bug. :-) Whereas a minor change is something new (not fixing something broken). But yeah, I don't expect everyone will get picky at that level.
18:52:21 <samccann> thus... guidelines
18:52:21 <andersson007_> briantist: agreed
18:52:23 <samccann> ;-)
18:52:47 <acozine> we can encourage folks to include the timeline if it's unusually short
18:53:06 <acozine> but yeah, guidelines not requirements
18:54:15 <samccann> #info feedback on this topic included here -https://github.com/ansible-community/community-topics/issues/64#issuecomment-1034088582
18:54:29 <samccann> cuz I didn't info a thing during this whole discussion!
18:55:02 <felixfontein> :)
18:55:56 <andersson007_> should we get rid of open floor part as everything except updates seems to be like an Open floor?:)
18:56:21 <felixfontein> #topic open floor
18:56:29 <felixfontein> we can still have it... not that I expect anything to happen ;
18:56:30 <felixfontein> )
18:56:34 <andersson007_> :)
18:56:35 <cybette> I have an item I did not manage to include in updates as I was distracted
18:56:38 <acozine> andersson007_: you mean, get rid of the open floor for today's meeting? or in general?
18:57:03 <andersson007_> acozine: i mean we could skip highlighting it
18:57:08 <andersson007_> in general
18:57:16 <cybette> #info We will be closing issue 546 after releasing this week's Bullhorn newsletter. Please continue to share your news items with newsbot (in #ansible-social) as most of you have been doing already. Thanks!
18:57:32 <samccann> do we need an Open Floor... about... Open Floors? :-)
18:57:38 <acozine> Carol Chen: link?
18:57:49 <acozine> samccann: heh
18:57:55 <cybette> #link https://github.com/ansible/community/issues/546
18:59:14 <andersson007_> you can redirect to https://github.com/ansible/community/wiki/News#the-bullhorn from your guides and readmes when mentioning Bullhorn i guess, cybette ?
18:59:52 <andersson007_> don't forget to update your collection docs, folks
18:59:56 <cybette> andersson007_: yeah I already do. this is just in reference to the issue that we'll be closing.
19:00:15 <cybette> ^ great reminder, thanks andersson007_ !
19:00:30 <andersson007_> the community is always welcome:)
19:03:03 <acozine> time for my lunch - thanks for an interesting discussion, folks!
19:03:18 <acozine> and thanks Felix Fontein for "driving"
19:03:20 <cybette> thanks everyone!
19:03:22 * acozine waves
19:03:33 <samccann> enjoy!
19:03:39 <felixfontein> #endmeeting