19:02:25 <felixfontein> #startmeeting Ansible Community Meeting
19:02:25 <zodbot> Meeting started Wed Dec  9 19:02:25 2020 UTC.
19:02:25 <zodbot> This meeting is logged and archived in a public location.
19:02:25 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:02:25 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:02:30 <felixfontein> andersson007_ dericcrago gundalow samccann abadger1999 agaffney tadeboro russoz geerlingguy briantist samccann jillr dmsimard cybette acozine lmodemal cyberpear aminvakil gwmngilfen akasurde baptistemm resmo Goneri maxamillion: ping!
19:02:33 * gundalow waves
19:02:36 <jillr> o/
19:02:37 * dericcrago waves
19:02:39 <felixfontein> dmsimard: thanks for the reminder, I already looked it up ;)
19:02:42 <dmsimard> ah felixfontein beat me to it :p
19:02:42 <gundalow> #topic Updates
19:02:44 <cybette> o7
19:02:50 <felixfontein> #chair gundalow jillr dericcrago dmsimard cybette
19:02:50 <zodbot> Current chairs: cybette dericcrago dmsimard felixfontein gundalow jillr
19:02:50 <dmsimard> need chairs
19:02:57 <gundalow> (very quickly as I know everybody is excited to get to Checklist)
19:03:03 <felixfontein> #topic Updates
19:03:03 <dmsimard> #topic updates
19:03:05 <samccann> o/
19:03:08 <dmsimard> #undo
19:03:08 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7eff1a563350>
19:03:08 <abadger1999> felixfontein: in theory, probably yes.  In practice you probably depend on your dependencies keeping the same licensing and the same licensing of their dependencies unless they call it out in the release notes.
19:03:13 <felixfontein> #chair samccann abadger1999
19:03:13 <zodbot> Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein gundalow jillr samccann
19:03:36 <lmodemal> Hello!
19:03:44 <felixfontein> abadger1999:  I know why I like dependencies which have no other dependencies ;)
19:03:47 <felixfontein> #chair lmodemal
19:03:47 <zodbot> Current chairs: abadger1999 cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann
19:04:02 <briantist> hi I'm lurking but I'm in back-to-back meetings all day so kind of distracted
19:04:22 <cyberpear> o/
19:04:42 <gundalow> #info Work is progressing on moving Collection repos to Azure Pipelines (AZP) https://dev.azure.com/ansible/community.crypto/_build?definitionId=21&_a=summary shows AZP running against `community.crypto` https://github.com/ansible-collections/overview/issues/124 will track the overall progress. I'm writing docs as I go
19:04:43 <felixfontein> #chair cyberpear briantist
19:04:43 <zodbot> Current chairs: abadger1999 briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal samccann
19:05:01 <felixfontein> briantist: I'm chairing you anyway, #unchair yourself if you don't want to ;)
19:05:09 <briantist> fair enough :)
19:05:48 <dmsimard> gundalow: is there a deadline to move to AZP ?
19:06:12 <felixfontein> #info ansible-base 2.10.4rc1 has been released
19:06:48 <gundalow> dmsimard: Shippable haven't been that clear. It's the main thing I'm working on now, so I'd hope to get most if not all of it done over the next two weeks
19:07:54 <abadger1999> #info abadger1999 has an email to send to red hat legal Re: licensing of collection contents.  Comment after the meeting if you see anything that should be addressed/changed: https://gist.github.com/abadger/af41787b30bc678876efdca81bbbc66c
19:09:25 <tadeboro> o/
19:09:50 <resmo> abadger1999, offtopic but did you just say bsd is not legal to use as a library but our module_utils has to be bsd code?
19:10:08 <resmo> which is used in our gpl modules?
19:10:17 <abadger1999> resmo: I don't think so... what are you reading?
19:10:27 <resmo> ok, then all good.
19:11:07 <abadger1999> resmo: Talk to me after the meeting or PM if the meeting ends to late and I'll be sure to clarify
19:11:36 <resmo> ok, thanks
19:12:06 <dmsimard> any other updates ?
19:12:15 <cybette> #chair tadeboro resmo
19:12:15 <zodbot> Current chairs: abadger1999 briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal resmo samccann tadeboro
19:12:29 <felixfontein> don't think so
19:14:10 <felixfontein> #topic discussion of guidelines for including new collections into Ansible
19:14:15 <acozine> o/
19:14:28 <felixfontein> who wants to lead discussion for this topic? abadger1999?
19:14:30 <felixfontein> #chair acozine
19:14:30 <zodbot> Current chairs: abadger1999 acozine briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr lmodemal resmo samccann tadeboro
19:15:20 <gundalow> So I'm aware of
19:15:20 <gundalow> 1. What type of contributions are accepted
19:15:20 <gundalow> 2 Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee.
19:15:20 <gundalow> 3. MUST be in Galaxy + README.md
19:15:20 <gundalow> 4. MUST changelogs
19:15:42 <gundalow> (first 4 from https://github.com/ansible/community/issues/539#issuecomment-738321359)
19:15:59 <gundalow> 5. BSD License for module_utils should be 2 clause #133
19:16:26 <gundalow> 6. Collections requirements for role or playbook-focused collections? #127
19:16:26 <abadger1999> Cool.
19:16:34 <gundalow> Anyone know of anything else?
19:16:37 <abadger1999> Are 1 and 2 the same?
19:16:41 <felixfontein> for 1 and 2 we had concrete suggestions, but ran out of time
19:16:47 <felixfontein> 1: Add to documentation section: "What type of contributions are accepted, if any, and the method for submitting contributions must be documented. This documentation SHOULD be in a CONTRIBUTING file in the root of the repository, or mentioned in the README."
19:16:51 <felixfontein> 2: Add a clause "Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee. Every rejected candidate will get feedback, and we try to have more precise rules for Ansible 4.0.0."
19:17:02 <felixfontein> abadger1999: no
19:17:10 <abadger1999> Ah... 1 is about upstrewam collections.
19:17:25 <gundalow> ah, sorry, I only copied the first sentance
19:17:54 <gundalow> ok, starting at the top
19:17:57 <felixfontein> abadger1999: last time you said you weren't happy with at least one of 1 and 2
19:18:02 <abadger1999> <nod>
19:18:13 <gundalow> #topic 1.  What type of contributions are accepted
19:18:34 <gundalow> > Add to documentation section: "What type of contributions are accepted, if any, and the method for submitting contributions must be documented. This documentation SHOULD be in a CONTRIBUTING file in the root of the repository, or mentioned in the README."
19:18:57 <dmsimard> I don't see any problem with that
19:19:10 <abadger1999> I'm fine with this one as it goes along with the other requirements we're making on upstream collections.
19:19:28 <abadger1999> (If we revisit them in the future, I'd be for revisiting them as a group)
19:19:32 <abadger1999> +1 from me
19:19:56 <acozine> +1  though I could wordsmith it a bit
19:20:06 <dmsimard> +1
19:20:07 * acozine is probably wordsmithing her own words . . .
19:20:11 <felixfontein> +1
19:20:15 <samccann> +1
19:20:15 <felixfontein> acozine :)
19:20:15 <jillr> +1 and happy to let acozine wordsmith it
19:20:20 <dericcrago> +1
19:20:36 <jillr> acozine: I think I wrote that one so please improve upon it!
19:20:50 <cybette> +1
19:20:50 <tadeboro> +1
19:20:54 <resmo> +1 and acozine +1
19:21:23 <gundalow> So do we want something along the lines of:
19:21:23 <gundalow> > The ``CONTRIBUTING.md`` (or ``README.md``) MUST state what types of contributions (PRs, feature requests, bugs) are accepted and any relevant contributor guidance
19:21:51 * acozine passes writer's hat to gundalow with a thumbs-up
19:21:53 <gundalow> (I note writing RST into irccloud confuses it)
19:21:54 <felixfontein> hmm, I think bug reports should always be accepted
19:22:05 <gundalow> felixfontein: yup, good call
19:22:13 <dmsimard> there is a requirement on issue tracker
19:22:15 <dmsimard> already
19:22:20 <felixfontein> it doesn't make sense if we require a public issue tracker and then allow collections to forbid users to use it
19:22:21 <gundalow> So do we want something along the lines of:
19:22:21 <gundalow> > The ``CONTRIBUTING.md`` (or ``README.md``) MUST state what types of contributions (PRs, feature requests,) are accepted and any relevant contributor guidance. Bug reports must always be accepted
19:22:43 <felixfontein> sounds good to me
19:23:01 <jillr> lgtm
19:23:02 <dmsimard> what constitutes accepting a bug repo
19:23:05 <dmsimard> report* ?
19:23:13 <acozine> heh, now i want a bug repo!
19:23:23 <felixfontein> dmsimard: I guess it must be possible to create one so that other people can see it
19:23:37 <gundalow> #action wordsmith and add The ``CONTRIBUTING.md`` (or ``README.md``) MUST state what types of contributions (PRs, feature requests,) are accepted and any relevant contributor guidance. Issues (bugs and feature request) reports must always be accepted
19:23:50 <abadger1999> Shall we leave out ".md"  since those can be different?
19:23:58 <gundalow> #action update issue_template to include CONTRIBUTING.md
19:24:01 <dmsimard> abadger1999: can't be different for readme due to galaxy though
19:24:05 <felixfontein> README must always be README.md I think
19:24:09 <abadger1999> Ah, okay.
19:24:13 <dmsimard> felixfontein: yeah I mean so long as there isn't a guarantee of support or bugfix I mean
19:24:14 <felixfontein> CONTRIBUTING could also be something else though
19:24:31 <gundalow> We OK to move to `#2`?
19:24:48 <felixfontein> dmsimard: I guess they can simply ignore all reports, but at least other users with the same problem can write and potential users can see that there are a lot of unsolved bugs :)
19:24:58 <dmsimard> sure
19:25:02 <felixfontein> +1 for going to #2
19:25:09 <gundalow> .-.-.--.-.-.-.-.-.-.-.--
19:25:18 <gundalow> #topic 2. Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee
19:25:19 <dmsimard> gundalow: is that morse code ? :)
19:25:35 <acozine> heh, I thought it was a train
19:25:36 <gundalow> dmsimard: was just trying to put a section div in
19:25:58 <felixfontein> :)
19:25:58 <gundalow> I think we are happy with
19:25:58 <gundalow> > Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee
19:26:09 <felixfontein> I think abadger1999 wasn't happy last time
19:26:15 <gundalow> Though abadger1999 had some thoughts on `Every rejected candidate will get feedback, and we try to have more precise rules for Ansible 4.0.0.`
19:26:19 <dmsimard> yes, with the caveat that there is no such formal thing as a review committee (yet)
19:26:41 <abadger1999> We need to strike "and we try to have more precise tules for Ansible 4.0.0"
19:27:01 <acozine> it does seem risky to provide a timeline for that
19:27:11 <abadger1999> I would suggest adding "Differences of opinion should be taken to the community irc meeting for discussion and a final vote"
19:27:18 <felixfontein> acozine: having a timeline for 'trying' is not risky ;)
19:27:38 <acozine> felixfontein: true
19:27:44 <felixfontein> abadger1999: sounds also good
19:27:54 <abadger1999> The reason for striking is that I think the rules should be updated constantly.  With the majority of updates grandfathering collections that have already been approved to some extent
19:27:55 <felixfontein> abadger1999: could someone bring their 100 friends to the meeting so they win every vote?
19:28:33 <dmsimard> abadger1999: I like the suggestion
19:28:37 <abadger1999> felixfontein: yeah, that is a probelm and I think we'll need to decide on who is allowed to vote (not just on the checklist but on other policies and decisions as well).
19:28:41 <acozine> if someone has 100 friends willing to storm an IRC meeting, we have a recruiting opportunity on our hands!
19:28:53 <abadger1999> I think that we have to be working on that as soon as we get back from the winter holiday.
19:29:16 <felixfontein> abadger1999: sounds good
19:29:23 <acozine> (I do see the pitfall there, though)
19:29:23 <felixfontein> acozine: you're very opimistic :)
19:29:25 * tadeboro is not sure if there are 100 people left that know how to use IRC ;)
19:29:43 <dmsimard> we're 132 in this channel hopefully we'll be fine
19:29:57 <abadger1999> I've been talking to gundalow about what other projects like Fedora do but we still have to shape those other experiences into something that will work for our project.
19:30:31 <gundalow> tadeboro: haha
19:31:16 <felixfontein> ok, so "Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee. Every rejected candidate will get feedback. Differences of opinion should be taken to the community irc meeting for discussion and a final vote."?
19:31:42 <acozine> +1
19:31:52 <tadeboro> +1
19:31:53 <cybette> +1
19:31:55 <aminvakil> +1
19:31:56 <jillr> +1
19:31:57 <dmsimard> +1
19:32:02 <briantist> +1
19:32:03 * gundalow waits for abadger1999
19:32:06 <abadger1999> +1
19:32:08 <gundalow> +1
19:32:08 <dericcrago> +1
19:32:10 <felixfontein> +1
19:32:11 <geerlingguy> +1
19:32:23 <felixfontein> #agreed Add "Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee. Every rejected candidate will get feedback. Differences of opinion should be taken to the community irc meeting for discussion and a final vote."?
19:32:28 <felixfontein> #chair geerlingguy
19:32:28 <zodbot> Current chairs: abadger1999 acozine briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal resmo samccann tadeboro
19:32:41 <geerlingguy> sorry I'm late, lunch and all
19:33:08 <dericcrago> do we need a todo for a "re-applying after rejection" doc / procedure?
19:33:31 <abadger1999> I'll add it to the Overview section underneath the warning unless someone has a better place for it.
19:34:28 <felixfontein> dericcrago: I'm not sure whether we need that already now, we could add a rule if we see that some people abuse the process by always re-applying without really adjusting to the feedback
19:34:57 <felixfontein> abadger1999: sounds good
19:35:20 <gundalow> Anything else on `#2`?
19:35:33 <abadger1999> We could also leave reviews open until someone refuses to adapt to a review comment.
19:36:16 <briantist> so it'll be like a PR? 😂
19:37:02 <felixfontein> gundalow: I think not
19:37:16 <abadger1999> briantist: Yes, it will.... hopefully we'l be able to do them better than the current PRs but there is definitely a danger of getting backlogged.
19:38:03 <gundalow> OK, hopefully a quickone next
19:38:07 <abadger1999> #info running PR for all the changes we're approving today: https://github.com/ansible-collections/overview/pull/135/files#diff-dacab21f27a6aa218b8dcaafcf6f5685df0ab52f231afa16e7a9ab5284b72c68
19:38:22 <gundalow> #topic 3. MUST be in Galaxy + have a README.md
19:38:29 <felixfontein> +1
19:38:34 <gundalow> Wording in https://github.com/ansible-collections/overview/pull/134
19:38:35 <github-linkbot> https://github.com/ansible-collections/overview/pull/134 | open, created 2020-12-09T18:56:11Z by gundalow: MUST be published to Galaxy + README.md
19:39:06 <tadeboro> Readme is alreday required for galaxy import iirc.
19:39:24 <acozine> +1 to content, but I'd either make those two separate items, or make it clear that Galaxy requires the README.md
19:39:44 <acozine> ah, nm, it's separate in the PR
19:40:13 <abadger1999> +1+1
19:40:20 <dmsimard> I added a comment in the PR, otherwise LGTM
19:40:41 <tadeboro> +1 for both
19:40:48 <jillr> +1 both
19:41:02 <dericcrago> +1 both
19:41:07 <felixfontein> +1 for both
19:41:11 <samccann> +1
19:41:15 <dmsimard> +1 for both
19:41:45 <aminvakil> +1 both
19:41:50 <cybette> +1 both
19:41:59 <gundalow> tadeboro: correct galaxy import requires, though it was implicit in the checklist
19:42:29 <felixfontein> tadeboro: gundalow: I think it doesn't hurt to have it explicitly. in case galaxy ever drops that requirement, we would still want a README :)
19:42:37 <tadeboro> gundalow: I commented before I looked at the PR.
19:42:37 <gundalow> exactly
19:42:40 <gundalow> #agreed MUST be in Galaxy + have a README.md (#134)
19:42:42 <gundalow> tadeboro: nps
19:42:46 <gundalow> It's a good point to make
19:42:46 <geerlingguy> +1 both
19:42:48 <gundalow> OK, next
19:42:52 <geerlingguy> oops missed :P
19:43:15 <gundalow> #topic 4. MUST changelogs
19:43:32 <gundalow> So in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#changelogs we talk about the options for changelogs
19:44:10 <felixfontein> we should change 'suggest' to 'MUST have'
19:44:25 <gundalow> Though I think
19:44:25 <gundalow> a) we are missing a MUST
19:44:25 <gundalow> b) Do we want to get stricter for new collections (ie only allow 1 or 2)
19:45:00 <gundalow> where that means
19:45:00 <gundalow> 1. antsibull-changelog
19:45:00 <gundalow> 2. chaneglogs/changelog.yaml
19:45:01 <dmsimard> allow 1 or 2 what ?
19:45:01 <felixfontein> for b), I don't mind, but I'm biased ;)
19:45:11 <jillr> +1 to change suggest to MUST, and I'd be in favor of only 1 or 2
19:45:24 <gundalow> ire drop `3. Provide a link to the changelog file (self-hosted) (not recommended)`
19:45:27 <jillr> dmsimard: there's 3 options in the link gundalow shared
19:45:43 <gundalow> dmsimard: you were too quick :)
19:45:50 <dmsimard> yes, ok
19:46:03 <felixfontein> option 3 is "provide a link to a changelog"
19:46:04 <samccann> can we get away with removing option 3? I thought that was a TPTB requirement for partners etc?
19:46:04 <gundalow> background: If people use option 1or 2 then docs.ansible.com will include the changelog
19:46:08 <tadeboro> +1 for a, for b I would keep the 2 as an option because smaller collections do not need changelog generator.
19:46:19 <felixfontein> samccann: what does TPTB mean?
19:46:36 <gundalow> tadeboro: keep 2 or 3?
19:46:55 <samccann> sorry the Powers That Be.. my name for people above my pay grade who make decisions
19:46:59 <gundalow> haha
19:47:03 <felixfontein> samccann: ah, ok :)
19:47:28 <tadeboro> gundalow: I am fine with removing 3 (link to changelog). But requiring changelog generator (option 1) is a bit harsh.
19:47:31 <gundalow> hum, small collections is a fair point. Is requiring `changelogs/changelog.yaml` too high a bar?
19:47:37 <jillr> I don't think anyone from partner engineering is here now, do we need an action to find out what their checklist currently is?
19:47:39 <samccann> anyway I vaguely remember we put option 3 in there for companies who have their own way of doing changelogs
19:47:47 <abadger1999> Dropping 3 seems like it will also exclude people using reno or another tool...
19:47:51 <resmo> keeping as is an option?
19:47:54 <gundalow> tadeboro: oh, sure. I'm onlt considering dropping 3
19:47:57 <felixfontein> samccann: and also community projects who do that
19:48:16 <gundalow> Ok, sounds like we need to keep `3 self hosted changelogs`, I'm OK with that
19:48:19 <jillr> make options 1 and 2 a SHOULD rather than MUST?
19:48:43 <felixfontein> jillr: i.e. SHOULD 1 or 2, and MUST 1 or 2 or 3?
19:48:52 <gundalow> You MUST include a changelog, ideal that SHOULD be 1 or 2. Or if need be 3
19:48:57 <dmsimard> it's at the expense of not including changelogs on docs.ansible.com -- is there another drawback ?
19:49:07 <jillr> felixfontein: yeah like, you have to have something but we really would prefer you do 1 or 2, pretty please :)
19:49:25 <felixfontein> dmsimard: that's the main and only drawback ('uniform changelog formatting' doesn't really count IMO :) )
19:49:33 <abadger1999> dmsimard: You also can't add things to the porting guide.
19:49:43 <abadger1999> (already documented on that page)
19:50:06 <abadger1999> We should document how/where to include your changelog link for option 3 as well.
19:50:15 <jillr> it's documented, should it be wordsmithed to be a bit clearer/stronger wording?
19:50:41 <dmsimard> agree on MUST include a changelog, should/ideally 1 or 2 and keep 3
19:50:43 <gundalow> My thought behind this is making sure that breaking changes are clearly visible to people. As the number of collections increases the chance of someone missing something increases
19:50:54 <felixfontein> (btw, right now we have one collection with a manual URL, and a handful of collections with no changelog)
19:50:54 <tadeboro> All those shortcommings sound like a good incentives to migrate from 3 to 2 or even 1.
19:51:31 <gundalow> This maybe something where we need to make it easier for people to maintain a proper changelog
19:51:32 <felixfontein> gundalow: that's actually a good reason!
19:51:48 <gundalow> aaaaand now to change my mind
19:52:08 <gundalow> MUST have, and MUST 1 or 2
19:52:31 <dmsimard> because it's included in the ansible package, right ?
19:52:36 <gundalow> yup
19:52:42 <felixfontein> we could vote between a) MUST 1 or 2, or b) MUST 1 or 2 or 3 (with suggestion to avoid 3)
19:52:57 <dmsimard> I mean collections that don't want to be included in the package are free to do their own thing ofc
19:53:02 <felixfontein> I think the part `MUST have changelog` is uncontroversial :)
19:53:15 <abadger1999> Let's vote on the uncontroversial part first.
19:53:16 <felixfontein> dmsimard: exactly
19:53:25 <gundalow> VOTE: MUST have a changelog
19:53:26 <gundalow> +1
19:53:28 <felixfontein> +1
19:53:28 <dmsimard> +1
19:53:29 <tadeboro> +1
19:53:29 <abadger1999> +1
19:53:30 <acozine> +1
19:53:31 <cyberpear> +1
19:53:32 <cybette> +1
19:53:33 <samccann> +1
19:53:35 <dericcrago> +1
19:53:49 <resmo> ++
19:53:51 <jillr> +1
19:53:54 <gundalow> #agreed MUST have a changelog
19:53:58 <gundalow> VOTING ENDS
19:54:01 <gundalow> NEXT VOTE
19:54:52 <gundalow> VOTE: Changelogs MUST be one of `antsibull-changelog` or `changelogs/changelog.yaml` (+1, -1, 0)
19:55:00 <felixfontein> +1
19:55:03 <gundalow> (ie no more self hosted changelogs)
19:55:09 <gundalow> +1
19:55:18 <resmo> -1
19:55:19 <abadger1999> -1
19:55:21 <samccann> I'm somewhere between a 0 and -1
19:55:22 <acozine> hmm, this means no support for reno?
19:55:27 <abadger1999> right
19:55:43 * jillr waffling... -1
19:55:47 <acozine> 0
19:55:47 <felixfontein> acozine: if you can trick reno into creating changelogs/changelog.yaml, it's fine
19:55:52 <acozine> heh
19:55:59 <gundalow> aside: what would it take to reno -> changelogs/changelog.yaml
19:56:01 <tadeboro> +1
19:56:18 <abadger1999> "no support for reno.... unless someone does extra work to enhance reno"
19:56:20 <dericcrago> 0
19:56:29 <dmsimard> I guess the intent is to make sure the collections that are included in the ansible package have relnotes on docs.ansible.com and for that to happen, it currently assumes antsibull-changelog as a requirement
19:56:34 * acozine has to skip out for a biobreak before next (video) meeting at the top of the hour
19:56:44 <jillr> in addition to the community points being made, I think we need to coordinate better with RH Partner Engineering before making that change
19:56:45 <gundalow> acozine: Thanks as always
19:56:49 <acozine> #unchair acozine
19:56:49 <zodbot> Current chairs: abadger1999 briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal resmo samccann tadeboro
19:56:55 <abadger1999> dmsimard: Yeah... a manual PR is also a possibility, I suppose.
19:56:56 <gundalow> jillr: Good point, thanks
19:57:03 <cybette> 0
19:57:16 <felixfontein> abadger1999: what kind of manual PR?
19:57:31 <dmsimard> like manually sending a PR to amend the porting guide or changelogs
19:57:41 <felixfontein> I don't think that works
19:57:43 <samccann> that wouldn't work
19:57:45 <dmsimard> as opposed to submitting whatever antsibull-changelog generates
19:57:49 <samccann> they are autogenerated
19:57:50 <abadger1999> acozine: If you have time before your next meeting, just a quick note of whether you would vote to approve the checklist as is for allowing new collections would be nice.
19:57:53 <gundalow> +1x3
19:57:53 <gundalow> -1x4 (counting samccann as -1
19:57:53 <gundalow> 0x2
19:57:53 <felixfontein> these are auto-generated, so you'd have to manually keep these entries for EVERY release
19:58:22 <abadger1999> Oh, I htought we had a place to submit additional entries.
19:58:35 <dmsimard> felixfontein: so it's a limitation of the tool, not the process per se
19:58:38 <acozine> abadger1999: +1 for approving the checklist
19:58:40 <felixfontein> abadger1999: well, kind of, but these are more like global entries, not collection-specific entries
19:58:42 <abadger1999> Thanks
19:58:46 <abadger1999> <nod>
19:58:47 <gundalow> Ok, so seems like this will need more thought. I appreciate the ideas here, though I want to make sure we get the rest of the checklist done
19:59:00 <dericcrago> how bout `Provide a link to the changelog file (self-hosted) (not recommended and may be deprecated in the future)`?
19:59:11 <felixfontein> abadger1999: and I'd like to avoid them to be abused by collections. if they want something in there, they have to provide a changelogs/changelog.yaml file
19:59:23 <dmsimard> dericcrago: doesn't work if the objective is to have a unified changelog/porting guide on docs.ansible.com
19:59:40 <tadeboro> As someone who will need to find a way to generate changelog.yaml file, I feel this is a fair price for being part of something bigger.
20:00:15 <gundalow> #info We like the idea of requiring chaneglogs that docs.ansible.com can build, though currently there are a few projects using manual or reno to generate changelogs. We need to update reno to generate changelog in the correct format
20:00:47 <gundalow> dmsimard: Do you know reno, could you please raise an issue for this in /overview/issues
20:00:47 <tadeboro> And I have certified content in mind when I talk about missing changelog.
20:00:57 <felixfontein> examples of manual entries: https://github.com/ansible-community/ansible-build-data/blob/main/2.10/changelog.yaml#L51 https://github.com/ansible-community/ansible-build-data/blob/main/2.10/CHANGELOG-v2.10.rst#breaking-changes--porting-guide-2
20:01:15 <gundalow> ===================================
20:01:24 <abadger1999> #info examples of manual entries, Source: https://github.com/ansible-community/ansible-build-data/blob/main/2.10/changelog.yaml#L51
20:01:28 <gundalow> Usefull discussion here, though there are still other things to discuss
20:01:31 <felixfontein> (we mainly did that to keep entries from the ansible/ansible porting guide for 2.10)
20:01:33 <gundalow> on the checklist
20:01:45 <abadger1999> #info examples of manual entries, Rendered to rst: https://github.com/ansible-community/ansible-build-data/blob/main/2.10/CHANGELOG-v2.10.rst#breaking-changes--porting-guide-2
20:01:45 <gundalow> We ready to move on to topic 5?
20:01:58 <jillr> +1
20:02:00 <felixfontein> +1
20:02:04 <dmsimard> wfm
20:02:04 <gundalow> ==================================
20:02:21 <gundalow> #topic 5. BSD License for module_utils should be 2 clause
20:02:29 <gundalow> https://github.com/ansible-collections/overview/pull/133
20:02:29 <github-linkbot> https://github.com/ansible-collections/overview/pull/133 | open, created 2020-12-09T17:42:24Z by abadger: BSD License for module_utils should be 2 clause
20:02:40 <abadger1999> https://github.com/ansible-collections/overview/pull/133/files
20:02:59 <felixfontein> # Simplified BSD License (see licenses/simplified_bsd.txt or https://opensource.org/licenses/BSD-2-Clause)
20:03:16 <felixfontein> that's the current short header we're using in module_utils
20:03:28 <abadger1999> I looked up the existing license requirements for module_utils after last meeting.  Existing guidelines for module_utils in ansible/ansible is to use BSD-2-clause rather than 3 clause, which we discussed here last time.
20:03:51 <felixfontein> I'm +1 for the change
20:04:17 <abadger1999> I think using BSD-2-clause is in the the spirit of what we wanted (do what ansible has historically done until we get legal's permission to open it up to other open source licenses).
20:04:23 <abadger1999> +1
20:04:26 <jillr> +1
20:04:31 <tadeboro> +1
20:05:02 <gundalow> +1
20:05:04 <dmsimard> legal bit outside my realm of expertise, I'll defer to the knowledgeable folks
20:05:08 <samccann> 0 cuz the whole licensing thing is ..wooosh... over my head right now
20:05:13 <gundalow> samccann: :D
20:05:25 <dericcrago> likewise... defer to legal
20:05:30 <abadger1999> Roger that.
20:05:35 <felixfontein> my +1 is mainly because the current version is saying something we don't do right now, and with the change we can just keep what we have right now ;)
20:05:55 <gundalow> #agreed https://github.com/ansible-collections/overview/pull/133
20:05:57 <gundalow> Ok
20:06:19 <gundalow> #topic Other checklist items
20:06:41 <gundalow> #undo
20:06:41 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7eff2015c050>
20:06:58 <gundalow> #topic 6. Collections requirements for role or playbook-focused collections
20:07:02 <gundalow> from geerlingguy
20:07:11 <gundalow> #info Background https://github.com/ansible-collections/overview/issues/127
20:07:37 <gundalow> Seems like felixfontein jillr dmsimard had thoughts on this
20:07:38 <felixfontein> I would even suggest to probably skip role/playbook only collections for ansible 3.0.0
20:07:49 <dmsimard> I feel this isn't so much about collections with only roles and playbooks (i.e, no plugins) than it is about the precedent of shipping roles and playbooks in the ansible package by way of including collections
20:07:50 <felixfontein> since we don't have any experience with them at all
20:07:56 <felixfontein> (at least yet)
20:08:27 <gundalow> I'm OK with ignoring this for 3.0.0 if that's what others thing
20:08:36 <dmsimard> We've talked a lot about requirements for plugins like "must pass ansible-test sanity tests" and stuff like that but we haven't discussed roles/playbooks
20:08:40 <abadger1999> I'd propose skipping this until after we approve the checklsit for new inclusion.
20:09:02 <felixfontein> dmsimard: that's mostly why I would suggest to skip them for now, so we have more time to look at what's a good way to check them :)
20:09:08 <dmsimard> does skipping it imply that we will rm -rf roles/playbooks directories as part of packaging ?
20:09:20 <tadeboro> Maybe we can require that galaxy import is clean (for some definition of clean)?
20:09:21 <abadger1999> We can start talking about it next meeting if people are interested and there isn't anything higher priority... if something is approved before the deadline for new collections, they could go into 3.0.0
20:09:27 <felixfontein> dmsimard: no, it means not accepting new collections that only have roles/playbooks and nothing else
20:09:30 <dmsimard> because there's nothing preventing collections from including roles/playbooks right now
20:09:39 <felixfontein> some collections already do
20:09:43 <dmsimard> right
20:10:01 <tadeboro> And most of our collections (even certified) contain modules and roles.
20:10:10 <gundalow> VOTE: Skip "Collections requirements for role or playbook-focused collections" for the first release of the checklist. If there is time we can discuss in next weeks meeting
20:10:12 <gundalow> +1
20:10:18 <abadger1999> Would we want geerlingguy  to write a strawman proposal?
20:10:22 <jillr> I mainly think it's really good to anticipate and lay out some criteria, but I think that will be a significant undertaking to work out. I don't have any novel suggestions that haven't already been brought up.
20:10:26 <abadger1999> +1
20:10:35 <jillr> +1 geerlingguy to put a proposal together
20:10:35 <samccann> +1
20:10:36 <aminvakil> +1
20:10:36 <felixfontein> abadger1999: if he has time, I would appreciate that!
20:10:45 <samccann> and +1 for more work for geerlingguy :-)
20:10:50 <felixfontein> hehe :)
20:10:59 <felixfontein> +1
20:11:00 <dmsimard> volounteering someone else to do the work haha
20:11:12 <abadger1999> jillr: You also expressed interest.... I'm mainly thinking someone who has role-heavy collections will need to drive this forwards.
20:11:13 <felixfontein> and then vote about it :D
20:11:14 <gundalow> and no lunch for geerlingguy next week
20:11:27 <tadeboro> Does skipping the role part is not checked at all when deciding if collection will or will not be part of ansible?
20:11:28 <geerlingguy> +1 ha, I should be able to whip something up. Maybe.
20:11:34 <geerlingguy> Probably after next week though
20:11:34 <jillr> abadger1999: yeah totally happy to participate in that
20:11:39 <abadger1999> geerlingguy: Cool, thanks
20:11:59 <abadger1999> jillr: thank you as well :-)
20:12:04 <felixfontein> geerlingguy: thanks a lot! :)
20:12:19 <jillr> geerlingguy++
20:12:26 <felixfontein> I'm also working on a role-only collection, so I'm definitely interested in the outcome
20:12:37 <resmo> -1 for more work for geerlingguy, I want to get more raspberry pi youtube content ;)
20:12:42 <jillr> lol
20:12:47 <felixfontein> hehe
20:12:54 <gundalow> tadeboro: I think it means "As the checklist stands (once current PRs have been merged) if a collection meets all the documented requirements it stands a very good change of being included in Ansible 3.0.0 (even if it happens to contain roles"
20:13:13 <tadeboro> gundalow: then +1 from me
20:13:16 <dmsimard> +1 to keep roles/playbooks requirements out of scope for 3.0 checklist but I feel strongly about discussing QA/requirements soon enough
20:13:29 <felixfontein> +1 on what dmsimard said
20:13:38 <gundalow> Though I don't think we have anything in the collection checklist that says collections can't only contain roles
20:14:28 <abadger1999> Right... it will be more of if someone tests the boundaries (role-only collection), then the reviewer would bring it here and say "the future has come, how do you vote?"
20:14:41 <gundalow> And now my mind is thinking about Babe the Pig, and the sheepdog trial rulebook not explicitly stating the animals must be dogs.
20:14:57 <felixfontein> I'd prefer to make it explicit that we might not accept any role/playbook-only collection for 3.0.0
20:14:58 <dmsimard> abadger1999: this is where the "all rights reserved to review committee" clause comes in until we have something better I suppose
20:15:04 <abadger1999> Exactly :-)
20:15:25 <samccann> heh
20:15:29 <felixfontein> though they should still apply, to make it easier to taylor the process. which will also help them :)
20:15:38 <gundalow> `all rights reserved to review committee` is very much our "oh, woops, we should have really thought that people might do X and that's baaaaad"
20:15:41 <dericcrago> +1 if collections aren't automatically dismissed / denied based on the inclusion of roles or playbooks
20:15:54 <dmsimard> gundalow: yeah we should we wary of invoking it too easily :)
20:15:57 <tadeboro> IIRC, NGINX certified collections are role-only.
20:16:22 <gundalow> tadeboro: interesting, didn't know that. Though not included in `ansible==2.10`
20:16:33 <tadeboro> So if NGINX and partner engineering decide to try get it into ansible, fun times ;)
20:16:34 <abadger1999> I'm okay invoking it frequently... but we should be taking all decisions and turning htem into generalizable checklist items for the future.
20:16:45 <abadger1999> rather than using it for one-off decisions.
20:16:47 <gundalow> OK
20:16:50 <gundalow> =======================
20:17:00 <gundalow> #info We will revisit this topic
20:17:08 <gundalow> #topic Other items
20:17:14 <gundalow> Anything else for the checklist
20:17:29 <abadger1999> The only thing left that I know of is Overall vote.
20:17:50 <abadger1999> Approve the checklist plus items approved today as the criteria to start approving new collections.
20:17:54 <gundalow> jillr: I believe we've covered everything from https://github.com/ansible-collections/overview/issues/126
20:18:09 <gundalow> abadger1999: as in who and how the vote takes place?
20:18:18 <jillr> gundalow: I believe you are right, I'm +1 to clsoe that
20:18:26 <felixfontein> abadger1999: should we merge some of the PRs before voting?
20:18:43 <felixfontein> gundalow: jillr: I agree, also just looked at it
20:19:04 <abadger1999> I can merge my running one for the meeting now.
20:19:19 <abadger1999> dmsimard: gundalow : What needs to be done to: https://github.com/ansible-collections/overview/pull/134 before that is merged?
20:20:06 <dmsimard> I don't have a strong opinion
20:20:28 <dmsimard> not against merging it as-is
20:20:42 <abadger1999> Okay, I'll merge as is.  We can always change it later.
20:20:50 <dmsimard> +1
20:20:53 <abadger1999> And reformatting should be easier to approve than changes to content.
20:21:07 <gundalow> hum, at the top of the checklist do we need something like `MUST and SHOULD in this document refer to the including content in the Ansible package`
20:21:42 <dmsimard> gundalow: we could perhaps generally wordsmith the doc better in general -- but there is a dedicated section at the end about including in the ansible package
20:22:00 <abadger1999> Yeah...... I think something like that for the whole document.
20:22:00 <felixfontein> gundalow: SHOULD also applies in general, but the MUST parts are for inclusion in Ansible :)
20:22:02 <gundalow> Yup, I think the doc needs a bit of tidying up now
20:22:05 <abadger1999> Change to overview....
20:22:11 <gundalow> Good call
20:22:13 <jillr> once everything is merged a copy edit/wordsmithing pass would probably be wise
20:22:15 <abadger1999> remove "This document is for maintainers of collections to provide them help, advice, and guidance on making sure their collections are correct."
20:22:42 <gundalow> I have to drop off now. Thank you everybody. Lots of great progress today
20:22:51 <felixfontein> gundalow: thanks a lot! have a great evening!
20:22:54 <jillr> thanks gundalow!
20:23:02 <abadger1999> gundalow: Could you vote before leaving?
20:23:14 <felixfontein> so how should we proceed, vote on it now, do another pass (copy-editing), and then vote again?
20:23:22 <abadger1999> Sounds good
20:23:41 <gundalow> abadger1999: what's the Q?
20:23:45 <dmsimard> copy-editing might not be ready until next meeting though, so acceptance today would be provisional I guess ?
20:23:49 <jillr> can reviews on the copy-edit pass be the second vote?  we're coming on a time of year when folks might have weird schedules
20:23:54 <abadger1999> VOTE: Start allowing new collection submissions and approvals based on the current checklist: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
20:24:04 <dmsimard> +1
20:24:09 <felixfontein> +1
20:24:10 <jillr> +1
20:24:14 <gundalow> +1
20:24:19 <samccann> +1
20:24:24 <resmo> +1
20:24:26 <abadger1999> dmsimard: Copy editing shouldn't change the substance of the rules, just clarify and make them easier to read.
20:24:28 <abadger1999> +1
20:24:47 <tadeboro> +1
20:24:52 <abadger1999> acozine also gave a +1 based on the status of this when she left the meeting.
20:25:02 <felixfontein> dmsimard: that's why I'd suggest another vote before merging the copy-editing PR :)
20:25:39 <felixfontein> so anyone who thinks that some edit changes the meaning should point it out before, and that could block a vote
20:25:47 <dmsimard> yeah, something along those lines
20:25:49 <abadger1999> #chair
20:25:49 <zodbot> Current chairs: abadger1999 briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow jillr lmodemal resmo samccann tadeboro
20:25:58 <geerlingguy> +1
20:25:59 <dericcrago> +1
20:26:16 <cyberpear> +1
20:26:22 <abadger1999> Anyone else who'd like to vote to approve or disapprove the start of new collection acceptance, please speak up now :-)
20:26:34 <felixfontein> or shut up until next week? ;)
20:26:39 <samccann> heh
20:26:40 <cybette> +1
20:27:17 <abadger1999> Cool,
20:27:43 <felixfontein> #agreed Start allowing new collection submissions and approvals based on the current checklist: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
20:28:02 <felixfontein> hmm we should have started a new #topic first I guess
20:28:05 <felixfontein> #undo
20:28:05 <zodbot> Removing item from minutes: AGREED by felixfontein at 20:27:43 : Start allowing new collection submissions and approvals based on the current checklist: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
20:28:12 <felixfontein> #topic Approval of the checklist
20:28:13 <abadger1999> Yay, thanks everyone for doing a tough job on a short timeframe :-)
20:28:15 <felixfontein> #agreed Start allowing new collection submissions and approvals based on the current checklist: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst
20:28:33 <dmsimard> abadger1999: and thanks for spearheading that
20:28:37 <felixfontein> btw, there seems to be an application for a new collection in 2.10: https://github.com/ansible-community/ansible-build-data/pull/42
20:28:37 <github-linkbot> https://github.com/ansible-community/ansible-build-data/pull/42 | open, created 2020-12-09T15:07:50Z by ganeshrn: Add ansible.utils to collection list
20:28:42 <felixfontein> abadger1999: thanks a lot!
20:29:00 <felixfontein> so what happens if we have an application (at least for 2.11)?
20:29:05 <felixfontein> meh. 3.0.0 I mean :)
20:29:36 <samccann> need to drop for 15 min or so... \o
20:29:53 <felixfontein> samccann: thanks for being here!
20:30:07 <jillr> felixfontein: presumably we bring the application here and discuss?
20:30:13 <dmsimard> for posterity maybe we'll want to tag a versioned release of the checklist (maybe after copy-editing)
20:30:13 <resmo> I am about to replace a collection with another for 3.0.0
20:30:36 <resmo> (different namespace, moved to vendor)
20:30:47 <felixfontein> resmo: define 'replace' :)
20:31:03 <felixfontein> resmo: do you want to change the old one to essentially redirect to the new one, and add a new one?
20:31:38 <felixfontein> jillr: only during meetings, or also at other times?
20:32:06 <abadger1999> felixfontein: A year ago, I would think that the net new collections should be added to 3.0.0 but not to 2.10.5.  We can talk about that next meeting, though.  I'm currently undecided.
20:32:31 <abadger1999> I'll create the directory for ansible-build-data/3.0 as well so PRs can target just that version.
20:32:42 <resmo> felixfontein, need to figure it out how would be best, talk to you later
20:33:12 <jillr> felixfontein: that's an excellent question. maybe only meetings at first, then we can see how it goes?
20:33:25 <felixfontein> resmo: there should be some kind of backwards compatibility, so either the old collection deprecates all its contents, or it redirects to the new one, I think. but yeah, no need to discuss it now ;)
20:33:43 <felixfontein> jillr: sounds good. also depends on the number of applications :)
20:34:20 <felixfontein> abadger1999: so far we only added collections which contain content that was already included before (but in another collection). ansible.utils would be something completely new (as far as I understand)
20:35:17 <abadger1999> at some point, I think we'll have a group of people that are trusted to review new collections.  And we can just let them approve and then mark the ansible-build-data PR  as ready to merge.
20:35:31 <abadger1999> But we're still bootstrapping, I think :-)
20:35:36 <abadger1999> felixfontein: <nod> Yeah.
20:36:27 <tadeboro> Hmm, I just noticed the second bullet point in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#collection-infrastructure What happens if the collection already has a CoC? (And this is not a hypothetical question.)
20:37:30 <abadger1999> Grrr....
20:37:30 <dmsimard> I think the wording that we agreed on in a previous meeting was slightly different and along the lines of "MUST have a CoC or defer/link to the Ansible one"
20:37:36 <cyberpear> yeah, I'd drop that requirement entirely, or make it a should
20:37:37 * dmsimard looks through logs
20:37:38 <abadger1999> I didn't think we approved that version lsat week.
20:37:48 <abadger1999> I thought we approved "MUST have a CoC".
20:38:08 <abadger1999> and the ansible CoC was what people should use if they didn't already have their own.
20:38:12 * abadger1999 goes spelunking.
20:38:22 <felixfontein> I also remember some other wording, but we had something that the Ansible CoC would govern all collections in the Ansible package
20:38:24 <dmsimard> 20:13:05 <gundalow> #agreed MUST have a CoC (or if not fall back to Ansible's)
20:38:35 <dmsimard> from https://meetbot.fedoraproject.org/ansible-community/2020-12-02/ansible_community_meeting.2020-12-02-19.01.log.html
20:39:13 <abadger1999> Okay....
20:39:21 <tadeboro> That sounds better. For example, we already have a Sensu CoC in our Sensu Go collection.
20:39:42 <abadger1999> So that's a substantive change rather than just formatting and should have come back for a vote.
20:39:53 <felixfontein> we were discussing about  20:26:25 <acozine> can we just do "all collections in the ansible package are governed by the Ansible CoC"?
20:39:58 <felixfontein> but didn't really vote in the end I think
20:40:26 <dmsimard> abadger1999: we agreed on the intent, do you mean we didn't agree on the wording ?
20:40:32 <abadger1999> Yeah, and I would have voted -1 o nthat.
20:40:45 <abadger1999> No, we didn't agree to that.
20:41:25 <dmsimard> hmmm, going back through the logs it's true there didn't seem to be a formal vote on that item
20:41:31 <abadger1999> I'm going to go through the commits that were added to that PR after the meeting last week.
20:41:57 <abadger1999> I didn't realize that more commits had been added after the meeting when I told gundalow that PR could be merged.
20:42:16 <abadger1999> Anything that's changing the meaning post-meeting, I'll put up for a vote next meeting.
20:42:34 <dmsimard> want to #action that ?
20:43:09 <felixfontein> #info there seems to be some content in the checklist that wasn't properly approved during the last meeting, so we have to do another iteration on th(is|ese) problematic topic(s)
20:43:16 <tadeboro> I missed previous meeting because $job, otherwise I would raise my voice earlier.
20:43:39 <dmsimard> tadeboro: no worries, thanks for bringing it up
20:43:58 <abadger1999> Yeah, I don't think this is a good direction to take.
20:45:07 <felixfontein> ok, should we continue with open floor?
20:45:12 <abadger1999> Yes.
20:45:14 <felixfontein> in case someone has a quick topic
20:45:17 <felixfontein> #topic Open Floor
20:45:30 <felixfontein> so if someone has a quick topic, it's time now to bring it up. or wait until next week :)
20:46:11 <felixfontein> otherwise I'll close in ~4 minutes
20:47:18 <dmsimard> nothing from me but thanks everyone for contributing \o/
20:50:14 <felixfontein> #info I'm working on adding support to add 'new plugin' notifications for test and filter plugins, and 'new role'/'new playbook' notifications to changelogs. if someone is interested in it, PTAL and comment: https://github.com/ansible-community/antsibull-changelog/pull/48
20:50:17 <github-linkbot> https://github.com/ansible-community/antsibull-changelog/pull/48 | open, created 2020-11-26T21:08:55Z by felixfontein: [WIP] Add support for test and filter plugins, roles and playbooks
20:50:57 <felixfontein> #info I'm working on a small framework for making open_url()-based plugins (or modules) easier to test. reviews/comments welcome! https://github.com/ansible-collections/community.internal_test_tools/pull/24
20:50:59 <github-linkbot> https://github.com/ansible-collections/community.internal_test_tools/pull/24 | open, created 2020-12-07T06:52:11Z by felixfontein: Add open_url test framework
20:51:38 <abadger1999> Yay!
20:53:13 <felixfontein> #endmeeting