Giters

ansible / community

This repository is being archived. See https://github.com/ansible-community/presentations and https://github.com/ansible-community/meetings for the new locations

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Community Working Group Meeting Agenda

felixfontein opened this issue Β· comments

commented

This tracks the Community Working Group meetings for Ansible.

CC @abadger @Andersson007 @gregdek @gundalow @jamescassell

commented

Some topics to discuss:

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

  • 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.

commented

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

commented

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

  1. glossary of terms in the New World Order (and simplification/deconflict as appropriate) ACD, ansible-base, ansible-core, etc
  2. 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
commented

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.

commented

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

next meeting

  • We will meet again next Wednesday

Actions

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

commented

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).

commented

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:

  • What should our policy be for collections whose semantic version is 0.z.y? I lay out the problems and possible solutions here: ansible-community/antsibull#70
commented

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 :)

commented

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)
commented

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)?
commented

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)
commented

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 #539 (comment), and discussions about ACD itself (like @abadger's #539 (comment)).

commented

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:

ansible-community/antsibull#94 (comment)

  • 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
commented
  • 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).
commented

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
commented
  • 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)
commented

2020-06-24

#539 (comment)

  • ansible-community/antsibull#70
  • Writeup of the problem and potential solutions: ansible-community/antsibull#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

commented

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

commented

@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)

commented

@Andersson007 right now there's one proposal of interest (#539 (comment)) and two questions by cyperpear (#539 (comment)). 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 :) ).

commented
  • 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)

commented

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

commented

Minutes from last week's meeting:

2020-07-08

Updates

ansible/proposals#179

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

open floor

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

Actions

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

commented

2020-07-15

ansible-collections/overview#88

Actions

  • @felixfontein write a few lines on how paths and imports change when
  • @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

commented

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.

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

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
  • ansible-community/antsibull#147
  • πŸ‘ 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
  • πŸ‘ ansible roadmap will live alongside ansible-base roadmap (which needs renaming)

Module versioning

Actions

  • @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
  • @felixfontein announce 1.0.0 date in repo issues
  • @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 ansible-collections/overview#45 (changes impacting contributors)
  • @abadger do not release a new alpha on Thursday July 30th, but wait until Friday July 31st
  • @samccann acozine republish 2.10 on Fri July 31 (after c.g release an ansible alpha release)
  • @abadger to get clarification from rbergeron about some of th edates and milestones
  • @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

commented

2020-07-29

#539

  • ansible/ansible#82 is merged
  • πŸ‘ 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)

ansible-collections/overview#88

Actions

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

commented

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

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

@jamescassell I guess that's related to #539 (comment). 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).

commented

(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

commented
  • 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?
  • 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)
commented

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

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.

commented
commented

@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?
commented

@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.
commented

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

commented

2020-08-12

agenda: #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): ansible-collections/community.general#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
  • @abadger will add gluster.gluster to the ansible-2.10 collections
  • @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

commented

Related to #539 (comment) and #539 (comment) 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?
commented

Testing of Ansible 2.10 beta

  • What needs testing
  • Where to advertise/promote
commented

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.

commented

2020-08-19

agenda: #539 (felixfontein, 18:05:09)

Testing ansible

Collection Policies

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

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

commented

Open topics from above:

commented

2020-08-26

current state

  • release scripts are ready for beta
  • collection's minor version is frozen for 2.10.0, only patch releases are accepted
  • most collections for 2.10 have changelogs, but there's still a larger bunch which does not
  • only chance to include changelog after minor version freeze is to make a patch release (increase only z in x.y.z) before the final freeze

Logs

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

commented

This github project comes with a git repository! It's still using master as the default branch name. Need to identify who to talk to about renaming it: #558

commented

2020-09-02

Updates

  • Ansible 2.10.0b1 has been released - features are now frozen for 2.10.0
  • Not sure if others saw, though we have 3,000+ people that are interested in attending Contributors Summit (which is an increase from the ~150)
  • We are planning for two days of Contributors Summit. Monday will mostly be pre-recorded videos with Q&A. Thursday will be possibly more interactive
  • Please register for AnsibleFest https://www.ansible.com/ansiblefest

What to do with/about inactive #539 (comment) (felixfontein, 18:27:45)

