Community Working Group Meeting Agenda

[felixfontein]

This tracks the Community Working Group meetings for Ansible.

• Meeting logs
• Invite (import by URL): ics file
• Location:
  • Matrix Room: #community:ansible.com
  • IRC Channel: #ansible-community

CC @abadger @Andersson007 @gregdek @gundalow @jamescassell

[felixfontein]

Some topics to discuss:

• [x] how often do we want new features to appear? (i.e. how often do we want to release minor versions?)

[felixfontein]

• [x] Proposal for versioning and releasing of community.general and community.network: https://gist.github.com/felixfontein/2bad8517b70008ab9be90387ee4090c8

  I created this with the assumption that features should be able to make it into a release a lot faster than now, i.e. ~once per month. After discussion with @Andersson007 I guess we need to discuss this assumption first (see above topic). Also, the dates here are essentially random picks. I scheduled the 1.0.0 release next to Ansible-base's planned 2.10 release, and put a 0.2.0 release at the end of May as a suggestion to fix a plan until then, so we can have a first version with correct deprecation version numbers and proper changelogs. I guess that will also only happen later :) But at least we have something concrete to discuss now.

[felixfontein]

First meeting on Wednesday, May 27th, at 18:00 UTC.

[samccann]

can we get this added to the ansible calendar? - https://github.com/ansible/community/blob/master/ansible_community_meetings.ics

[jamescassell]

in last Thursday's Core meeting, it was suggested to discuss these here:

1. [x] glossary of terms in the New World Order (and simplification/deconflict as appropriate) ACD, ansible-base, ansible-core, etc
2. [x] do more to involve the community in /designing/ future changes (not just implementing) (ansible-devel mailing list?)
3. [ ] better docs for /design/ of collections, even after the fact

[felixfontein]

Summary of today's discussion (with "community collections", I mainly mean community.general and community.network):

1. community collections should use semver;
2. breaking changes (i.e. new major releases) every 6 months;
3. new features (i.e. new minor releases) every 2 months;
4. deprecation by version number (not by date).

The numbers 6 and 2 can be adjusted in the future. Also, ACD will use similar version numbers to pre-ansible-base's ansible for now, that discussion can continue once 2.10.0 has been released.

[felixfontein]

For details:

Meeting ended Wed May 27 19:52:12 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-05-27/community_working_group.2020-05-27-18.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-05-27/community_working_group.2020-05-27-18.00.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-05-27/community_working_group.2020-05-27-18.00.log.html

[gundalow]

python3 meetings/read_minutes.py https://meetbot.fedoraproject.org/ansible-community/2020-05-27/community_working_group.2020-05-27-18.00.txt

2020-05-27

Community.(general,networking) versioning, releasing and deprecation

• felixfontein's proposal for Versioning, deprecation and changelogs for community.general and community.network https://gist.github.com/felixfontein/2bad8517b70008ab9be90387ee4090c8
• https://github.com/ansible/community/issues/539#issuecomment-634846106
• :+1: 6 month major release for community.general and community.network. Other collections can release at their own cadence. This maybe revisited in the future.
• :+1: derecation per version for c.g and c.n (5 votes for version; 9 attending, 0 opposed)
• You can see the list of Collections which make up Ansible 2.10 in https://github.com/ansible-community/ansible-build-data/blob/master/2.10/acd.in

next meeting

• We will meet again next Wednesday

Actions

• [X] @gundalow Setup this meeting https://github.com/ansible/community/pull/540
• [ ] @samccann to start a tracking docs issue on what ansible-base has for

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-05-27/community_working_group.2020-05-27-18.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-05-27/community_working_group.2020-05-27-18.00.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-05-27/community_working_group.2020-05-27-18.00.log.html

[felixfontein]

I've adjusted the proposal (https://gist.github.com/felixfontein/2bad8517b70008ab9be90387ee4090c8); minor versions are now every two months, and dates are not fixed (except for the next releases).

[abadger]

We need to have a policy around backwards compatibility in Ansible. I think the basic policy is simple:

• We attempt to make any Ansible-2.y.(n+1) backwards compatible with any previous Ansible-2.y.n.. Ansible-2.(y+1),z will almost certainly contain backwards incompatibilities with Ansible-2.y.
• We do this by only shipping updates to a collection if the semantic version specifies that the update is backwards compatible.

