18:00:11 <felixfontein> #startmeeting Ansible Community Meeting
18:00:11 <zodbot> Meeting started Wed Apr 26 18:00:11 2023 UTC.
18:00:11 <zodbot> This meeting is logged and archived in a public location.
18:00:11 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:11 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:11 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/679
18:00:15 <felixfontein> 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, oranod, resmo, russoz, samccann, thaumos, wbentley15[m], zbr: The Ansible community meeting is starting
18:00:22 <felixfontein> now!
18:00:24 <felixfontein> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself.
18:00:27 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/679 / Topics: https://github.com/ansible-community/community-topics
18:00:30 <felixfontein> #topic Updates
18:00:33 <felixfontein> #info Ansible 7.5.0 has been released (https://groups.google.com/g/ansible-devel/c/aPTJUebywAM)
18:00:37 <felixfontein> #info Ansible 8.0.0a2 has been released (https://groups.google.com/g/ansible-devel/c/g4I0JblfSnY)
18:00:56 <mariolenz[m]> o/
18:00:57 <anwesha[m]> Hello hello
18:01:21 <felixfontein> #chair mariolenz[m] anwesha[m]
18:01:21 <zodbot> Current chairs: anwesha[m] felixfontein mariolenz[m]
18:01:28 <felixfontein> thanks a lot for doing the releases anwesha[m]!
18:01:29 <cybette_> o/
18:01:35 <felixfontein> #chair cybette_
18:01:35 <zodbot> Current chairs: anwesha[m] cybette_ felixfontein mariolenz[m]
18:02:27 <mariolenz[m]> I agree, thanks anwesha !
18:02:55 <anwesha[m]> Rather sorry for the delay :)
18:03:11 <anwesha[m]> Europe is not treating me well.
18:03:23 <samccann> o/
18:03:50 <felixfontein> #chair samccann
18:03:50 <zodbot> Current chairs: anwesha[m] cybette_ felixfontein mariolenz[m] samccann
18:04:06 <gotmax23> .hi
18:04:07 <zodbot> gotmax23: gotmax23 'Maxwell G' <maxwell@gtmx.me>
18:04:17 <felixfontein> #chair gotmax23
18:04:17 <zodbot> Current chairs: anwesha[m] cybette_ felixfontein gotmax23 mariolenz[m] samccann
18:04:30 <gotmax23> hi y'all!
18:04:33 <felixfontein> so, what do you folks want to discuss today?
18:06:19 * gotmax23 doesn't see anything new
18:06:31 <felixfontein> there's a lot of old stuff ;)
18:06:40 <samccann> :-)
18:07:15 <gotmax23> I keep pushing off https://github.com/ansible-community/community-topics/issues/218...
18:08:02 <felixfontein> one question is whether we want to enforce this for 8.0.0 already
18:08:39 <gotmax23> I would like to do that
18:09:17 <gotmax23> I think I have a branch in my local antsibull checkout where I started modifying the release playbook and then got busy with other things
18:09:44 <samccann> can we enforce a new policy at alpha?
18:10:11 <gotmax23> The policy itself is not new
18:10:21 <gotmax23> We've had it for months
18:10:25 <gotmax23> This is about actually enforcing it
18:10:37 <acozine> o/
18:10:37 <oranod> hello all
18:10:39 <oranod> o/
18:10:51 <gotmax23> But I suppose the way we enforce it can also be considered a policy in itself :)
18:10:55 <anwesha[m]> gotmax23: have you written down any suggested process for the authors and also for the release manager.
18:11:00 <felixfontein> I think if we want to enforce it, we should enforce it as early as possible, i.e. for the next alpha or at least for the beta release (with collection feature freeze)
18:11:02 <anwesha[m]> s/./?/
18:11:16 <gotmax23> yeah, that's another next step
18:11:34 <felixfontein> anwesha[m]: for collection authors nothing should change, assuming they have been doing it correctly so far
18:12:01 <acozine> agreed that early enforcement is good, gives people a chance to do the right thing before there are consequences
18:12:03 <samccann> do we know how many collections may not be dooing this yet?
18:12:48 <felixfontein> we did have some in the past
18:12:50 <gotmax23> Basically, if a new collection version is released that's not properly tagged, the release manager would have to pin its version to `< NEW_UNTAGGED_RELEASE_HERE` in the ansible-8.build file.
18:12:51 <cybette_> #chair acozine Don Naro
18:12:51 <zodbot> Current chairs: Don Naro acozine anwesha[m] cybette_ felixfontein gotmax23 mariolenz[m] samccann
18:13:09 <gotmax23> Then someone would have to file an issue against the collection's repository
18:13:33 <gotmax23> samccann: Yes, we have tooling for this. Let me run it quickly and report the results.
18:13:41 <anwesha[m]> What is the way to find out these collection?
18:13:41 * gotmax23 brb
18:14:06 <felixfontein> it looks to me (from ansible-8.0.0a2-tags.yaml) that all entries have a tag
18:14:35 <gotmax23> $ antsibull-build validate-tags-file ansible-8.0.0a2-tags.yaml
18:14:35 <gotmax23> cisco.nso 1.0.3 is not tagged in https://github.com/CiscoDevNet/ansible-nso
18:14:35 <gotmax23> hpe.nimble 1.1.4 is not tagged in https://github.com/hpe-storage/nimble-ansible-modules
18:14:49 <felixfontein> ah
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:06 <samccann> ah so if it's only two or so, then definitely +1 for enforcing it and annoucing that enforcement asap
18:15:10 <felixfontein> I thought it would be `tag: `, not `tag: null`... yeah, these two are missing
18:15:12 <AndreasadsScherb> makes it easy to enforce this going forward.
18:15:18 <mariolenz[m]> Only those two?
18:15:37 <gotmax23> We removed the other ones in ansible 8 IIRC
18:16:00 <gotmax23> $ antsibull-build validate-tags-file ansible-7.5.0-tags.yaml
18:16:00 <gotmax23> cisco.nso 1.0.3 is not tagged in https://github.com/CiscoDevNet/ansible-nso
18:16:00 <gotmax23> hpe.nimble 1.1.4 is not tagged in https://github.com/hpe-storage/nimble-ansible-modules
18:16:00 <gotmax23> mellanox.onyx 1.0.0 is not tagged in https://github.com/ansible-collections/mellanox.onyx
18:16:21 * gotmax23 apologizes to the IRC people for not using a pastebin. hopefully, this shows up properly...
18:16:32 <felixfontein> hmm, hpe.nimble hasn't been tagged since November: https://github.com/hpe-storage/nimble-ansible-modules/issues/59
18:17:08 <felixfontein> nso as well: https://github.com/CiscoDevNet/ansible-nso/issues/11
18:17:40 <gotmax23> IIRC hpe.nimble properly tagged every release besides the latest one
18:17:55 <gotmax23> I think we already vote to remove cisco.nso from Ansible 10
18:18:08 <gotmax23> s/vote/voted/
18:18:31 <acozine> wow, that's not nearly as many as I'd feared
18:18:35 <gotmax23> I think it's time to start the removal process for hpe.nimble
18:18:38 <samccann> so what's the penalty for not tagging in Ansible 8?
18:18:54 <mariolenz[m]> cisco.nso will be remove, anyway: https://github.com/ansible-community/ansible-build-data/issues/190
18:19:00 <felixfontein> it's quite annoying if we start enforcing this with three collections not doing it, which means that every Ansible 8 release will need extra manual work, and that Ansible 8 will use older verisons of these collections than Ansible 7
18:19:11 <gotmax23> Effectively, we won't include new collection releases unless they're properly tagged
18:19:18 <samccann> ah gotcha
18:19:36 <gotmax23> felixfontein: We'll ignore collections that are already untagged
18:19:45 <felixfontein> gotmax23: ah ok
18:19:50 <gotmax23> So it'll only error for new violations
18:19:55 <felixfontein> ah right, there was some ignore functionality I forgot about :)
18:20:15 <samccann> at what point does it error? When we start Ansible 9 alpha?
18:20:20 <samccann> (for new violations)
18:21:04 <anwesha[m]> I have to dig into Antsibull to figure the steps how to do it manually during the release process.
18:21:13 <felixfontein> it does error when RM tries to build a new release that would include a collection that isn't tagged (and not on the ignore list)
18:21:27 <felixfontein> when that starts failing is basically up to us - when we want to start enforcing this
18:21:35 <samccann> I guess I'm asking - do we not know a collection is violating the tagging until we build the first Ansible alpha? And then what do we do if say community.general doesn't tag... we can't remove it, right? So we're back to that manual override for every release?
18:22:11 <anwesha[m]> Maybe after I create the ansible-build-data updates (before creating creating the pull request)!!
18:22:20 <gotmax23> it shouldn't be a manual override for every release.
18:22:30 <samccann> ok phew!
18:22:42 <gotmax23> For example, let's say the latest community.general release isn't tagged
18:22:47 <felixfontein> I think we can half-way automate the manual override by adjusting the version range in the ansible-X.build file - which means that collections have to manually report they fixed it and then someone has to undo the range restriction
18:22:56 <gotmax23> (That would never actually happen, but ya know :)
18:23:04 <samccann> heheh
18:23:07 <gotmax23> https://github.com/ansible-community/ansible-build-data/blob/59318d1696740b3501bbcd9e2a569bf9281c8237/8/ansible-8.build#L36 would be changed
18:23:14 <felixfontein> so work is usually only needed at two points in time, when the problem is noticed and when its fixed, but not for every release inbetween
18:23:28 <samccann> cool
18:23:31 <gotmax23> `<7.0.0` would be changed to `<=` the latest tagged release
18:23:57 <gotmax23> felixfontein: exactly
18:24:01 <felixfontein> yeah, it cannot happen for all community.* collections in gh.com/ansible-collections/ since they only way to get them released is to tag releases ;) though you could delete the tag afterwards....
18:24:42 <gotmax23> in that case, the release playbook would fail
18:24:51 <felixfontein> I would push the work of undoing the range restriction to the authors of the collection who broke it, by asking them to create a PR to remove it once they fixed the problem
18:25:01 <gotmax23> the RM would have to adjust the version constraint in ansible-build-data, commit it, and rerun the playbook
18:27:47 <felixfontein> my main question is: where should we document this?
18:27:59 <gotmax23> yeah, that was also my question in the ticket
18:28:07 <felixfontein> we could do: 1. docs/ folder in https://github.com/ansible-community/ansible-build-data/ - 2. wiki in https://github.com/ansible-community/ansible-build-data/ - 3. ???
18:28:41 <felixfontein> (I don't think we should just put it into the README, that one is already somewhat large, it's better to start splitting this up into multiple pages IMO)
18:29:23 <anwesha[m]> For example if https://github.com/ansible-community/ansible-build-data/pull/220/files#diff-21e8b955a63c0833bbcaae86a1900ba011ca60a6d1d17bac9f3adca2501c03fdR36 would have been <= 7.0.0 it then the build process would have failed? Isn't it?
18:29:50 <gotmax23> felixfontein: I want to have the whole release process documented at some point, but for now I can add a separate page in ansible-build-data.
18:29:51 <gotmax23> s/page/file/
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:07 <samccann> +1 for starting a docs/ folder. That way we can eventually publish to RTD if that helps y'all
18:30:23 <felixfontein> anwesha[m]: what place would you prefer for (public) documentation?
18:30:50 <gotmax23> I'd prefer to write these in markdown :)
18:30:51 <felixfontein> I think inside the repo is somewhat better than using the wiki since it's easier to track changes
18:30:59 <gotmax23> +1
18:31:15 <felixfontein> gotmax23: no docx? :P
18:31:38 <anwesha[m]> felixfontein: We can put in git itself, maybe in a docs folder.
18:31:47 <gotmax23> SGTM
18:31:51 <felixfontein> :+1:
18:31:56 <felixfontein> then docs/ it is :)
18:32:07 <gotmax23> how do we want to handle voting for this?
18:32:08 <samccann> \o/
18:32:12 <gotmax23> do we need more time for discussion?
18:32:21 <felixfontein> with markdown files; I don't think we need rst or something more complex
18:32:26 <gotmax23> should we target this for 8 or 9?
18:32:39 <felixfontein> gotmax23: you mean for the docs/ folder, or for tag validation?
18:32:48 <gotmax23> tag validation
18:33:05 <felixfontein> I personally would start with the next 8.0.0 pre-release
18:33:21 <felixfontein> and not vote, since we already voted that we want to require this
18:33:30 <anwesha[m]> I would prefer 9.
18:33:41 <anwesha[m]> :)
18:33:44 <acozine> anwesha: what's your thinking?
18:34:33 <acozine> I don't have much of an opinion either way (8 or 9) but am curious why you would prefer 9
18:34:39 <felixfontein> we can also start during the 8 release cycle if at the point we want to start all collections are still tagged (except the known exceptions)
18:35:20 <gotmax23> yeah, this wouldn't create any new immediate work for the RM. it will only break if we find a new validation.
18:35:25 <gotmax23> s/validation/violation/
18:35:28 <felixfontein> keeping it separate from the major releases might make this easier for anwesha[m] since there's more time to prepare and less happening at the same time
18:35:59 <samccann> as in 'after Ansible 8.0.0, all collections must be tagged'
18:36:19 <felixfontein> samccann: they already have to be tagged now, it's just not really enforced :)
18:36:21 <anwesha[m]> We can enable the policy for the rest of the 8.0.0 release too, but also what felixfontein said.
18:37:27 <samccann> heh ok so violators will be held at a prior, tagged release
18:37:41 <gotmax23> exactly
18:38:11 <gotmax23> but only new ones. I'm not going to downgrade existing collections.
18:38:15 <felixfontein> right now that's our default solution to all kind of problems :)
18:38:35 <mariolenz[m]> Sounds like a good plan :-)
18:38:37 <felixfontein> (which I think is fine, since at least it's something that works)
18:39:49 <gotmax23> so should I create the PRs and then merge them once they get a couple acks or start a formal vote?
18:40:52 <felixfontein> if merging them means that it will be active from the next release after the next antsibull release, we should probably wait with merging them until 8.0.0 is out and 7.x.y is EOL
18:41:05 <felixfontein> I don't think we need a vote, but I don't mind voting on it either
18:41:29 <gotmax23> I would add a constraint to only fail for versions greater than 8.0.0a3
18:41:41 <gotmax23> Otherwise, it would just print a warning
18:42:59 <felixfontein> I would let anwesha[m] decide from which version on this should be active
18:43:12 <gotmax23> definetely!
18:43:18 <gotmax23> * definitely!
18:43:49 <acozine> I think we've voted on this more than once already
18:43:58 <acozine> time to act!
18:44:09 <anwesha[m]> Let's do this from 9 onwards (alpha) it give more time.
18:44:44 <anwesha[m]> * more time for the policy itself.
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:33 <felixfontein> fine for me. we'll definitely already pester collections who don't do it before that by creating issues :)
18:45:38 <acozine> Starting with Ansbile 9 alpha sounds good
18:45:44 <samccann> +1
18:46:52 <gotmax23> alright
18:47:18 <felixfontein> we should definitely make sure to have a lot more documentation (on all aspects of the release process) until then
18:47:26 <gotmax23> for now, is it okay if I add the code and docs but have it print warnings instead of errors?
18:47:28 <gotmax23> felixfontein: +1
18:48:00 <gotmax23> If I can help with documenting the process in any way, let me know.
18:48:01 <felixfontein> I think printing warnings is good, that makes it easier to see when something goes wrong
18:48:19 <anwesha[m]> felixfontein: Yes please.
18:49:10 <felixfontein> I started by creating an issue that we should do this ;) https://github.com/ansible-community/ansible-build-data/issues/221
18:49:31 <samccann> should all documentation about the release be in that repo?
18:49:41 <gotmax23> #action gotmax23 to actually follow through and submit antsibull and ansible-build-data PRs to implement the suggested policy for ansible 9.0.0a1 and beyond
18:49:49 <gotmax23> samccann: I think so
18:49:53 <samccann> cool
18:50:07 <felixfontein> samccann: I think that would be good, that makes it easier to find everything
18:51:11 <gotmax23> open floor?
18:51:44 <felixfontein> #topic open floor
18:51:45 <felixfontein> yes!
18:56:27 <acozine> quiet day!
18:56:31 <felixfontein> indeed :)
18:59:43 <felixfontein> ok, I guess we can close the meeting then :)
18:59:56 <felixfontein> #endmeeting