Actions

  • @fest Video: 1) Brand new GitHub (no fork of collection), click Edit on GitHub 2) Fix typo 3) Create PR 4) Wait for CI 5 ) 6) Success
  • @fest Video: Overview of IRC (maybe show via Matrix.im) 1) How to register (or does Matrix do this for you) 2) #ansible (user) #ansible-devel & #ansible-community 3) Don't ping Just ask the question
  • @samccann - open a docs issue for a 'getting started developing in ansible' guide
  • @samccann acozine to review / participate in orphan discussion - https://gist.github.com/gregdek/52e6669421d3f65cded51862e16ad0e9

Logs

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

commented
commented

2020-09-09

updates

  • ansible-base 2.10.1 was delayed by one week, which means that the ansible 2.10.0rc1 will also get delayed by one week (now planned for 2020-09-15)
  • ansible 2.10.0 release is currently planned for 2020-09-22
  • https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst also says 17
  • meeting at 2020-09-17 18:00 UTC about whether there are blockers for ansible 2.10.0
  • rc1 means complete freeze, except for blockers: i.e. even if we have another rc, collections will only get updated if needed to remove blockers
  • that means no patch releases in any collections after RC1 is created, unless it fixes a blocker

test requirements for new plugins/modules

  • For new modules/plugins in community.general and community.network, we require tests, which SHOULD run in CI whenever possible (6 x +1, 1 x abstain)

open floor

Actions

  • @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-09-09/ansible_community_meeting.2020-09-09-18.00.html
Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-09-09/ansible_community_meeting.2020-09-09-18.00.txt
Log: https://meetbot.fedoraproject.org/ansible-community/2020-09-09/ansible_community_meeting.2020-09-09-18.00.log.html

commented

A reminder for everyone interested, in case you're confused:

  • there's a regular community meeting today (2020-09-16) at 18:00 UTC in #ansible-community (Freenode), which does not discuss potential blockers for the Ansible 2.10.0 release;
  • there's a special community meeting tomorrow (2020-09-17) at 18:00 UTC in #ansible-community (Freenode) which does discuss potential blockers for the Ansible 2.10.0 release.
commented

2020-09-16

agenda #539 (comment) (felixfontein, 18:01:37)

updates

moving content between collections after 2.10 (#539 (comment)) (felixfontein, 18:15:40)

  • Content moving out of community.general (and community.network) into dedicated collections is generally a good thing assuming there is a set of new maintainers
  • πŸ‘ 1) deprecate module/plugin once it has been added to the target collection and that has been released (as a minor release that will also get included in the next Ansible version), with removal scheduled for the next major version; 2) in next major version, remove module/plugin and add redirect with deprecation that has no removal date/version; 3) in 1-2 years, revisit these redirects
  • to discuss: what happens when the target collection is (not yet) contained in Ansible?
  • discussion will be continued next time :)

Logs

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

commented

Criteria for including new collections in Ansible 2.11

I expect this (and in fact require this) to take a while to get signed off.

  • How can we decide the criteria
  • What should the criteria be
  • For each, how is it enforced
  • What happens if content starts failing, do we remove in the he next major
commented

There's a new PR for removing content from c.g to a collection that's not (yet) in Ansible: ansible-collections/community.general#948

commented

Criteria for including new collections in Ansible 2.11

I expect this (and in fact require this) to take a while to get signed off.

  • How can we decide the criteria
  • What should the criteria be
  • For each, how is it enforced
  • What happens if content starts failing, do we remove in the he next major

After the criteria are decided, we should add them to ansible_collections/overview (put the ref to Collections checklist). Later, a special person will scrutinize suggested collections on the proposal stage according to the list.

Imo, first of all, collections must follow:

  1. Ansible documentation format and conventions,
  2. security conventions, e.g. use special provided methods like module_utils.fetch_url/open_url instead of bare urllib, etc.,
  3. they must pass sanity tests
  4. not sure, maybe they should be published on galaxy for some time before inclusion, have a release policy, permanent maintainers, etc.

Not to make criteria too tight is also important.

commented

2020-09-23

Ansible 2.10.0 RELEASED