There is a corner case, though:

• [x] What should our policy be for collections whose semantic version is 0.z.y? I lay out the problems and possible solutions here: https://github.com/ansible-community/antsibull/issues/70

[felixfontein]

Discussion of versioning for community.general and community.network (proposal at https://gist.github.com/felixfontein/2bad8517b70008ab9be90387ee4090c8), more discussion points:

1. Branching and Backporting
   • Release from master, or from release branch (as ansible/ansible)?
   • Backporting automatically (by maintainers via bot) until last minor release, or manually (as ansible/ansible)?
2. How long will bugfixes be backported? (I.e. how long do we want to support old releases?)
3. Length of standard deprecation cycle? (4 major versions, i.e. 2 years, or less?)

I hope that we can get this done today, so we can actually plan a first proper release soon :)

[felixfontein]

Meeting ended Wed Jun 3 19:25:55 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-06-03/ansible_community_working_group.2020-06-03-18.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-06-03/ansible_community_working_group.2020-06-03-18.00.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-06-03/ansible_community_working_group.2020-06-03-18.00.log.html

Summary of decisions for versioning:

• community.general and community.network will release from release branches (stable-1, stable-2, ...)
• backports are merged by bot (maintainer shipit), and potentially also created by the bot
• feature backports are only accepted for current major version (will be evaluated and discussed again by the end of the year, when 2.0.0 comes closer)
• bugfixes will be backported to the last two major versions, only security and major bugfixes ported to the last three major versions (will be evaluated and discussed again by the end of the year)

[felixfontein]

Questions still open:

• length of deprecation cycle? ~1 year (2 major versions)? ~2 years (4 major versions)?
• who will merge bugfix backports? (bot? RM?)
• who will merge critical bugfixes and security fixes? (bot? RM?)

• how should Ansible versions (for deprecation) be mapped to collection versions? Proposal:

  • 11 -> 2.0.0 (January 2021)
  • 12 -> 3.0.0 (July 2021)
  • 13 -> 4.0.0 (January 2022)
  • 14 -> 5.0.0 (July 2022)

  (If we shorten the deprecation cycle, this should be condensed. Maybe 11 and 12 to 2.0.0, 13 and 14 to 3.0.0?)

• Changelog fragments:
  • one changelog fragment for every PR (with trivial category)?
  • one changelog per major version, or a continuous changelog?
  • keep fragments in repository, or delete them (changelog.yaml would be full source of truth)?

[felixfontein]

Meeting ended Wed Jun 10 19:21:25 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-06-10/community_working_group.2020-06-10-18.04.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-06-10/community_working_group.2020-06-10-18.04.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-06-10/community_working_group.2020-06-10-18.04.log.html

Summary of decisions for versioning of community.general and community.network:

• Deprecation cycle:

  • at least 2 major versions;
  • maintainers can choose a later major version for removal if they want;
  • current Ansible deprecation/removal versions should be mapped as follows:
  • 2.11 and 2.12 will map to 2.0.0 (~January 2021)
  • 2.13 and 2.14 will map to 3.0.0 (~July 2021)
  • the old Ansible removal version will be kept as a comment, so maintainers can choose to bump the collection version accordingly if they want to support that feature longer than ~Jan/Jul 2021

• Changelog:

  • we have one changelog per major version (as ansible/ansible); the ancestor of one changelog points to the previous major release (x.0.0)
  • changelog fragments are removed after every release (contents are in changelog.yaml)

• Releasing:

  • 0.2.0 will be released a couple of days after ansible-base 2.10 beta has been released
  • 0.2.0 will include a changelog, correct version_added values (0.2.0), and correct deprecation/removal versions
  • 0.2.0 will be released directly from master, there won't be a release branch for it (i.e. no backporting necessary until 1.0.0 is out)

[felixfontein]

Questions for next week:

1. Version 1.0.0:

   • is release by end of July fine?
   • two week freeze, with one or two RC releases (1.0.0-rc1, and maybe 1.0.0-rc2)?

2. Changelog: should every PR have a fragment?

   • Background: antsibull-changelog has a trivial category which is recorded in the changelog.yaml, but not contained in the generated .rst file
   • Allows to have automated check for "at least one changelog fragment per PR", without cluttering changelog with "Temporarily disabled foo tests in CI" and "Fixed typo in feature from yesterday which hasn't been released yet".

