18:00:17 <gotmax23> #startmeeting Ansible Community Meeting
18:00:17 <zodbot> Meeting started Wed May 31 18:00:17 2023 UTC.
18:00:17 <zodbot> This meeting is logged and archived in a public location.
18:00:17 <zodbot> The chair is gotmax23. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:17 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:24 <gotmax23> #topic Salutations
18:00:34 <gotmax23> Landrash[m], acozine, andersson007_, anwesha, ascherbaum, baptistemm, bcoca, briantist, cidrblock, cyberpear, cybette, dericcrago, dmsimard, felixfontein, geerlingguy, gotmax, gundalow, gwmngilfen, ikhan_, jillr, jtanner, lmodemal, mariolenz[m], markuman, maxamillion, misc, nitzmahone, ompragash, oranod, resmo, russoz, samccann, thaumos, wbentley15[m], zbr: The Ansible community meeting is starting now!
18:00:34 <gotmax23> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself.
18:00:58 <andersson007___> o/
18:01:40 <gotmax23> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
18:02:25 <andersson007___> #chair andersson007___
18:02:36 <gotmax23> #info Ansible 8.0.0 was released this week: https://groups.google.com/g/ansible-devel/c/oc0vyV5X3Og. Thanks to @rooftopcellist for handling the release!
18:02:36 <anwesha[m]> I am skipping the travelling back from PyCon Italy. Still at the airport.
18:02:45 <gotmax23> @chair andersson007___ gotmax anwesha
18:03:10 <gotmax23> Oops...
18:03:22 <gotmax23> #chair andersson007___ gotmax anwesha
18:03:22 <zodbot> Current chairs: andersson007___ anwesha gotmax gotmax23
18:03:42 <gotmax23> Safe travels anwesha!
18:03:46 <andersson007___> great news about Ansible 8
18:03:51 <andersson007___> thanks everyone involved!
18:04:09 <gotmax23> Indeed!
18:04:28 <acozine> o/
18:04:29 <gotmax23> We have a couple topics, so speak up if you're interested in any in particular.
18:04:39 <gotmax23> I'll wait a couple more minutes for folks to file in :)
18:04:46 <gotmax23> #chair acozine
18:04:46 <zodbot> Current chairs: acozine andersson007___ anwesha gotmax gotmax23
18:04:52 <gotmax23> 🌊
18:05:11 <acozine> hello everybody
18:05:19 <samccann> o/
18:05:22 <andersson007___> hello acozine
18:05:26 <acozine> anwesha: sorry about the delay at the airport
18:05:34 <acozine> hi andersson007___ !
18:05:41 <Leo[m]> Hi all!
18:05:48 <gotmax> #chair Leo[m]
18:05:48 <zodbot> Current chairs: Leo[m] acozine andersson007___ anwesha gotmax gotmax23
18:06:15 <acozine> hi Leo
18:06:45 <gotmax23> I think I'll start with Create a policy for hotfix/bugfix ansible releases #231
18:06:59 <gotmax23> #topic Create a policy for hotfix/bugfix ansible releases
18:07:04 <gotmax23> #link https://github.com/ansible-community/community-topics/issues/231
18:07:49 <gotmax23> Basically, the question is whether we should create a formal policy about hotfix/bugfix releases in between our regularly scheduled X.Y.0 released.
18:08:18 * acozine needs to go answer a question from the painters, BRB
18:10:14 <andersson007___> are there any possible negative consequences if we don't have the policy?
18:10:30 <andersson007___> i mean we just release them if needed
18:10:50 <samccann> if we don't have a policy, what do we say when collection X has a fix they deem is too urgent to wait for the next 4-week package release?
18:11:03 <gotmax23> Right
18:11:31 <samccann> tho we've only had 3 so far in 2.5 yrs so... maybe we don't need a formal policy yet?
18:11:41 <gotmax23> If there's a security vulnerability in a collection, it's cut and dry, but there may be ambiguity in some cases
18:12:26 <gotmax23> Perhaps not, but a user reported an ansible-build-data issue requesting a bugfix release for a serious bug, so I figured I'd get the discussion started.
18:12:43 <gotmax23> (https://github.com/ansible-community/ansible-build-data/issues/232 is the issue in question)
18:13:12 <samccann> ah gotcha
18:13:32 <samccann> then yeah, a policy might be good.
18:14:01 <gotmax23> If that bug had been reported e.g. two weeks before the next scheduled release and not three days before when there was no point, I'm not sure what we would've done
18:14:02 <andersson007___> not sure as we have ~120 collections and the process afaik is not automated
18:14:40 <gotmax23> Yeah, the release process is a bit convoluted
18:14:54 <andersson007___> if it's ok for release engineers to release on demand, i'm ok with it:)
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:02 <samccann> looking at the three examples Felix added, I'd say the first one (rolling back a collection to a prior version because the collection had  syntax error) might be one we would use a policy to say' nope, not critical enuf'
18:15:21 <gotmax23> That one is very crucial I'd say
18:15:25 <acozine> I thought we defaulted to "release a new collection version and have uses install that"?
18:15:33 <acozine> s/uses/users
18:15:46 <gotmax23> That syntax error single-handedly broke ansible package builds for several Linux distros
18:15:48 <samccann> well if the collection has a security problem, then the package has a security problem
18:15:58 <gotmax23> Right
18:16:11 <samccann> oh maybe the flip question is - when would we NOT roll a bufix release
18:16:23 <gotmax23> I think that's a useful way to frame it
18:17:16 <gotmax23> Do you know if ansible-core have a written policy of what they consider "critical bugfixes" that would be backported to older releases?
18:17:39 <andersson007___> and i would definitely not recruit the SC to decide whether each particular case is critical or not:)
18:17:44 <samccann> I can't recall seeing anything that defines what critical is
18:18:22 <Leo[m]> gotmax23: That probably falls with the sec team, under the critical impact https://access.redhat.com/security/updates/classification/
18:19:25 <andersson007___> maybe something like "we release a patch release on demand only in case of critical security fixes. a release engineer decides whether it's critical enough in each particular case"
18:19:41 <andersson007___> to keep it flexible enough
18:19:53 <andersson007___> w/o to much burocracy
18:19:54 <Leo[m]> the problem would be, who defines what critical is, if it's a community collection
18:20:18 <gotmax23> That was going to be my next comment :)
18:20:25 <samccann> so some of these were not security but were critical (aka breaking a bunch of distros)
18:20:32 <gotmax23> Correct
18:20:44 <gotmax23> Also, it rendered a part of the collection completely unusable
18:20:52 <andersson007___> i would suggest delegating it to release engineers
18:21:05 <Leo[m]> samccann: we have the critical bugfix as well in rhel for ex. didn't link it above though
18:21:16 <andersson007___> we can define a list of engineers on docs.ansible.com
18:21:18 <samccann> I'd say a secruity issue gets fixed, anything else is up to the discretion of the release manager, with the option to raise it to the steering committeee if the user feels it needs to override the release manager
18:21:52 <gotmax23> That sounds reasonable
18:21:56 <samccann> my guess is all of them thus far have been discussed by more than one person etc
18:21:57 <andersson007___> yep
18:22:37 <acozine> yeah, as long as cutting releases is in the hands of a few people, those are the people who should make that call
18:22:39 <gotmax23> I would like to make sure the release managers are okay with this before we add more things they have to do
18:22:55 <samccann> good point
18:23:03 <gotmax23> But I'm on board if they are :)
18:23:20 <andersson007___> :)
18:23:29 <Leo[m]> +1, I mean if we are talking release blocking stuff, they should be involved at some point.
18:24:11 <andersson007___> i think we should anyway list people who has commit in ansible-build-data on docs.ansible.com
18:24:46 <Leo[m]> andersson007___: Can we do that dynamically, to avoid manually maintaining  that list?
18:24:47 <gotmax23> That's not a bad idea
18:25:12 <andersson007___> Leo[m]: we should think
18:25:17 <samccann> okay but people with ansible-build-data commit rights aren't all release managers. I'd say most currently are not
18:25:22 <andersson007___> hard to say on the spot
18:25:26 <gotmax23> Right
18:25:27 <andersson007___> but it's a good idea
18:25:48 <andersson007___> i think those people is a team
18:25:51 <andersson007___> release team
18:26:02 <gotmax23> FTR, a lot of people have commit on ansible-build-data. I believe everyone on the community-team, felixfontein, mariolenz, and I have.
18:26:16 <andersson007___> they are all involved
18:26:43 <andersson007___> and they imo should collectively decide
18:27:13 <andersson007___> w/o too much bureaucracy
18:27:19 <samccann> ah I see what you're saying. it's not just the person creating the package and putting it up on pypi that should decide
18:27:33 <andersson007___> yes
18:27:53 <andersson007___> on the other hand if that person who does the job wants, why not..
18:27:54 <samccann> so instead of 'up to the discretion of the release manager' it's 'up to the discretion of the release team' and it's those build-data folks
18:27:58 <gotmax23> That's fine with me
18:28:13 <andersson007___> yes
18:28:40 <andersson007___> answering my own last question: nope, they shouldn't release if they just want
18:29:19 <andersson007___> it'd be a bad precedent
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:06 <andersson007___> if someone releases on demand w/o questioning, than everyone will think they can demand in any case
18:30:18 <samccann> agreed
18:30:23 <gotmax23> :+1:
18:31:13 <gotmax23> I think we can require opening up issues about whether to create a hotfix/bugfix release in ansible-build-data and then require consensus from a couple people before proceeding
18:31:16 <gotmax23> How does that sound?
18:31:26 <andersson007___> +1
18:31:31 <samccann> +1
18:31:46 <gotmax23> where poeple is ansible-build-data committers and release managers
18:31:49 <Leo[m]> gotmax23: would the reviewers feature work for this? like a hard quota on X reviewers?
18:32:12 <andersson007___> so the key points: 1. critical security fixes 2. release team 3. consensus
18:32:45 <gotmax23> Exactly
18:33:31 <andersson007___> gotmax23: yeah those people == release team
18:33:48 <gotmax23> Leo: I don't think that would really work here. There's other steps besides committing the build data. Also, I'm generally against those type of review requirements. If you don't trust your committers to abide by the rules and responsibly use their privs, then you shouldn't give them at all.
18:34:12 <andersson007___> +1
18:36:04 <gotmax23> Are we ready to move on? There's always the issue tracker and I don't want this to turn into endless bikeshedding :).
18:36:18 <andersson007___> gotmax23: i have a question
18:36:39 <gotmax23> Ask away!
18:36:39 <andersson007___> where are we gonna have the "policy" written?
18:36:55 <andersson007___> ansible-buit-data or docs.ansible.com?
18:37:14 <Leo[m]> gotmax23: Good points!
18:37:29 <andersson007___> anyway, if someone raise a PR and ping the committee, it'd be great:)
18:37:43 <gotmax23> You mean where should we define the policy?
18:37:48 <andersson007___> yep
18:38:44 <samccann> I don't think we have anything on docs.ansible.com today about building the package etc. But we could add the names of  the current release team to one of those collection contributor pages if we want
18:38:53 <samccann> and the policy
18:39:01 <gotmax23> For the record, I'm starting to get weary of defining things like the collection requirements and other SC policies in ansible/ansible where the community doesn't have access.
18:39:34 <andersson007___> good point
18:40:03 <samccann> true
18:40:04 <andersson007___> so ansible-buit-data then? I'm ok, just asking
18:40:24 <gotmax23> I think so
18:41:01 <andersson007___> if there's something touchable/ seeable (a PR), it usually speeds up the process of decision making
18:41:17 <andersson007___> :)
18:41:34 <gotmax23> #action $PERSON to work on putting together a PR to define a formal policy based on what was discussed in the meeting
18:41:53 <andersson007___> 👍
18:42:04 <gotmax23> #topic Open Floor
18:42:05 <andersson007___> gotmax23: thanks for bringing it up!
18:42:23 <samccann> I have a couple of floor items
18:42:26 <gotmax23> Sure :). Thanks everyone for the good discussion.
18:42:51 <samccann> #info please review/approve the Ansible 9 roadmap pr - https://github.com/ansible-community/community-topics/issues/222
18:42:59 <samccann> so we can get that in sometime soon :-)
18:43:07 <gotmax23> I think we agreed to start a formal vote by now but then forgot
18:43:23 <samccann> cool that would be good thanks
18:43:25 <samccann> pr is https://github.com/ansible/ansible/pull/80851
18:44:12 <gotmax23> #action $AN_SC_MEMBER to start a vote on the Ansible 9 roadmap PR
18:44:20 <samccann> the next is a general question - we are looking to get good working examples of the ansible CLI commands with commonly used flags to add to the command cheetsheet. We have this topic - https://github.com/ansible-community/community-topics/issues/232
18:44:48 <samccann> we were going to open on topic per CLI command to keep the replies separate. Is that going to be too annoying? should we just ask for all of them in one topic?
18:45:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:07 <andersson007___> samccann: should this go to Bullhorn?
18:45:30 <gotmax23> #topic Commonly used Ansible CLI flags
18:45:37 <samccann> yeah good point, I'll do that next. But first want to know if opening like 6 topics (one per command) would be annoying or okay
18:45:37 <gotmax23> #link https://github.com/ansible-community/community-topics/issues/232
18:45:41 <andersson007___> if those issues are not in community-topics, should be ok
18:45:56 <samccann> it's asking for feedback using community-topics, yes
18:46:22 * gotmax23 notes that the community forum will be a great venue for this kind of thing
18:46:23 <samccann> I can switch the current 'ansible-doc' command one to a genereic question and list all the commands we want help with
18:46:40 <samccann> gotmax23: that it will!!
18:46:48 <gotmax23> Okay. I agree that having 6 issues in community-topics may be disruptive.
18:46:55 <gotmax23> :)
18:47:07 <samccann> ok cool that's all I wanted to know. I'll edit this one and ask for all the commands thanks!
18:47:18 <gotmax23> Cool thanks!
18:47:45 <gotmax23> #topic Open Floor
18:50:00 <Leo[m]> I was going to write up something to share later, but might as well post it here and read your thoughts now.
18:50:24 * gotmax23 listens
18:50:39 <Leo[m]> Question about the naming of "Ansible Community Working Group", something that came up during Summit while discussing the WGs
18:50:52 <Leo[m]> Summit / Fest / Community Day
18:51:18 * andersson007___ listening carefully
18:51:20 <Leo[m]> Quite a few thought it was an umbrella WG, like for "all things community" and not collection centric
18:51:42 <Leo[m]> or community package centric
18:52:14 <gotmax23> Yeah, I'm not sure we have a formal definition anywhere
18:52:39 <gotmax23> I'd definitely create a community-topic about this
18:52:42 <samccann> yeah I've heard that confusion before
18:52:53 <Leo[m]> maybe the branding is not clear , and the list here[1] https://docs.ansible.com/ansible/devel/community/communication.html#working-groups
18:52:56 <Leo[m]> doesn't provide a description
18:53:23 <Leo[m]> so I was thinking if we could think a bit on that. I could draft something for discussion in Github later
18:53:27 <gotmax23> Oh, I guess there's a description here: https://github.com/ansible/community/wiki/Community
18:54:08 <andersson007___> looks stale
18:54:13 <Leo[m]> gotmax23: yeah, which when we look at the meetings and topics, doesn't seem to be so accurate
18:54:26 <gotmax23> > Quite a few thought it was an umbrella WG, like for "all things community" and not collection centric
18:54:26 <gotmax23> So it seems the former is inline with our formal definitions
18:54:40 <gotmax23> Yes, I don't think that encompasses everything we do
18:54:54 <Leo[m]> we have more or less the same issue with the Steering committee
18:55:07 <Leo[m]> in regards to perception I mean
18:55:42 <andersson007___> a topic would be good
18:55:43 <gotmax23> FWICT, our main thing is overseeing the ansible community package
18:56:32 <gotmax23> Yeah. I have another meeting right at the top of the hour, so I don't want to start too long of a discussion here :).
18:56:38 <Leo[m]> Ok, just wanted to throw it out here to see if someone else had that conversation, I see samccann at least had, and the matter seems valid enough to do a topic on it, so I can get back to that later
18:56:55 <Leo[m]> ty for the space ;)
18:57:24 <gotmax23> Thanks for bringing it up!
18:57:54 <andersson007___> btw it's not only about collections and the package:) how about topics by Greg?:)
18:58:14 <gotmax23> That's very true :)
18:58:16 <andersson007___> like the forum, the new community site, etc.
18:58:34 <gotmax23> Sometimes high level community decisions are brought to us
18:58:48 <andersson007___> but ok, lets think and discuss it async in the topic
18:58:52 <andersson007___> yes
18:59:25 <gotmax23> We're nearing the top of the hour, so speak now or forever hold your peace :)
18:59:35 <Leo[m]> until next week that is :D
18:59:43 <gotmax23> Indeed
18:59:50 <andersson007___> :)
18:59:55 <samccann> heh
19:00:06 <gotmax23> #endmeeting