moving content between collections after 2.10

  • ansible/ansible#71854 | open, created 2020-09-22T07:30:22Z by Andersson007: Docsite: update Migrating Ansible content to a different collection [affects_2.11,core_review,docs,docsite,needs_triage,support:core]
  • ansible/ansible#71854 | open, created 2020-09-22T07:30:22Z by Andersson007: Docsite: update Migrating Ansible content to a different collection [affects_2.11,core_review,docs,docsite,needs_triage,support:core]
  • ansible/ansible#71875 | open, created 2020-09-23T08:46:40Z by rajeevarakkal: Update Botmeta and runtime file to reflect the dellemc collections path [affects_2.11,botmeta,core_review,docs,needs_triage,runtime,support:core]

Documentation of Ansible Project Policies

  • proto-proposal: Push all policy documentation to docs.ansible.com
  • some parts of docs.ansible.com have a workflow to stub older releases to point to devel as the release-independent version of those docs.
  • ptoto-proposal: policies that we move to docs.ansible.com should follow this workflow so that there's one version for all of ansible project.
  • likely will still want a checklist like we have in ansible-collections/overview, but have it live on docs.ansible.com as a release-independend document
  • see https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ for an example
  • issue for 'move overview docs over to official docs' - ansible/ansible-documentation#86

ansible/ansible-documentation#86 -- Move policies to docs.ansible.com with partial policies around managing that content (see issue for details) (abadger1999, 19:18:44)

  • POLL: We will move policies to docs.ansible.com using the policies in ansible/ansible-documentation#86 for managing that content
  • 71890 (move policies to docs.ansible.com) approved with +6, none opposed.

Open floor

Actions

Logs

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

commented

Current topics:

  1. Moving content between collections after 2.10 (when source is in Ansible, but destination is not yet)
  2. Criteria for including new collections in Ansible 2.11
commented

Should we build ansible nightlies? If so, where should they live? ansible-community/antsibull#195

commented

2020-09-30

#539 (comment) (felixfontein, 18:02:22)