After that, we can continue with other issues, like the questions @jamescassell asked in https://github.com/ansible/community/issues/539#issuecomment-634846106, and discussions about ACD itself (like @abadger's https://github.com/ansible/community/issues/539#issuecomment-638230501).

[abadger]

I have another policy question about the ansible package. ansible-2.10 is going to ship with a dependency on ansible-base-2.10.x. As we make new minor releases of the ansible package, should those newer versions allow any ansible-base package to be installed or should it require updating to at least the latest ansible-base package at the time the ansible package was release?

There's examples of the two scenarios in the ticket:

https://github.com/ansible-community/antsibull/issues/94#issuecomment-643451914

• [x] decided: ansible 2.10.x should depend on ansible-base >= 2.10.y, where 2.10.y is the latest ansible-base release on ansible 2.10.x build time

[felixfontein]

• [x] Proposal: Ansible should use semver (ansible/proposals#179). IMO too late for 2.10, but we should discuss this for 2.11 (which would then be 3.0.0).

[felixfontein]

Meeting ended Wed Jun 17 19:20:12 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-06-17/ansible_community_meeting.2020-06-17-18.07.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-06-17/ansible_community_meeting.2020-06-17-18.07.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-06-17/ansible_community_meeting.2020-06-17-18.07.log.html

Summary of decisions for versioning of community.general and community.network:

• 1.0.0 to be released in last week of july (might slip if ansible-base RC1 hasn't been released by then), 2.0.0 for somewhen in January 2021, 3.0.0 somehwn in mid 2021, 4.0.0 in beginning of 2022, etc.
• 1.0.0 is released with no freeze
• if necessary, we deviate from the minor release cycle, especially when an ansible release is coming up, to get bugs fixed
• we eventually want to enforce "every PR has a changelog fragment" (use trivial category if it's nothing that should end up in the changelog.rst file), but this is low priority right now

[felixfontein]

• [x] should the symlinks in community.general and community.network be removed? if yes, for which version: 1.0.0, 2.0.0, or even later? (removing them essentially breaks Ansible 2.9 compatibility)

[felixfontein]

2020-06-24

https://github.com/ansible/community/issues/539#issuecomment-638230501

• https://github.com/ansible-community/antsibull/issues/70
• Writeup of the problem and potential solutions: https://github.com/ansible-community/antsibull/issues/70
• gundalow's todo list contains chasing ansible (as in ACD) collection owners to make sure they have a proper (as in: pass sanity checks, galaxy.yml correct, versioned correctly, etc.) release out "soon" (or not too late)
• we decided on option 5: allow upgrades in 0.y.z, but collection owner must request that manually
• goal is still to have 1.0.0 or newer for every collection

Actions

• [ ] @abadger to open a ticket to explore how prereleases liek
• [ ] @abadger to also figure out if we can exclude prereleases from the
• [ ] @gundalow to ensure that some people from Ifty's team are aware and

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-06-24/ansible_community_meeting.2020-06-24-18.02.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-06-24/ansible_community_meeting.2020-06-24-18.02.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-06-24/ansible_community_meeting.2020-06-24-18.02.log.html

[felixfontein]

2020-07-01

What version of ansible-base should ansible depend on?

• Pro: changelog included in the latest ansible-2.10.x will be for the latest ansible-base
• Pro: most collections will test against the latest ansible-base-2.10.x
• Con: Prevents users from choosing to use the ansible packaged collections with an older version of ansible-base.
• ansible 2.10.x should depend on ansible-base >= 2.10.y with latest y that was around when ansible 2.10.x was built (4 yes, 1 no)

Should symlinks in c.g and c.n be removed for 1.0.0, or for later?

• community.network and community.general will (try to) support ansible 2.9 at least for the 1.x.y releases

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-07-01/community_working_group_meeting.2020-07-01-18.04.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-07-01/community_working_group_meeting.2020-07-01-18.04.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-07-01/community_working_group_meeting.2020-07-01-18.04.log.html

[Andersson007]

@felixfontein irccloud that i use is down so i'm asking here: what's the agenda for today's meeting? (hope irccloud will become alive by 18 UTC)

[felixfontein]

@Andersson007 right now there's one proposal of interest (https://github.com/ansible/community/issues/539#issuecomment-643764618) and two questions by cyperpear (https://github.com/ansible/community/issues/539#issuecomment-634846106). And maybe some current problems related to Ansible 2.10 (I haven't been able to pay much attention yesterday and today, so I don't know if there are some surprise topics :) ).

[felixfontein]

• [x] how should moving content between collections after 2.10 work exactly?
  • I guess right now we remove it and add a redirect, 1-2 major version later add a deprecation warning, and then two major releases later remove it.
  • Do we add the destination collections as dependencies while the direction is there?

(Related: ansible-collections/community.general#623)

[samccann]

In order to run the bot that will close all the collection-related issues/PRs, we need movement on:

• [x] https://github.com/ansible/ansibullbot/issues/1391

• [x] Appropriate edits to https://github.com/ansible/ansibullbot/blob/master/docs/collection_migration.md

• [x] all collections that are part of Ansible 2.10 must be in galaxy.

[felixfontein]

Minutes from last week's meeting:

2020-07-08

Updates

• Lots of branches have swapped to main, we've seen zero issues so far
• New Collections: community.digitalocean & community.proxysql are running, community.mysql will be done shortly
• ansible 2.10 alpha2 has been released
• Theres been great progress in updating all the collections included in 2.10 to use FQCN in documentation M() and SEEALSO, each repo will have an issue tracking what needs doing
• https://github.com/ansible-collections/community.azure/issues/4
• :+1: infoblox and infinidat are being included from communtiy.general for ansible-2.10, even though their collections exist, they are not correct (and missed the deadline) https://github.com/infobloxopen/infoblox-ansible/issues/7 https://github.com/Infinidat/ansible-infinidat-collection/issues/1
• Contributor Summit Summary: https://meetbot.fedoraproject.org/ansible-community/2020-07-06/ansible_contributors_summit.2020-07-06-10.57.html
• Contributor Summit Log: https://meetbot.fedoraproject.org/ansible-community/2020-07-06/ansible_contributors_summit.2020-07-06-10.57.log.html
• Contributor Summit Videos: https://www.youtube.com/playlist?list=PL0FmYCf7ocrbmgUsXJFqJrIKQRg9hz02h

https://github.com/ansible/proposals/issues/179

• We will add proposals to The Bullhorn so they get a wider audiance. This includes Community, Content Team, etc
• :+1: we will revisit ansible-base vs semver (proposal#179) two months after Ansible 2.10 has been released
• https://github.com/ansible-collections/overview/pull/82

open floor

• ANSIBLE IS HIRING FOR THE COMMUNITY TEAM
• If you would like to know more, feel free to ping me

Actions

• [ ] @gundalow to finish

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-07-08/ansible_community_meeting.2020-07-08-18.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-07-08/ansible_community_meeting.2020-07-08-18.00.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-07-08/ansible_community_meeting.2020-07-08-18.00.log.html

[felixfontein]

2020-07-15

https://github.com/ansible-collections/overview/issues/88

• https://github.com/ansible-collections/overview/pull/90
• use https://github.com/ansible-collections/overview/pull/90 to list the requirements for collections to be in Ansible

Actions

• [ ] @felixfontein write a few lines on how paths and imports change when
• [x] @abadger will consult robyn about getting the schedule into the next
• [ ] @acozine to get
• [ ] create issues in collection repos once we have the checklist merged

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-07-15/ansible_community_meeting.2020-07-15-18.01.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-07-15/ansible_community_meeting.2020-07-15-18.01.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-07-15/ansible_community_meeting.2020-07-15-18.01.log.html

[felixfontein]

Appendum to the minutes from last week: the infinidat collection got done and the modules moved on the day of the deadline. infoblox did miss the deadline.

[felixfontein]

• [x] when exactly to release 1.0.0 of c.g and c.n? (Suggestion: July 31st)

[felixfontein]

2020-07-22

Release 1.0.0 of community.general and community.network

• c.general and #c.network need have correctly generated plugin docs before we release 1.0.0
• https://github.com/ansible-community/antsibull/issues/147
• :+1: c.g and c.n 1.0.0 will be released on Friday, July 31st
• antsibull-docs CLI change: Rename --ansible-base-cache to --ansible-base-source
• antsibull-build CLI change: Remove the redundant build- prefix from antsibull-build subcommands
• both antsibull-docs and antsibull-build file format change: Renaming "acd" fields to "ansible" and renaming default filenames in the same way.
• the changes that affect antsibull-docs will operate with backwards compatibility for at least a few weeks [probably until after 2.10.0 is released]
• Question1: Which freeze date determines the major version of collections that will go into Ansible-2.10 (abadger1999 suggests beta freeze date)?
• Question2: Will either new minor releases or patch releases of collections be allowed between RC1 and GA of 2.10.0 (abadger1999 suggests no, but might need ask to adjust the rc->GA dates in that case)?
• https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/ROADMAP_2_10.rst should link to the new ansible (add) roadmap
• :+1: ansible roadmap will live alongside ansible-base roadmap (which needs renaming)

Module versioning

• http://docs.testing.ansible.com/ansible/2.10/collections/wti/remote/cpm_interface_config_module.html#ansible-collections-wti-remote-cpm-interface-config-module
• https://github.com/wtinetworkgear/wti-collection/blob/master/wti/remote/plugins/modules/cpm_interface_config.py#L31
• https://github.com/ansible/community/issues/521#issuecomment-624153545

Actions

• [x] @felixfontein write instructions for how to do major release (and maybe also minor / patch releases) for c.g and c.n → https://github.com/ansible/community/wiki/ReleasingCollections
• [x] @felixfontein announce 1.0.0 date in repo issues
• [x] @samccann mention collection docs, 1) what to check for 2) where to report issues 3) that we know c.general is broken 4) anything else on https://github.com/ansible-collections/overview/issues/45 (changes impacting contributors)
• [ ] @abadger do not release a new alpha on Thursday July 30th, but wait until Friday July 31st
• [x] @samccann acozine republish 2.10 on Fri July 31 (after c.g release an ansible alpha release)
• [x] @abadger to get clarification from rbergeron about some of th edates and milestones
• [x] @samccann add to the collection checklist that version_added should not say 2.10, but should say collection version

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-07-22/ansible_community_meeting.2020-07-22-18.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-07-22/ansible_community_meeting.2020-07-22-18.00.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-07-22/ansible_community_meeting.2020-07-22-18.00.log.html

[felixfontein]

2020-07-29

https://github.com/ansible/community/issues/539

• ansible/ansible#82 is merged
• :+1: we SUGGEST collections should make sure that removals happen at least two ansible versions after the deprecation (or one, if the deprecation happens in 2.x.0) (6 x yes, 0 x no)

https://github.com/ansible-collections/overview/issues/88

• https://docs.ansible.com/ansible/devel/community/development_process.html#changelogs

Actions

• [x] @abadger to draft and send a schedule email.
• [x] @felixfontein rebase ansible-collections/overview#82
• [ ] @acozine to massage the schedule email into a roadmap page once it is approved and sent.

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-07-29/ansible_community_meeting.2020-07-29-18.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-07-29/ansible_community_meeting.2020-07-29-18.00.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-07-29/ansible_community_meeting.2020-07-29-18.00.log.html

[felixfontein]

Tentative schedule for Ansible 2.10 has been published: https://groups.google.com/forum/#!topic/ansible-devel/srweNQ92pJw

[felixfontein]

• [x] ansible-collections/overview#94
• [x] https://gist.github.com/felixfontein/65a86c4fe47e9c645eebadd52d8b0d5c
• [x] https://github.com/ansible/community/issues/539#issuecomment-656098926
• [x] 1.1.0 release for c.g and c.n on 2020-08-14?

[jamescassell]

• [x] Moving content between collection - does it have to be aligned to a major release? carry "deprecated" copy in old location until next major release?

[felixfontein]

@jamescassell I guess that's related to https://github.com/ansible/community/issues/539#issuecomment-656098926. IMO the removal and adding of the redirect must happen in a major release, since it breaks backwards compatibility (except maybe if you add the new location as a dependency to your collection - then it "only" breaks for Ansible 2.9).

[Andersson007]

(i don't know maybe the following questions were brought up already / irrelevant. Need to know) the number of collections is growing, maintainers come and go, so

• [ ] should we check anyhow whether a collection is released regularly? maybe by automation. Collection maintainers can stop maintainig, etc., people do work, so collections should be released, provided that there are merged things since the last release. Should we monitor this? Maybe automatically create an issue that contains something like "The collection hasn't been released for more than 2 months and it doesn't feel good .."
• [ ] if there are a lot of PRs but no merges (and no feedback from maintainers), what should we do? Should we monitor somehow such situations: PR num open vs PR num merged from the last release, etc.?
• [ ] if maintainers stop releasing (and maintaining) their collections, should we release the collections (that we control) ourselves? Maybe i missed something and it'll be released automatically.
• [ ] any other potentially not good things related to abandoned collections?

Thanks

[felixfontein]

• [x] test requirements for new modules/plugins in community.general and community.network - do we accept unsupported integration tests as the only set of tests for a module/plugin?
• [x] do we want to define a set of exceptions? (f.ex. tests for shutdown plugin are very non-trivial, the reboot plugin in ansible-base has no tests either because of that)

[GregSutcliffe]

I'm happy to help build stats tools for this kind of thing. Things we already have:

• https://stats.eng.ansible.com/~/admin/community.general.prs.html for community.general, could be generalized
• https://stats.eng.ansible.com/~/admin/CollectionsRank/ my start on a set of tooling across all collections (unfinished :p)

I think we need to agree some starting heuristics for collections, and I can build some visualization of that. Once we start using it, we can iterate as most metrics are not going to fit all collections - we'll start to see where the heuristics fail and do better.

Happy to discuss in detail at a future IRC meeting. In the meantime, I'll work on getting a public repo set up to hold the tools, so we have a dedicated place to discuss the details.

[felixfontein]

• [x] what to do with gluster.gluster? (related to content moving)
  • https://github.com/ansible-collections/community.general/issues/761
• [x] how should we get backporting for c.g/c.n started?

[Andersson007]

@felixfontein

0. could we use anything instead of gluster.gluster to avoid FQCNs like gluster.gluster.gluster_info?

also to think it over in advance:

1. what to do with gluster.gluster? (related to content moving) . are there any related issues / options?
2. how should we get backporting for c.g/c.n started? any issues / options available now?

[felixfontein]

@Andersson007

1. I guess we can include it in Ansible 2.10, but we can probably neither update ansible-base's ansible_builtin_runtime.yml anymore, nor can we remove the modules from community.general 1.x.y (since that would be a breaking change IMO).
2. Right now, the only option is "manual". We can do it via individual PRs though, or just git cherry-pick -x from main to stable-1.

[abadger]

I added a ticket for the gluster issue ( https://github.com/ansible-collections/community.general/issues/761 ) since it seems like there's a lot to discuss. I put the link to it in felixfontein's agenda item for it.

[felixfontein]

2020-08-12

agenda: https://github.com/ansible/community/issues/539 (felixfontein, 18:02:35)

Backports

moving content between collections after 1.0.0 is released, and the gluster collection (felixfontein, 18:18:04)

• summary of situation (for gluster): https://github.com/ansible-collections/community.general/issues/761
• https://gist.github.com/felixfontein/2876b20d632edebc3c7157559eda1bc0
• the plan for gluster.gluster is: . 1) include gluster in ansible 2.10.0, 2) adjust ansible_builtin_runtime.yml for ansible-base 2.10.1 to redirect gluster modules to the gluster collection, 3) delay ansible 2.10.0rc1 until ansible-base 2.10.1 has been released?
• community.general will deprecate the gluster modules for removal in 2.0.0
• we add redirects for the gluster modules in 2.0.0 without deprecation, and revisit this question (about removing them eventually, with or without a deprecation) somewhen after 2.0.0 has been released (6 x +1, 1 x abstain)

