18:00:13 <felixfontein> #startmeeting Ansible Community Meeting
18:00:13 <zodbot> Meeting started Wed Mar 16 18:00:13 2022 UTC.
18:00:13 <zodbot> This meeting is logged and archived in a public location.
18:00:13 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:13 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:13 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/645
18:00:13 <felixfontein> acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:00:17 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
18:00:20 <felixfontein> #topic Updates
18:00:33 <briantist> o/
18:00:35 <jillr> o/
18:00:35 <andersson007_> o/
18:00:39 <briantist> (am in another meeting though)
18:00:41 <cyberpear> o/
18:00:45 <samccann> \o
18:01:05 <dmsimard> #info Ansible 5.5.0 has been released: https://groups.google.com/g/ansible-announce/c/4sbFT7aVklY
18:01:15 <acozine> o/
18:01:40 <felixfontein> #chair briantist jillr andersson007_[m] briantist cyberpear samccann dmsimard acozine
18:01:40 <zodbot> Current chairs: acozine andersson007_[m] briantist cyberpear dmsimard felixfontein jillr samccann
18:01:48 <felixfontein> dmsimard: you have to repeat that, sorry
18:01:50 <dmsimard> ah, that may have not gone through since I wasn't chair, let's try that again
18:01:52 <dmsimard> #info Ansible 5.5.0 has been released: https://groups.google.com/g/ansible-announce/c/4sbFT7aVklY
18:01:55 <andersson007_> there's the last chance to vote on community.sap inclusion for folks who haven't voted yet https://github.com/ansible-community/community-topics/issues/74
18:02:14 <andersson007_> i'll ping someone to help cont votes later during the meeting
18:02:34 <felixfontein> #info VOTE DEADLINE TODAY! https://github.com/ansible-community/community-topics/issues/74 Inclusion of new collections
18:02:44 <felixfontein> #info Vote deadline on Monday: https://github.com/ansible-community/community-topics/issues/71 (Steering Committee rules)
18:02:48 <felixfontein> #info Vote deadline in a week: https://github.com/ansible-community/community-topics/issues/76 (files to remove from Ansible 6) and https://github.com/ansible-community/community-topics/issues/77 (collections must not use files from non-standard locations)
18:03:02 <andersson007_> thanks felixfontein
18:03:02 <felixfontein> especially the last three votes are pretty important, so please make sure you vote on them if you haven't already!
18:03:39 <felixfontein> #info Discussion on extra links format: https://github.com/ansible-community/community-topics/issues/80 - open until next Monday
18:04:10 <felixfontein> #info Discussions on removing collections from Ansible: https://github.com/ansible-community/community-topics/issues/79 https://github.com/ansible-community/community-topics/issues/34
18:04:31 <felixfontein> so lots of exciting things happening asynchronously :)
18:04:36 <dmsimard> felixfontein: thanks for rounding up the topics
18:05:00 <felixfontein> which of these (or others?) do you want to discuss about today?
18:05:29 <dmsimard> I'd like to talk about 34 and 79, though they are related they are not exactly the same
18:06:00 <dmsimard> It would probably be more productive to chat about 34 first
18:06:38 <acozine> that seems like a good idea, since we just "primed the pump" by reviewing a collection for inclusion
18:06:39 <bcoca> well, 34 defines reasons and should define what each reason means, including 'inactive' and 'unmaintained'
18:06:43 <felixfontein> #topic Removing collections from Ansible
18:06:59 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/34 (and relatedly, https://github.com/ansible-community/community-topics/issues/79)
18:07:19 <felixfontein> bcoca: indeed!
18:07:22 <felixfontein> #chair bcoca
18:07:22 <zodbot> Current chairs: acozine andersson007_[m] bcoca briantist cyberpear dmsimard felixfontein jillr samccann
18:07:37 <dmsimard> bcoca: 34 is more about the criteria and the process over which we would remove collections, yes
18:07:58 <dmsimard> 79 is.. let's call it a list of candidates to put through that process
18:08:14 <samccann> so as a user, if I am using collection.foo in Ansible 5, and it ends up removed in Ansible 6 - do my playbooks all stop working?
18:08:16 <acozine> heh, so we have a potential rule and some potential rule-breakers
18:08:40 <acozine> good question, maybe we need to deprecate collection inclusions?
18:09:03 <jillr> deprecation notices would be good
18:09:04 <felixfontein> samccann: they do, unless you install that collection manually
18:09:10 <andersson007_> we should develop criteria and procedure for removal first
18:09:14 <dmsimard> samccann: yes -- it is a breaking change though one that can be worked around easily by installing the collection manually
18:09:26 <felixfontein> I think we should definitely have a deprecation period (except for some very specific and seldom exceptions maybe)
18:09:32 <andersson007_> we shouldn't judge only by last release dates
18:09:40 <felixfontein> unfortunately we cannot guarantee that users see the deprecation notices in the porting guide / changelog
18:10:10 <andersson007_> if nothing is happening in a collection, it doesn't mean it's not maintained
18:10:24 <felixfontein> indeed
18:10:25 <andersson007_> maybe red CI would be a good indicator in addition to other indicators
18:10:40 <dmsimard> andersson007_: I disagree -- if nothing is happening in a collection, it is by definition unmaintained
18:10:40 <acozine> my criteria would be something more like "dozens of issues/bugs have been filed and nobody has responded, let along fixed anything"
18:10:41 <andersson007_> permanently red
18:10:47 <felixfontein> issues that are never triaged / responded to
18:10:48 <dmsimard> now, whether it still works or not is another matter
18:10:59 <felixfontein> acozine: +1
18:11:16 <andersson007_> let's put our brainstorm ideas in https://github.com/ansible-community/community-topics/issues/34
18:11:32 <bcoca> samccann:  yes and no, it breask if you only install 'ansible' but you can always install the specific collections in parallel until you find a substitute
18:11:44 <acozine> dmsimard: I don't know, some modules that interact with stable APIs might be stable for a long time without much change
18:12:20 <dmsimard> acozine: I stand by my definition of unmaintained meaning that no maintenance is taking place :p
18:12:33 <bcoca> andersson007_: if nothing happens in colleciton AND it has outstanding bugs,  ... if my code is perfect, nothing needs to happen ....
18:12:47 <samccann> If removed collections are listed under breaking changes, that would help (though as folks said, people don't always read the porting guides). Maybe we need a process where we announce 'candidates for removal' in the bullhorn as well
18:13:22 <felixfontein> samccann: that's the bare minimum. IMO we should first list them as deprecated a certain amount of time ahead before removal
18:13:31 <bcoca> once thing you can do is set deprecation notices in the runtime.yml , so people see that the collectino will be removed (not surehow to do at collection level)
18:13:39 <felixfontein> and +1 for announcing that in bullhorn
18:13:55 <bcoca> or if you need to do each plugin . but that might require modifying the colleciton's runtime.yml
18:13:55 <felixfontein> bcoca: we can only do that if we have access to the collection's repo, and we want to make a new release ourselves
18:14:14 <bcoca> if deprecated, means you still ship it, its not same as removed
18:14:15 <dmsimard> felixfontein: this is actually what we did for community.azure
18:14:19 <felixfontein> for some collections we have such access, for some others we do not
18:14:20 <andersson007_> bcoca: audience can be small:)
18:14:45 <bcoca> any colleciton you have shipped, you should still have access to 'last copy'
18:14:45 <felixfontein> if the audience is small, nobody cares when it is removed ;)
18:14:50 <samccann> @bcoca - yeah that's the bit I wasn't sure about  - how do we force a deprecation notice on an unmaintained collection. If that runtime.yml is under our control (ansible/ansible) cool - if it has to happen within the unmaintained collection repo.. urm.. seems problematic
18:14:55 <bcoca> they care if they never got notice
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:06 <andersson007_> felixfontein: heh)
18:15:07 <bcoca> why 'runtime warnings' are soo important
18:15:21 <felixfontein> bcoca: they are, but we do not want to start modifying collections
18:15:31 <bcoca> samccann: runtime.yml shipped with ansible is alwasys under 'our control'
18:15:47 <bcoca> ^ but requires what felixfontein does not want to do
18:15:50 <felixfontein> bcoca: you mean the one included in ansible-core?
18:15:52 <dmsimard> bcoca: you mean the one that we are all but forbidden to touch ?
18:16:02 <samccann> heh
18:16:11 <felixfontein> or the one included in the collection that we ship in the tarball?
18:16:26 <bcoca> felixfontein: not core, the colleciton specific one, once you download it and 'add it' to the community package, you can 'add' customizations on their runtime
18:16:46 <dmsimard> ah, so patch it out of band
18:16:52 <felixfontein> bcoca: once we start modifying it, we apparently are in another legal area
18:16:54 <bcoca> since you do not have core in your package and would require modifying 'ansible-core' package install .. breaking verification, not something i would recommend
18:17:29 <felixfontein> some lawyer would have to tell us whether we can do that. and since we are still waiting for some easier questions for quite some long time, I don't think we'll get an answer for this one anytime soon :)
18:17:41 <bcoca> felixfontein:  many blurred lines there from a 'createing colleciton of things' to 'creating 'fixed' colleciton of things' .. see every distro package manager discussion list
18:17:41 <samccann> heh
18:17:45 * dmsimard sighs
18:18:17 <bcoca> i point at every distro package management workflow has 'local patches' they apply, from fedora to gentoo , bsds also
18:18:46 <jillr> can we agree that we do our very best to announce in porting guides and the bullhorn, but we can't force anyone to read those things, and we modify runtime.yml where we have repo access to do so, but we leave the software integrity/supply chain can of worms alone?
18:19:14 <felixfontein> when we want to modify things we should get advice from RH legal first
18:19:16 <dmsimard> jillr: +1 for me
18:19:31 <felixfontein> so +1 to jillr from me too
18:19:42 <hunleyd[m]> jillr: +1 for me too
18:19:57 <acozine> yep, +1 for leave the can o' worms closed
18:19:58 <bcoca> i dont forsee legal issues, since most distros do this, but it is a choice of picking up that burden or not
18:19:58 <dmsimard> jillr: though we should not assume we are able to do that even for collections under the ansible-collections org
18:20:26 <samccann> ok thinking as a user. If sometimes I get a deprecation on a pending removal and someetimes I don't, imma get mad
18:20:28 <jillr> dmsimard: sure, but in the cases where we do (community.azure for example) we can choose to do it
18:20:37 <dmsimard> right.
18:20:49 <samccann> I feel like we either 'teach' people to RTFM, or we have deprecation notices all the time
18:20:50 <jillr> samccann: oh, that's a really good point
18:23:05 <jillr> we have technical and possibly legal barriers to deprecations notices all the time, so that leaves us porting guides and the bullhorn
18:23:20 <jillr> that feels like a viable plan to me
18:23:35 <andersson007_> felixfontein: speaking about the legal - if there are no maintainers, nobody will go to court:)
18:23:37 <bcoca> i don tthink there is technical barrier (ianal so leaving legal alone) .. but it is a big burden to add
18:23:42 <jillr> andersson007_: lol
18:24:08 <bcoca> andersson007_: you'ld be suprised how maintainers 'appear' when they think they can get money from lawsuit
18:24:21 <jillr> bcoca: I meant it like, we have a technical barrier to doing something without triggering the legal gray area
18:24:23 <andersson007_> :(
18:24:24 <bcoca> its like the influx of 'cousins' when you win the lottery
18:24:52 <dmsimard> what would a deprecation look like in practice ? could it be deprecated in 5.x and removed in 6.x considering users can pin to 5.x or otherwise install the collection manually ?
18:24:58 <andersson007_> bcoca: :)
18:25:25 <jillr> dmsimard: I think so, yes
18:25:27 <bcoca> jillr: i would contest that,  rename the colleciton on install, create 'proxy colleciotn' with original name .. now you are not modifying original
18:26:00 <felixfontein> dmsimard: we can only remove in X.0, since it's a breaking change
18:26:00 <jillr> bcoca: fair, but now I call it a logistics barrier because who is doing all this work?  ;)  /me assigns the tickets to bcoca
18:26:18 <dmsimard> felixfontein: yes, sorry, I meant X.0 because we should indeed not do removals in minor versions, good point
18:26:23 <jillr> if someone signs up to do the work, no problem!
18:26:24 <felixfontein> renaming on install might quality as changing
18:26:33 <bcoca> jillr: hence my point about this being about the 'burden'
18:26:49 <bcoca> just want to make clear that the issue is not technical limitation
18:26:55 <jillr> sure, that's fair
18:27:01 <bcoca> but a NON trivial ammount of extra work
18:27:40 <bcoca> also feel free to assign me tickets, many people do .. even from other projects ... but i have about 2k in queue soo ... might wait a bit
18:29:10 <dmsimard> felixfontein: from a technical standpoint, where would we put a breaking change fragment if not inside a particular collection ?
18:29:26 <dmsimard> can we do that from ansible-build-data/antsibull ?
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:42 <felixfontein> dmsimard: in the Ansible changelog, i.e. in ansible-build-data
18:31:09 <dmsimard> ok, I'll have to check how we can do it, I've never put a standalone fragment like that before
18:31:42 * gundalow waves
18:32:38 <felixfontein> dmsimard: it's not a fragment, you have to edit changelog.yml, and we did that before, I think even when you were releasing :)
18:32:41 <felixfontein> #chair gundalow
18:32:41 <zodbot> Current chairs: acozine andersson007_[m] bcoca briantist cyberpear dmsimard felixfontein gundalow jillr samccann
18:33:10 <gundalow> Thanks felixfontein
18:33:19 <dmsimard> felixfontein: yeah I know about manually editing changelog.yml, thought there was another way
18:34:22 <felixfontein> dmsimard: so far there isn't
18:36:01 <gundalow> Release (but not collection) specific notes?
18:36:11 <acozine> Taking a quick step back, what would the goal of removing collections be? Are we just trying to be tidy? Make the package smaller? Protect users from broken functionality? Encourage maintainers to keep up with incoming issues?
18:36:24 <dmsimard> acozine: all of the above
18:37:24 <andersson007_> acozine: i'll copy your comment to the issue:) thanks for summarizing
18:37:38 <acozine> andersson007_: I put a similar comment on already
18:37:46 <andersson007_> ah, yep, i see, thanks:)
18:38:13 <acozine> This feels a bit like it should be incorporated into the approval process too. As in, when a collection applies for inclusion, we document the rules for staying in as well as the rules for getting in.
18:38:41 <acozine> A sort of "know what you're getting into here" warning.
18:38:45 <dmsimard> acozine: yes, we're working a bit backwards and we should have thought about it before IMO
18:38:46 <andersson007_> acozine: yep, this is one of the goals of the issue
18:39:12 <andersson007_> to develop the policy
18:39:14 <andersson007_> documented
18:39:25 <andersson007_> based on the issue
18:39:43 <acozine> and I'd vote for a mechanism for community feedback also - this could be part of the Bullhorn notices
18:40:25 <acozine> round one could be "this collection is unmaintained, if nobody steps forward to maintain it we will consider removing it - if you use this collection, now is the time to get involved"
18:40:41 <acozine> and round two could be "nobody stepped forward, we're starting eviction proceedings"
18:40:59 <andersson007_> users should know that a collection needs maintainers via warnings, Bullhorn, etc. to give someone a change to pick up the collection
18:41:09 <andersson007_> ie. to become a new maintainer
18:41:28 <acozine> sorry if this is in the issue already, I'm thinking this through without having read the issue in full
18:42:27 <andersson007_> sure, np
18:43:22 <andersson007_> could anyone help count votes in https://github.com/ansible-community/community-topics/issues/74 ?
18:43:39 <dmsimard> We've talked a lot about unmaintained or abandoned collections and I think there should be a distinction for removal due to other reasons -- like violation of standards (yikes) or superseded in favor of another collection (like community.azure)
18:44:35 <dmsimard> In https://github.com/ansible-community/community-topics/issues/79 there are three collections that would go under "superseded by another collection" -- I don't have a candidate for violation of standards (yet?)
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:03 <bcoca> buildable docs not a violation?
18:45:21 <dmsimard> bcoca: not sure what you mean
18:45:31 <bcoca> a colleciton has docs that cannot be built
18:45:56 <bcoca> i.e bad docs in module that break docsbuild for html pages
18:46:08 <dmsimard> perhaps, yes ? we should define those, probably guided by the inclusion standards (is there anything in the inclusion standards about making sure that docs build?)
18:46:09 <samccann> that already happens
18:46:20 <jillr> if the collection is actively maintained, we work with the maintainer to get them fixed in that case
18:46:42 <samccann> the resultant HTML page says it's broken and to open an issue on the collection I think. So the rest of it builds around that afaik
18:46:43 <bcoca> but that would be an example of violation
18:47:08 <dmsimard> bcoca: very fixable if the collection is maintained, but yeah
18:47:24 <jillr> sure, but it's easily fixed.  I've had docs breakage in my own collections, I just opened PRs to fix it.  :)
18:47:55 <bcoca> just giving an exmaple i know that has happened/is happening since he did not have one
18:47:57 <jillr> so I dont think we'd want to consider kicking out a collection for that reason, unless the maintainer refuses/fails to repsond
18:48:23 <bcoca> i would not suggest kicking for any violation unless that is the case with the maintainer
18:48:53 <jillr> ah ok, sorry I got confused
18:49:22 <dmsimard> jillr: my point was mostly being that there ought to be (at least?) three different workflows for removing a collection i.e, 1) abandoned collection, 2) superseded/replaced by another collection 3) violation of standard (that is not or cannot be fixed)
18:49:41 <bcoca> i don tthink anyone was talking 0 tollerance
18:50:49 <dmsimard> I'd like to come up with a better word than violation but my french fails me
18:50:51 <gundalow> dmsimard: yup, I think that's good. Three criteria, three approaches to solve.
18:52:03 <dmsimard> We have a little bit of time left before closing, we can revisit the topic next week after some asynchronous discussion perhaps -- do we want to talk about anything else ?
18:52:30 <andersson007_> abandonment in most cases leads to violations of standards
18:52:43 <andersson007_> e.g. to not working CI
18:52:46 <dmsimard> andersson007_: I guess
18:53:16 <dmsimard> but I mean, the outcome is different based on if it's maintained or not
18:53:27 <dmsimard> as in, can we expect the violation to be fixed or not
18:54:27 <andersson007_> should we include maintainers' responsiveness, etc. to the standards and consider such cases as violation of standards?
18:54:54 <dmsimard> good question
18:55:02 <andersson007_> (this is a late time for me, so sorry if i don't understand something)
18:55:07 <acozine> that's a gray area between "abandoned collection" and "violation of standards"
18:55:26 <acozine> in the list above, I mean
18:57:20 <felixfontein> sorry, got a bit sidetracked
18:58:04 <bcoca> dmsimard: abandoned i would consider a 'violation of standard' leaving it to 2
18:58:22 <bcoca> collections with migration path vs collection w/o migration path
18:58:52 <dmsimard> bcoca: I still see it as two different workflows -- we would ask for new maintainers in the bullhorn in the case of abandonment but not in the case of a violation, for example
18:59:42 <bcoca> true, but i would not flagged as 'abandoned' till those attempts were made and no one stepped up in a reasonable time
18:59:59 <felixfontein> also it depends on whether it is a collection 'we' control (because it is in gh.com/ansible-collections) or not
19:00:07 <dmsimard> bcoca: it's not mutually exclusive :)
19:00:11 <felixfontein> bcoca: I agree
19:00:23 <bcoca> no, but i don think the other option is 'nice'
19:03:13 <gundalow> One of my aims of hosting `community.` collections under gh/ansible-collections was so we can step in if need be
19:03:21 <felixfontein> anyway, time's up. I'll close the meeting in a minute
19:03:32 <felixfontein> please continue discussion in https://github.com/ansible-community/community-topics/issues/34 :)
19:03:48 <felixfontein> gundalow: that's a good thing!
19:03:56 <bcoca> gundalow: has pros/cons as always keeping the burden of being 'maintainer of last resort'
19:03:58 <acozine> thanks folks!
19:04:43 <felixfontein> thanks everyone!
19:04:45 <felixfontein> #endmeeting