updates

  • community.network 1.2.0 has been released today, community.general 1.2.0 will follow later today
  • there's a new sanity test in ansible-test which makes sure that version_added is never a patch version, and removal versions are never minor or patch versions
  • github.com/ansible/* will be moving from Shippable to Azure Pipelines soon (ie next month or two)
  • github.com/ansible-collections/* can continue to use Shippable for a while, though we can move to Azure Pipelines as well and benefit from a much larger node pool compared to what we currently have with Shippable
  • For repos using GitHub Actions I don't expect any change
  • May start off with community.crypto which currently uses Shippable, though doesn't have quiet the traffic as c.general
  • Panel interviews for the new Community Team members are happening this week and next

Criteria for collection inclusion in Ansible 2.11 18:22:41)

  • eventual policy should include "when will collections be dropped from the ansible package" too.
  • πŸ‘ Have a separate repo for the policy. When we vote that the policy is complete enough to start adding new collections for 2.11.0 we'll move it into ansible/ansible at a page location of docs' choosing and archive the initial policy repo. (+7)

open floor

Actions

  • @samccann to add where to document 2.11 collection requirements to DaWGs agenda

Logs

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

commented
commented
  • I suggest:

  1. Removing authors field from c.g.'s BOTMETA.yml ansible-collections/community.general#1057.
    According to the discussion in the PR, there's no difference how the bot handles authors and maintainers, so we could put authors in maintainers. By getting rid of it, we could make BOTMETA more compact.

  2. Then, i'm going to update teams by asking authors and maintainers of modules (which is not in teams) in a special issue to add them to teams. Besides updating, people would see their importance to the community.

  3. Also to put maintainers in the directory level and removing modules rows would also make BOTMETA clearer and all folks in teams would get notifications about all related stuff.

Besides improving BOTMETA, this all would potentially help increase activity in c.g.

commented
  • should https://github.com/felixfontein/ansible-basic-sphinx-ext become part of github.com/ansible-community, or even of antsibull? (The latter would allow to update the parameter/return value tables to be updated/replaced without everyone having to update their own copy of the relevant CSS, assuming "everyone" uses this extension.)
commented

  • should we accept new content (plugins, modules) from companies for their products in community.general/community.network? Or should we force them to create their own collection?

    So far we did force them if they wanted to submit a group of modules/plugins. What should we do if they start with only one? (Exampe: ansible-collections/community.general#772)

commented

The PR will get merged on 2.0.0 release as discussed.

@felixfontein:

I'm wondering whether we should delay this fix to 2.0.0, instead of adding it to 1.3.0, and marking it also with breaking_changes. If suddenly something is deleted that has not been deleted in the past, that could be very surprising to users. On the other hand, the current behavior is obviously wrong and different from the documented one.

commented
commented

Have some discussion around adding nightlies of ansible ansible-base: ansible-community/antsibull#195

For nightlies of the ansible package, the main thing I'd like to know is where should this end up? webknjaz has been testing this at http://webknjaz.github.io/antsibull What do we want? Something like https://ansible-community.github.io/ansible ?

commented

2020-10-28

updates

  • andersson007_ and felixfontein started creating new collections from material from c.g/c.n: community.postgresql, community.routeros, community.docker

should https://github.com/felixfontein/ansible-basic-sphinx-ext become a part of antsibull, or if not gh.com/ansible-community? (felixfontein, 18:15:51)

  • Will merge ansible-basic-sphinx-ext into antsibull (+1:6, 0:1, -1:0)

should we merge ansible-collections/community.general#1191 or not - i.e. is removing collection dependencies a breaking change that has to wait for a major release, or not? (felixfontein, 18:39:36)

should we reschedule the meeting to another time (felixfontein, 19:01:03)

we'll decide in two weeks, when the new members of the community time started working.

should we remove authors from botmeta? #539 (comment) (felixfontein, 19:09:37)

  • πŸ‘ remove author information from BOTMETA (i.e. deduplicate)

open floor

Actions

Logs

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

commented

I've created ansible-collections/overview#128 to track the state of the collections. I will no longer update this comment.

Preparing move of modules by adding new collections to Ansible 2.10.x:

We need to discuss what exactly we require for them, besides following https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst.

We should not add some of the collections (precisely: community.docker, community.kubevirt, community.okd, kubernetes.core) to 2.10.x before a backport of ansible/ansible#72428 is part of the latest ansible-base 2.10.y release included in 2.10.x.

commented

Discussions for next meeting(s):

  1. Should we merge small number of modules/plugins from companies (#539 (comment), start of discussion in https://meetbot.fedoraproject.org/ansible-community/2020-10-28/ansible_community_meeting.2020-10-28-18.02.html)?
  2. Moving content for 2.10 (see above and all the ones before)
  3. Build nightlies? (ansible-community/antsibull#195, #539 (comment))
  4. archive module, delay change of behavior with removal to 2.0.0 or merge it now? (#539 (comment))
  5. Criteria for new collections for 2.11? (Example candidate: https://github.com/ansible-collections/community.sops; do we have more candidates?)
commented

Regarding: #539 (comment) Possible non-binding poll for next time [pick all that you are okay with]: (A) No new content in c.g (we'll work out some other place to put new content) (B) new content in c.g limited to things that aren't likely to have more than a few (<5) new pieces of content. (C) new content only in areas which already exist in c.g (D) allow any new content that can pass review into c.g

commented

2020-11-04

agenda: #539 (comment) (felixfontein, 18:03:19)

announcements

Should we merge small number of modules/plugins from companies? (felixfontein, 18:08:37)

possibly change community meeting time

  • πŸ‘ community meeting will start at 19:00 UTC from next week on

open floor

Nightly builds of ansible

Logs

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

commented

Please note that from next week, the meeting will start at 19:00 UTC, i.e. one hour later than until this week.

commented

ansible-base renaming to ansible-core for 2.11

I don't think this will cause any problems for the ansible package as we have a maximum version in the metadata so ansible-2.10 and 2.11will run with ansible-base-2.10, ansible-2.12 will run with ansible-core-2.11. And that's just the expectation.

  • @webknjaz any problems you foresee?
  • @acozine @samccann @lmalivert We probably should document which ansible-base/ansible-core packages (and versions) each ansible version requires.
commented

@abadger I'm 99% sure that the upgrade/downgrade issue will surface itself once again and I'd rather just get rid of all the hacks attempting to warn users about those problems as it's largely unreliable + we'd be able to ship wheels. FWIW I can't think of any problems other than this one. But if there'll be some flow resulting in upgrading ansible-base==2.10 to ansible-core==2.11, we'll see the same sort of colliding file removals.

commented

Topics for today's meeting:

  • (#539 (comment), #539 (comment)) Should we accept new content in community.general (and community.network I guess)? Possible scenarios to vote on:

    1. Absolutely no new content. Only features to existing modules/plugins and bugfixes are allowed.
    2. New content only in areas that already have content, i.e. new GitLab modules would be accepted, new RandomNewCodeHoster modules would not be accepted.
    3. Accept content from new areas, but only if it is not likely there will be more than a few (< 5) new pieces of content, and if they can give a convincing argument why the new content should really be in community.general and not in a new collection or community.beta|incubator|... (Content for existing areas is accepted if it passes review.)
    4. Accept content from new areas, but only if it is not likely there will be more than a few (< 5) new pieces of content. (Module and _info module for a new ticketing or vault service would be ok. Modules/plugins for a new cloud provider would not be.) (Content for existing areas is accepted if it passes review.)
    5. Allow all new content that passes review.

    (Right now, we are somewhere between 3 and 5.)

  • Content moving, resp. adding new collections (with old content) to Ansible 2.10.x (#539 (comment)).

  • archive module, delay change of behavior with removal to 2.0.0 or merge it now? (#539 (comment))

  • Criteria for new collections for 2.11? (Example candidate: https://github.com/ansible-collections/community.sops; do we have more candidates?)

I think we should really make sure to also discuss the second item (new "old" collections for 2.10.x), and hopefully finish the first (new content for c.g/c.n).

Please remember that today's meeting starts at 19:00 UTC, i.e. one hour later than before.

commented

2020-11-11

announcements

  • ansible-base will be renamed to ansible-core, I think for 2.11
  • docs team is discussing how to split up the docsite to support independent releases of ansible-core and Ansible. See https://etherpad.opendev.org/p/ansible-documentation-split for scratchpad of current ideas. We meet on Thursdays 10:30am ET on #ansible-docs

Should we accept new content in community.general community.network)? (felixfontein, 19:16:55)

(discussion will be continued; general gist: options i-iii are of interest; making creation of new collections including CI simpler is something that should be high priority)

Content moving, resp. adding new collections Ansible 2.10.x: #539 (comment) (felixfontein, 20:13:36)

open floor

Logs

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

commented
commented

Topics for today (19:00 in #ansible-community on Freenode):

commented

There are a few things that I think we need to get approved:

Hope these can be two quick votes:

This leads to a lot of discussion:

  • New collections to be included in ansible 3.0.0
    • Proposed rules:
    • Proposed dates:
      • Discuss existing checklist today
      • Approve the existing checklist as our basis today or first thing on 2nd December
      • Discuss and approve additions and changes to the checklist on 2nd December and 9th December (please come to this meeting with proposed changes already written up)
      • Final rules for getting a net-new collection into 3.0 approved by this body by 16th December.
      • Open for new collections until 23rd Jan 2021. This is the approved-by-date. Collections need to have been submitted for review, reviewed, and any review blockers fixed before this date.
        • Can extend up to 2021-02-02, ansible-3.0 beta freeze if we want
    • Caveats/Problems: Our bottleneck will be collection reviewers. Especially in this first release where we have the initial seed but haven't yet approved other people to review collections.
commented
commented

2020-11-18

announcements

  • community.docker, community.postgresql and community.routeros 1.0.0 were released this week and will be included in the next Ansible 2.10 release
  • The Bullhorn 14 has been published today: https://mailchi.mp/redhat/the-bullhorn-14
  • Next two Ansible PR days are Tue 1st Dec and Thu 17th December. Calendar invite is in #407 Hope to see you there
  • Ansible-2.10.4 will be released on Tues, 1st Dec (or possibly 2nd December according to timezones ;-)
  • please review ansible-collections/community.general#1303 and ansible-collections/community.general#1304, in particular the changelog fragments, since we will replicate them a lot
  • ansible-collections/community.general#1303 | open, created 2020-11-14T19:43:15Z by felixfontein: [WIP] Add information on docker module migration [WIP,affects_2.10,docs,has_issue,needs_triage,owner_pr]
  • No IRC Meeting next week (25th Nov) as lots of people are off that week
  • ansible/ansible is now ansible-core (previously ansible-base) ansible/ansible#72594
  • ansible/ansible#72594 | closed, created 2020-11-12T00:53:41Z by relrod: Rename to ansible-core [affects_2.11,bug,shipit,support:community,support:core,test]

Semantic versioning of the ansible package

  • related proposal: ansible/proposals#179
  • πŸ‘ The next major release of ansible will be 3.0.0; Ansible releases will follow semantic versioning going forward from there (12 x +1, 1 x 0, 2 x -1)

Release schedule for ansible-3.0.0

inclusion of dellemc.openmanage (https://github.com/dell/dellemc-openmanage-ansible-modules/tree/collections) in 2.10.x for transfer of some content from c.g (ansible-collections/community.general#948) (felixfontein, 19:55:27)

Criteria for new collections to be included in ansible-3.0.0 (abadger1999, 20:08:48)

  • Proposal: #539 (comment)
  • We are happy for the inclusion criteria (https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst) to become stricter to help improve the quality of the collections that are shipped in ansible. If you have an idea please mention in IRC or raise a PR directly against collection_requirements.rst to clarify & improve
  • Discuss current checklist today, approve it as a basis for the guidelines no later than beginning of meeting on December-2-2020.
  • Discuss and approve changes to the guidelines on December-9 and December-16
  • Guidelines that have been approved by the end of the Dec-16 meeting will be the criteria for new collections in ansible-3.0.

Discuss and approve the current checklist

open floor

Actions

Logs

Minutes: https://meetbot.fedoraproject.org/ansible-community/2020-11-18/ansible_community_meeting.2020-11-18-19.00.html
Minutes (text): https://meetbot.fedoraproject.org/ansible-community/2020-11-18/ansible_community_meeting.2020-11-18-19.00.txt
Log: https://meetbot.fedoraproject.org/ansible-community/2020-11-18/ansible_community_meeting.2020-11-18-19.00.log.html

commented
  • release community.general more often (minor releases). Right now, minor releases happen every two months, which is quite a long time between releases. Since minor releases are relatively easy to do (the only exception is the last one befor the next major release), I would suggest to increase the frequency to either once per month, or even every ~3 weeks (i.e. sync with Ansible releases). I would only start this from 2.0.0, so that there isn't another minor release between 1.3.0 and 2.0.0.
commented
commented

Topics for today:

  • Short question: are bugfix releases every ~3 weeks (i.e. shortly before Ansible 2.10.x releases) ok for community.general's stable-1 branch (assuming there is something to release, of course)?
  • Short discussion: Ansible 3.0.0, or a higher version number (for example 10.0.0)
  • Long discussion: criteria for inclusion of new collections in Ansible 3.0.0

Here, "short" means "a few minutes" and not more.

commented

2020-12-02

agenda: #539 (comment) (felixfontein, 19:02:27)

Announcements

Are bugfix releases every ~3 weeks ok for community.general's stable-1 branch? (felixfontein, 19:06:24)

  • πŸ‘ community.general 1.3.x bugfix releases will be ~every three weeks

Should the next 'big' Ansible release in February 2021 be Ansible 3.0.0, or a higher version number? (felixfontein, 19:09:23)

  • πŸ‘ the next 'big' Ansible version will be 3.0.0 in February 2021. we'll add docs everywhere that explain that it is not much different than 2.11 would have been, so users hopefully won't expect something bigger

Criteria for inclusion of new collections in Ansible 3.0.0 (felixfontein, 19:19:03)

Matching ansible doc format and conventions

  • existing checklist item on documentation is considered okay to start with.

sanity tests

license for collections

Make some things stricter

Publically available issue tracker

  • πŸ‘ MUST have a public & free issue tracker

CoC

  • πŸ‘ MUST have a CoC (or if not fall back to Ansible's)

Information on which kind of contributions are accepted 20:13:25)

issue tracker proposal for vote

Information on which kind of contributions are accepted 20:22:59)

  • Discuss next time: 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."
  • Discuss next time: 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."
  • ansible-collections/overview#132 | open, created 2020-12-02T19:34:58Z by abadger: Must change changes to the checklist criteria

Actions

  • @gundalow to think about ignore.txt hackfest
  • @abadger1999 to find out who manages legal@fedoraproject.org and whether we can piggyback off of the list they maintain for our needs or need to setup our own review process and list with red hat legal.

Logs

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

commented

For next time, discuss:

  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."
  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."
  3. MUST be in Galaxy + have a README.md ansible-collections/overview#134
  4. MUST changelogs (what's the exact requirement, we have three options listed under https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#changelogs)
commented

Small update to the licensing section of the checklist that was approved last week: ansible-collections/overview#133

We talked about BSD-3-clause in the meeting but the existing module_utils coming from the ansible/ansible repository is actually BSD-2-clause. Since the spirit of the licensing section is "do what ansible/ansible did until we have legal approve us opening the doors", I think we should change this to BSD-2-clause.

commented

2020-12-09

Updates

discussion of guidelines for including new collections into Ansible (felixfontein, 19:14:10)

  1. What type of contributions are accepted
  1. Inclusion of a new collection in the Ansible package is ultimately at the discretion of the Ansible community review committee (gundalow, 19:25:18)
  1. MUST be in Galaxy + have a README.md
  1. MUST changelogs
  1. BSD License for module_utils should be 2 clause 20:02:21)
  1. Collections requirements for role or playbook-focused collections (gundalow, 20:06:58)

Other items

Approval of the checklist

Open Floor

Actions

  • @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
  • @update issue_template to include CONTRIBUTING.md

Logs

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

commented

After the meeting today, it was pointed out that some of the changes to the checklist that happened after last week's meeting were not approved. (In general, I think that changes which might change the meaning of a set of guidelines must be approved. Changes which merely change formatting or clarify the intent do not need to be approved [unless the clarifications are not universally seen as matching the intent].... The bigger the change, the more likely you should get it approved ;-)

I reviewed the changes that were made after the meeting and I pulled out the things that I think are changes to what were in the guidelines before:

  • The code of conduct update. In the meeting we voted on requiring a code of conduct and promoting the Ansible code of conduct as something to use if the collection didn't have one of their own. We talked after the vote about whether to require the Ansible code of conduct but that was not voted upon (I would have voted against it and tadeboro who was not at that meeting has since said that it causes difficulty for his existing collections) ansible-collections/overview#136
  • The ci changes here were unapproved. I think they're good in intent although I think we need to be careful that the way we're phrasing it doesn't put an undue burden on collection owners: ansible-collections/overview#137
commented

For next time, on sanity tests:

I am proposing a list of unacceptable ignore entries for new modules in
ansible-collections/overview#139

The basic criteria for those items is that they are all related to providing accuracy and completeness to argument_spec documentation. And those are the most basic cases.

In ignore-2.10.txt today we have 508 entries, and these entry types respond for 391 (~77% of the list). Top 5 offenders:

    129 validate-modules:parameter-list-no-elements
     87 validate-modules:parameter-type-not-in-doc
     84 validate-modules:doc-missing-type
     53 validate-modules:undocumented-parameter
     27 pylint:blacklisted-name

As it can be seen from this, we have a lot modules without basics: elements type unspecified, type of the parameter itself unspecified, undocumented parameter.

commented

2020-12-16

agenda #539 19:01:13)

Announcements

Some changes to the collection guidelines

Checklist: running CI against the version of ansible/ansible-base that the collection supports (abadger1999, 19:13:38)

  • Checklist change PASSED [+5, 0, -0]: You MUST run CI against each of the "major versions" (2.10, 2.11, 2.12, etc) ofansible-base/ansible-core that the collection supports. (Usually the head of the stable-xxx branches.)

Checklist change about running CI against every commit 19:25:09)

  • APPROVED [+5, 0, -0] Replace "All CI tests MUST run against every PR & commit to the repo." with "[] All CI tests MUST run against every pull request and SHOULD pass before merge. [] All CI tests MUST pass for the commit that releases the collection."

CoC change to not require Ansible's CoC: https://github.com/ansible-collections/overview/pull/136/files (abadger1999, 19:48:40)

  • APPROVED [+7, 0, -1] Replace current CoC requirement with one that is more flexible and has D&I review.
  • ansible-collections/overview#139 | open, created 2020-12-13T01:05:11Z by russoz: List of unacceptable values for new entries in ignore files
  • jillr also approved the 4-point CoC criteria update.

Add a list of sanity tests that MUST not be ignored to the checklist: ansible-collections/overview#139 (abadger1999, 20:26:54)

Open floor

Actions

  • @cybette to add CoC discussion to D&I WG meeting agenda
  • @abadger to update and merge the PRs impelemnting the approved checklist changes.

Logs

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

commented 
* [Modhelper improvements ansible/ansible#1480](https://github.com/ansible-collections/community.general/pull/1480)

@gundalow I'm curious on why my small PR is going into the spotlight. Can't decide if I'm happy or worried about it :-) And when will the next meeting be anyways, 06/Jan (7th for me)?