open floor

Actions

• [ ] @abadger will talk to the core team about ansible-base-2.10.1 blocking the release of ansible-2.10.0
• [ ] @abadger will let robyn know of potential to slip if ansible-base-2.10.1 isn't released before ansible-2.10.0rc1
• [x] @abadger will add gluster.gluster to the ansible-2.10 collections
• [x] @felixfontein adjust ansible_builtin_runtime.yml to redirect gluster modules to gluster.gluster

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-08-12/ansible_community_meeting.2020-08-12-18.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-08-12/ansible_community_meeting.2020-08-12-18.00.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-08-12/ansible_community_meeting.2020-08-12-18.00.log.html

[gundalow]

• [x] Hacktoberfest meetup 2020

[gundalow]

• [x] Some sort of longer message about how policies are changing

[Andersson007]

Related to https://github.com/ansible/community/issues/539#issuecomment-669849223 and https://github.com/ansible/community/issues/539#issuecomment-670386710 by @GregSutcliffe

For collections in github.com/ansible-collections would be good to see:

1. collections that haven't been released for some time (e.g. for the last 2 months), a web page maybe with a table and collections marked green means released regularly, blue means generally ok, red means hasn't been released for a long time or something. The table could also contain fields with last major/minor/fix release dates (if it's possible to track). Maybe something else.
2. other ways to identify abandoned collections using any kinds of visualization?
3. should we release abandoned collections ourselves?
4. should we announce anyhow that a collection needs new maintainers?

[gundalow]

Testing of Ansible 2.10 beta

• [x] What needs testing
• [x] Where to advertise/promote

[GregSutcliffe]

I've gone ahead and created https://github.com/ansible-community/stats-collections so that we can log anything that comes up in discussions.

1. collections that haven't been released for some time (e.g. for the last 2 months), a web page maybe with a table and collections marked `green` means `released regularly`, `blue` means `generally ok`, `red` means `hasn't been released for a long time` or something. The table could also contain fields with `last major/minor/fix` release dates (if it's possible to track). Maybe something else.

I'll have to check the GH API around releases, but I think it likely we can do something. The bigger is issue is that different collections will have different release timing - so we can't use a one-size-fits-all heuristic here. We'd probably need to calculate the average frequency and then ask ourselves if the collection is way beyond that (a little beyond is ok, ofc)

2. other ways to identify abandoned collections using any kinds of visualization?

There's a few ways to do this - frequency of commits, PRs, comments, etc. The challenge is to separate "abandoned" from "stable and doesn't need work". The key difference, I expect, is in number of open Issues and the time-to-close on those Issues - abandoned projects won't respond to Issues, so they'll have more and with a longer close time.

I have some data on time-to-merge, re-doing it for Issues (merge == PRs of course) is easy enough.

[felixfontein]

2020-08-19

agenda: https://github.com/ansible/community/issues/539 (felixfontein, 18:05:09)

Testing ansible

• As we are getting close to ansible 2.10, we need to get extra help from people to test the new ansible package
• https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases#bugs-in-modules-and-plugins has some details
• https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases#known-bugs

Collection Policies

• https://github.com/ansible/community/issues/556
• https://github.com/ansible-collections/overview/blob/master/collection_requirements.rst also contains some of them, it should definitely be linked

should/must new modules and plugins for community.general / community.network have tests? tests running in CI? (felixfontein, 19:02:58)

• consensus that new modules/plugins MUST have tests
• vote needed whether tests MUST run in CI, or SHOULD
• definition of "basic" needed for tests

Actions

• [ ] @gundalow merge https://github.com/ansible/ansible/pull/71357
• [ ] @gundalow reddit release announcement + https://github.com/ansible/community/wiki/User-testing-of-ansible-2.10-pre-releases
• [ ] @gundalow to create Etherpad for policy, assign meeting logs
• [ ] @gundalow to setup meeting, maybe felixfontein & cyberpear (EDT) could help?

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-08-19/ansible_community_meeting.2020-08-19-18.00.html Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-08-19/ansible_community_meeting.2020-08-19-18.00.txt Log: https://meetbot.fedoraproject.org/ansible-community/2020-08-19/ansible_community_meeting.2020-08-19-18.00.log.html

[felixfontein]

Open topics from above:

• continuing from last time: test requirements for c.g / c.n (https://github.com/ansible/community/issues/539#issuecomment-670352844)
  • continuation of discussion in https://meetbot.fedoraproject.org/ansible-community/2020-08-19/ansible_community_meeting.2020-08-19-18.00.html
• moving content between collections after 2.10? (https://github.com/ansible/community/issues/539#issuecomment-656098926, https://github.com/ansible/community/issues/539#issuecomment-669279701)
  • continuation of discussion in https://meetbot.fedoraproject.org/ansible-community/2020-08-12/ansible_community_meeting.2020-08-12-18.00.html
• inactive collection maintainers (https://github.com/ansible/community/issues/539#issuecomment-669849223)