18:00:03 <felixfontein> #startmeeting Ansible Community Meeting
18:00:03 <zodbot> Meeting started Wed Mar 29 18:00:03 2023 UTC.
18:00:03 <zodbot> This meeting is logged and archived in a public location.
18:00:03 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:03 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:03 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/679
18:00:04 <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:10 <felixfontein> now!
18:00:12 <felixfontein> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself.
18:00:20 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/679 / Topics: https://github.com/ansible-community/community-topics
18:00:24 <felixfontein> #topic Updates
18:00:44 <gotmax23> .hi
18:00:44 <acozine> o/
18:00:44 <zodbot> gotmax23: gotmax23 'Maxwell G' <maxwell@gtmx.me>
18:00:48 <pino|work> o/
18:00:52 <andersson007___> o/
18:00:54 <anwesha[m]> Hello hello
18:00:57 <cybette_> o/
18:01:30 <felixfontein> #chair gotmax23 acozine pino|work andersson007___ anwesha[m] cybette_
18:01:30 <zodbot> Current chairs: acozine andersson007___ anwesha[m] cybette_ felixfontein gotmax23 pino|work
18:01:59 <felixfontein> #info There's an active vote on: "Static site generator for the Ansible community web presence" ending tomorrow (https://github.com/ansible-community/community-topics/issues/210)
18:02:30 <felixfontein> #info A new collection microsoft.ad will be included in Ansible if nobody objects until tomorrow (https://github.com/ansible-community/community-topics/issues/217)
18:03:08 <felixfontein> #info Ansible 7.4.0 has been released yesterday (https://groups.google.com/g/ansible-project/c/ILuT3R7XGQ4)
18:03:35 <felixfontein> #info ansible-core 2.14.4 has been released on Monday (https://groups.google.com/g/ansible-project/c/Hgx-Mwqamgw)
18:03:47 <felixfontein> any other news folks want to share? :)
18:03:54 <Leo[m]> hi all! baby duties  , hope to be jumping in and out
18:04:15 <felixfontein> #chair Leo[m]
18:04:15 <zodbot> Current chairs: Leo[m] acozine andersson007___ anwesha[m] cybette_ felixfontein gotmax23 pino|work
18:04:28 <maxamillion> .hello2
18:04:29 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
18:04:35 <gotmax23> When we move on to topics, I'd like to discuss https://github.com/ansible-community/community-topics/issues/218
18:05:06 <felixfontein> https://github.com/ansible-community/community-topics/issues/212 is also tagged for today; are there other/more things folks want to discuss today?
18:05:41 <felixfontein> #info The antsibull* projects are changing from poetry-core to hatchling as a build system
18:05:55 <felixfontein> shouldn't affect any user, but everyone contributing to these projects :)
18:06:14 <gotmax23> 🎉
18:06:42 <gotmax23> So far, we've only moved antsibull and antsibull-changelog, but I believe we're also going to do antsibull-core and antsibull-docs at some point?
18:07:26 <felixfontein> yes, probably very soon
18:07:34 <felixfontein> from my POV
18:08:18 <felixfontein> ok, if there are no more topic suggestions, let's start with the first
18:08:23 <felixfontein> #topic https://github.com/ansible-community/community-topics/issues/218
18:08:34 <felixfontein> #undo
18:08:34 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f86c14f74e0>
18:08:42 <gotmax23> Also, should we do a release of antsibull and/or antsibull-changelog this week?
18:08:44 <felixfontein> #topic Enforce collection tagging policy as a release blocker
18:08:50 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/218
18:09:04 <felixfontein> gotmax23: I was trying to release antsibull-changelog earlier today, but I failed - see the PRs ;)
18:09:31 <gotmax23> Ah, okay. Let's talk about it after the meeting or during Open Floor
18:09:35 <felixfontein> :+1:
18:09:44 <felixfontein> do you want to say something about #218?
18:09:51 <gotmax23> So I wrote a decent summary in the topic about #218, but basically:
18:10:16 <gotmax23> We require that collections tag new releases in their respective Github repositories and not just release them to Galaxy
18:10:23 * andersson007___ listening carefully
18:10:40 <gotmax23> I added tooling to antsibull to verify this, but running it is not enforced
18:10:45 <gotmax23> I'd like it to be a release blocker
18:11:23 <felixfontein> in which sense should it block? i.e. should we use the last version of that collection that works, or delay the release until it is fixed?
18:11:33 <gotmax23> In this proposal, all collections (except the ones that we've started removal for) will be checked by the release playbook to ensure that the latest release is tagged
18:11:48 <gotmax23> If the latest release is not tagged, the collection will be pinned to the previous tagged release
18:12:09 <andersson007___> if they don't fix, will we not include it in release?
18:12:12 <gotmax23> This will also be tested in ansible-build-data CI, so hopefully we can catch it early
18:12:25 <felixfontein> andersson007___: it will, but an older version
18:12:30 <andersson007___> ah, ok
18:12:37 <felixfontein> (basically the last one we had before)
18:12:37 <gotmax23> In addition to pinning to the previous release, we'll file issues against the collections
18:12:48 <gotmax23> Exactly
18:13:15 <andersson007___> looks good to me on the first sight
18:13:22 <felixfontein> the main downside here is that this is more work for the folks doing the releases
18:13:39 <felixfontein> (in particular the manually pinning versions part, which makes automation harder)
18:13:54 <andersson007___> fair as well
18:14:23 <felixfontein> which is also why anwesha[m] and chadams[m] are tagged in that topic :)
18:14:24 <gotmax23> Right
18:14:34 <andersson007___> but if they agree:) why not
18:14:45 <felixfontein> (and the whole https://github.com/orgs/ansible-community/teams/release-managers team, which I first saw in that topic :) )
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:21 <felixfontein> so far we already have one case where manual intervention is needed (next to Galaxy timeouts): when there is an dependency violation
18:15:31 <felixfontein> s/an/a/
18:15:53 <felixfontein> so it is not that this is the very first thing that makes automation harder :)
18:16:24 <samccann> o/  sorry for strolling in late
18:16:35 <felixfontein> #chair samccann
18:16:35 <zodbot> Current chairs: Leo[m] acozine andersson007___ anwesha[m] cybette_ felixfontein gotmax23 pino|work samccann
18:17:15 <gotmax23> Yeah, the way I approached this issue was similar to how we implemented the policy for dep violations. First, we made this informational and added tooling to verify that the policy is being followed. Then, we started reaching out to noncompliant collections, and finally, we enforced it as a blocker.
18:18:19 <gotmax23> https://paste.sr.ht/~gotmax23/7c82fb4ca7cd5d12971a6bc34b9ac06630f0ff32
18:19:04 <felixfontein> are these all up for removal?
18:19:10 <andersson007___> i think as the suggested solution implies real consequences we shouldn't expect a lot of such collections and fast resolve (or kicking them out)
18:19:13 <gotmax23> That's the output from the new validate-tags-file subcommand. These collections that are already part of the release will not block.
18:19:32 <gotmax23> All except inspur.sm
18:19:35 <gotmax23> See https://github.com/ISIB-Group/inspur.sm/issues/57
18:20:45 <anwesha[m]> I am +1 to the idea but I would love see proper examples of manually pinning the version to the collections.
18:21:01 <gotmax23> Yeah, I will write up documentation
18:21:28 <gotmax23> And that reminds me, do we have a central source of documentation for the ansible community package release process?
18:21:39 <felixfontein> chadams[m] just wrote something in the topic: https://github.com/ansible-community/community-topics/issues/218#issuecomment-1489087683
18:21:50 <felixfontein> good question :)
18:22:02 <gotmax23> Yeah, I agree with them
18:22:30 <gotmax23> We have CI in ansible-build-data, but I'm not sure if anyone monitors that
18:22:51 <felixfontein> I kind of do since I think I get mails when it fails
18:23:03 <felixfontein> or at least I think I get them
18:23:35 <anwesha[m]> gotmax23: Not that I know of  which is available to the community
18:23:54 <felixfontein> it hasn't failed for a long time, but I'm pretty sure I got emails when it failed spontaneously in the past
18:24:17 <andersson007___> generally i support the idea but the final words should imo be by release folks
18:24:48 <andersson007___> not the final but next:) final by SC:)
18:25:22 <felixfontein> yeah, both SC and RMs should agree on this :)
18:25:37 <andersson007___> the more  fast and real rule enforcement the better:D
18:26:04 <acozine> could we do a test of the build-data failure?
18:26:10 <acozine> add something that we know won't build, and see what happens on a test run?
18:26:19 * andersson007___ wanted to write "physical" first
18:26:21 <gotmax23> #action gotmax23 Update the release playbook to run `antsibull validate-tags`. Make the command fail the playbook on antsibull >= 7.X.0 (where X is the next version) and make it informational otherwise
18:26:57 <gotmax23> #action gotmax23 Add a list of collections to ignore errors for in ansible-build-data
18:27:02 <gotmax23> #action gotmax23 document the process
18:27:09 <gotmax23> How's that :)?
18:27:38 <mattclay> felixfontein: I just noticed that the hetzner.hcloud collection, which is included in the ansible package, isn't currently passing sanity tests. In fact, it looks like CI hasn't been passing on commits for over 2 years.
18:27:45 <gotmax23> (Of course, I'd wait for approval and/or submit draft PRS, but that's my current plan)
18:27:48 <felixfontein> gotmax23: I think the first action needs an SC vote first
18:28:10 <gotmax23> #action gotmax23 submit draft PRs and wait for SC approval
18:28:17 <felixfontein> mattclay: thanks for reporting! I'll take a look
18:28:58 <felixfontein> mattclay: I think it is still active maintained (or at least it was in parts of the last two years)
18:30:00 <felixfontein> mattclay: it seems that the devel sanity checks fail, while the stable-2.14/2.13/2.12 sanity tests succeed - but I'll take a closer look
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:31:25 <felixfontein> ok, should we continue with https://github.com/ansible-community/community-topics/issues/212 ? or does anyone have more comments for #218?
18:33:08 <gotmax23> I'm fine to continue :)
18:33:46 <felixfontein> #topic community.grafana and grafana.grafana merger CLA requirement
18:33:51 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/212
18:34:47 <gotmax23> I'm waiting on an answer to my question about relicensing
18:34:49 <felixfontein> there have been discussions of merging community.grafana into grafana.grafana, which is currently blocked because grafana.grafana has a CLA (contributor license agreement) requirement
18:35:13 <felixfontein> gotmax23: why do you think that the CLA gives relicensing right?
18:35:15 <felixfontein> +s
18:37:39 <gotmax23> IANAL, but, it gives them a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works. As I read it, this gives them the write to distribute the work under whatever terms they want without the Corresponding Source.
18:37:54 <acozine> I'm reading the issues now, do we know why the Grafana folks want to impose a CLA? Or how strongly they feel about it?
18:38:27 <acozine> I agree that a CLA is a barrier to contributing. Maybe if we understood more about why they want it, we could find an alternative solution?
18:39:00 <gotmax23> I'm not sure. They didn't say much, but they made clear that it's a strong requirement for software in the grafana org.
18:39:10 <felixfontein> gotmax23: I understood that differently, but IANAL...
18:39:21 <gotmax23> There was talk about moving it into the ansible-collections org. I believe they initially expressed interest, but nobody's brought it up again.
18:39:36 <gotmax23> * ansible-collections org without the CLA requirement. I
18:40:22 <andersson007___> felixfontein:
18:40:40 <andersson007___> i see your question now, IANAL too:)
18:40:52 <andersson007___> used to be a long ago:)
18:41:09 <andersson007___> fortunately now i'm not:)
18:41:21 <felixfontein> andersson007___: I know, but I guess you have more experience with reading legalese than most of us ;)
18:41:57 <andersson007___> felixfontein: probably yes but i don't feel confident to make any legal judgments:)
18:42:08 <felixfontein> that's fair :)
18:42:18 <gotmax23> Even if the terms aren't super sweeping, I still think it presents an undue barrier to contributions and gives grafana more control than the rest.
18:42:58 <andersson007___> we could introduce a requirement
18:43:21 <andersson007___> not to force to sign any stuff to be allowed to contribute
18:43:30 <gotmax23> other than the DCO, I'd say
18:43:40 <andersson007___> what is it?
18:44:08 <pino|work> https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin
18:44:18 <pino|work> https://developercertificate.org/
18:44:36 <andersson007___> thanks for the links!
18:44:50 <gotmax23> It's the Developer Certificate of Origin that's used by some projects such as the Linux kernel. It's basically a formal agreement that you have the right to submit the changes you're submitting under the project's license.
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:02 <andersson007___> we could 1. create a PR against the collection requirements 2. vote
18:45:31 <felixfontein> is it something like 'By using git commit -s you sign the DCO'?
18:45:33 <gotmax23> Usually, people agree to it by using git commit --signoff (i.e. adding the Signed-off-by trailers), so it's pretty unintrusive
18:45:39 * felixfontein remembers having seen something like that before
18:45:52 <andersson007___> any legal barriers for contributors don't sound good to me
18:46:20 <pino|work> DCO is generally accepted in upstream communities, and even Red Hat legal approves it: https://www.redhat.com/en/resources/open-source-participation-guidelines-overview
18:46:33 <felixfontein> DCO sounds more acceptable than a CLA
18:46:55 <andersson007___> ok how about what i wrote but only about CLA?
18:47:43 <andersson007___> if someone submits a [WIP] PR against the collection requirements and open a vote after some discussion about wording, it'd be imo good
18:47:48 <gotmax23> Yes. Signed-off-by can have different meanings depending on the project, but many projects use it as a way for contributors to agree to the DCO
18:48:02 <gotmax23> pino|work: Right, I was going to point that out :)
18:49:24 <gotmax23> andersson007___: I'm fine with adding a guideline that says collections SHOULD NOT require contributors to sign CLAs
18:49:26 <felixfontein> andersson007___: I would probably propose it first more informally to see for a couple of weeks whether there's feedback to it, but I generally like that idea
18:49:54 <felixfontein> gotmax23: SHOULD NOT means that they can do anyway
18:50:01 <gotmax23> grafana.grafana that's part of the ansible package already has a CLA, so it should be a SHOULD NOT unless we want to make it retroactive
18:50:13 <gotmax23> Or we can make it MUST NOT and handle that collection seperately
18:50:43 <gotmax23> * grafana.grafana that's part of the ansible package already has a CLA, so it should be a SHOULD NOT unless we make it only apply to new collections
18:50:47 <felixfontein> in the past we had exceptions for all kind of things for collections added before the rules, so I think MUST NOT is viable
18:50:54 <anwesha[m]> <gotmax23> "I'm not sure. They didn't say..." <- According to my understanding they can use, reproduce and/or prepare  derivative work re license it and then distribute it.
18:51:14 <gotmax23> felixfontein: Ack
18:51:43 <andersson007___> I'm ok with MUST NOT also
18:52:35 <felixfontein> I did ask in https://github.com/ansible-community/community-topics/issues/212 whether they are ok with moving the collection go gh.com/ansible-collections and dropping the CLA requirement, or only requiring a DCO
18:52:56 <Zhenech> can we then also make it clearer which rules apply to the "ansible-collections" GH org, which to the Ansible "all in one" package inclusion?
18:52:56 <andersson007___> +1 let's see
18:53:10 <felixfontein> I think we should both try to convince them to stop requiring a CLA, and at the same time prevent new collections from requiruing that
18:53:34 <acozine> agreed
18:53:37 <gotmax23> +1
18:53:38 <felixfontein> Zhenech: that would indeed be a good thing :) historically it has been a bit ... mixed
18:53:53 <felixfontein> it's probably best to split it up into two separate documents
18:54:21 <andersson007___> i think we should decide anyway something
18:54:32 <andersson007___> even if they agree not to require it
18:54:42 <andersson007___> for future cases while we are here
18:54:43 <Zhenech> felixfontein, exactly (he said with a long-grand-fathered collection, that is not in that org)
18:54:53 <felixfontein> :)
18:55:22 <felixfontein> should we create a new discussion issue for the general requirement, or should we recycle the grafana discussion?
18:55:33 <gotmax23> yeah, definetely
18:55:36 <gotmax23> Should we move to open floor or does anyone have any last words?
18:55:48 <gotmax23> anwesha[m]: Thanks for answering this anwesha !
18:55:51 <samccann> I have  a quick floor mention
18:56:07 <felixfontein> that was an either-or question, answering with 'yes' isn't helping :D
18:56:29 <andersson007___> :)
18:56:44 <felixfontein> ok, we can figure that out later, let's go to open floor
18:56:46 <felixfontein> #topic open floor
18:56:51 <felixfontein> the trapdoor has opened!
18:56:57 <samccann> haha
18:57:10 <gotmax23> That "yeah, definetely" was to andersson007___'s comment
18:57:10 <gotmax23> The bridge mixed them up
18:57:26 <samccann> a quick metion - we are looking for final feedback on https://ansible.github.io/jinja-docsite/ (the new docsite pages) before we go live with these next Tuesday
18:57:32 <samccann> s/metion/mention/
18:57:52 <felixfontein> going live means publishing it on docs.ansible.com, right?
18:57:52 <cybette_> fwiw, I think we should create a new discussion for the general requirement, to keep things separate (sorry for late response)
18:57:54 <samccann> they will replace the first few pages you see today on docs.ansible.com
18:57:56 <samccann> yep
18:58:07 <andersson007___> samccann: i'm going to submit a bunch of PRs tomorrow
18:58:10 <samccann> there will be a toggle to go back to the old pages 'for a time'
18:58:27 <samccann> cool
18:58:35 <andersson007___> i think it'd be good to ask for feedback after that:) it'll be an overhaul
18:58:46 <felixfontein> cybette_: sounds good to me!
18:58:57 <samccann> ok now I dunno if you are joking or not  andersson007___
18:58:58 <felixfontein> does anyone want to create a new discussion about forbidding CLA?
18:59:00 <gotmax23> felixfontein: I think we should create a separate issue about the general requirement
18:59:00 <felixfontein> +s
18:59:02 <samccann> just how dry is your humor
18:59:19 <andersson007___> samccann: not joking, really:)
18:59:23 <felixfontein> :D
18:59:36 <andersson007___> gotmax23: +1
18:59:44 <samccann> hehe well you can let don know that tomorrow ;-) We've already sent out the existing pages for broader review
18:59:58 <samccann> ooph need to run for another meeting. catch y'all later taters!
19:00:15 <felixfontein> it's time for closing this anyway
19:00:18 <felixfontein> thanks everyone :)
19:00:20 <felixfontein> #endmeeting