Changes impacting Committers/Contributors

[gundalow]

Every so often the Ansible Core Team change parts of the development process. Some of these changes directly impact how people with Commit powers should deal with Issues and PRs. We could improve how we communicate these changes, also given that the Core team is much larger than a few years ago, and across four continents we can't assume that everyone "just knows".

Some of these changes maybe of interest to people developing (though without commit powers)

Examples

• Changes/reminders about freeze dates so people know what can be merged
• Introduction and changes in changelogs
• Defined process for creating backlogs
• Changes to CI
• Changes to Ansibot workflow

Possible Implementation

1. Process/workflow $Foo is changed
2. PR raised to document $Foo
3. $Foo is mentioned in next IRC meeting, this also forms part of the docs review to ensure we've done a decent job explaining the what/why
4. Chronological list of changes is updated
5. Announce $foo via GitHub/Mail List/What?

Questions

1. Do people think this is needed?
2. How would people like to be notified of changes. Need to ensure these notifications don't get lost in the sea of notifications via GitHub and ansible-devel mailing list
3. What else has changed over the past year that's come as a surprise

Should be added to main docs, summary in CommitterPage

See other discussions in:

• Newsletter "decisions" #211 (comment)

[caphrim007]

I also am not aware of all the many changes. Which means I'm very likely doing something incorrectly these days.

like @agaffney I also don't hang out on IRC all day long, so some form of communication that can be received and read "when I am available" works for me. Email is my path of least resistence provided that there is something that I can filter it by in my client so it doesn't get lost in the ether.

My last "oh...ok" moment was when I recently went to deprecate a module and noticed that 3 or 4 new keys were now required and I had to go find (in the source) what they were as I wasn't aware of a docs article (whether there is one or not).

[gundalow]

How would you imagine this looks like, a history page with a heading per change, newest at top with links to other relevant documentation and discussion?

[caphrim007]

specifically when I was going about the module deprecation work, I started with google. "ansible deprecate module" did not raise any links that were relevant, so I started looking in github for pre-existing modules that started with an "_" and then a round of 5-10 pushes to a PR before shippable came back green.

While I've tried to reproduce what shippable does on my client side (so I can PR knowing it will be green) every time I've tried it, the tests locally (my box) always say things are cool and then shippable finds the "real" problems.

Historically I haven't needed a "what's new" feed. My day-to-day is usually quite "eyes-off" what happens in core, and it's not until something is not working as I expect that I begin to go mousing around for answers.

For a long time though I've been operating under the premise that "core generally doesn't break my work" and so I guess you could say I've gotten comfortable not needing to know.

But I admit, that's not a good excuse.

If there is a landing page made that is the chosen place to put this, I will certainly make use of it. I use RSS (in the form of Feedly) for updates, but I would be fine with email that is communicated out too.

[agaffney]

I think that a combination of what @gundalow suggests with a "history page" and the email announcements to ansible-devel for new items would probably work well.

[amenonsen]

I think that a combination of what @gundalow suggests with a "history page" and the email announcements to `ansible-devel` for new items would probably work well.

Email announcements and a history page would work for me too.

[resmo]

I have minimal concerns that a "history" page gets "cluttered" very quickly. And I see no benefits in seeing the "full change history" of the processes.

I would suggest to "mail to devel ML about what changed" and the doc page should only reflect current status/workflow (without history) for simplicity.

[dagwieers]

When I proposed a Newsletter I was looking for a means to create a larger contributor community that we currently lack. Something earlier or newer contributors can easily tap into. Easy to read with short articles that point to the relevant information we already have. Something people can skim over to select what they like. A Newsletter that would be send once every quarter or every 2 months, not more often than that.

Because we already have IRC, and a mailinglist for us. I don't think we need another technical solution for the existing active contributors, but we could use something that both celebrates the Ansible dev community, as well as informs them of new things that are coming related to developing modules, plugins, etc.

That's what #211 (comment) was about anyway.

[pilou-]

As one without commit powers:

Do people think this is needed?

Yes

How would people like to be notified of changes.

Newsletter - I like dagwieers proposal ! - and main doc.

[gundalow]

To hijack my own thread, can you please ensure you all have GitHub 2FA on otherwise "shortly" you will no longer have commit rights.

[gundalow]

To move the discussions back on topic.

Thank you for your feedback so far. This confirms, as I thought, this is a real issue, and there are some examples that I hadn't considered.

I'll add this to the agenda for Contributors Summit and based on feedback I've got a few ideas that I believe meet everyone's concerns.

If you have any other thoughts please do add them here.

We can also use this issue to track items that need communicating, so we don't loose track of them. You may have noticed that I've referenced this issue from other issues that would impact developer and comitter workflow.

If you spot such issues please do mention them here, so we have a set of topics for our first update.

[gundalow]

Stricter checks for Module DOCUMENATION.return

Thanks to @felixfontein not use adding this test, though also for fixing over 100 modules.
See ansible/ansible#63411 for more details

[ssbarnea]

Better to delay a major release than breaking stuff. Every time I rushed a release I regretted it.

In case anyone is interested molecule master code is running CI and pasing with Ansible 2.9rc4.

[felixfontein]

Module documentation: element type for lists

Module docs can be improved by adding elements: next to type: list for both option documentation (possible in devel and stable-2.9; see ansible/ansible#50335) and return value documentation (possible in devel and in post-2.9.0 stable-2.9; see ansible/ansible#62929).

To see this in action, search for contact or identifier here.

[gundalow]

Ansible 2.9.0 has been released

Porting Guide

Changelog

Future maintenance releases will occur approximately every 3 weeks. So expect the next one around 2019-11-21.

Amazing work by everybody, thank you!

[gundalow]

Next PR review day is Thursday 14th November from 1400UTC til late
What's this in my Timezone?

See you in #ansible-community on Freenode IRC
We #407 for more info

[felixfontein]

Please note that a couple of PRs have been merged which improve sanity checking for modules. Check the updated ignore.txt for the modules you maintain / are interested in, and watch out when merging something the next days :)

The improvements are:

• for type='list', elements is now required (Add sanity test to require elements entry when argument type=list ansible#66386) and also checked against elements in documentation (Add tests to make sure that the documented 'elements' matches that defined in argument_spec ansible#66385);
• the argument spec is validated with a schema (Schema validation for argument_spec ansible#65747).

[felixfontein]

There are some more new sanity tests for modules. Make sure to check the current ignore.txt for the modules you maintain / care about!

• Forbid state=(list|info) in modules via ansible-test sanity check ansible#66898 make sure modules don't support state=list or state=info
• Module validation: sanity check mutually_exclusive, required_if, required_xxx ... ansible#66961 basic checks for mutually_exclusive, required_if, required_by, required_together and required_one_of
• add_file_common_arguments: fix defaults and tpyes, improve sanity checking ansible#67243 some errors previously ignored because of special code for handling add_file_common_arguments=True are now reported

If your modules already live in a collection outside the Ansible main repo, make sure to also check them with devel's ansible-test, as it catches a lot more errors than the one coming with Ansible 2.9.

[gundalow]

Collections: Important changes to devel

Very soon we will start the mass migration of content (modules & plugins) out of ansible/ansible:devel into Collections. During this time the devel branch will be frozen for a while, followed by a mass DELETION (git rm) of files.

Please all take the time to read through https://github.com/ansible-collections/overview/blob/master/README.rst

Any feedback or further questions please ping me on IRC or email me gundalow@redhat.com

Please also help spread the word by retweeting/upvoting/sharing the various bits of Communication we've already done

[gundalow]

Ansible Contributors Summit EUROPE

What

Ansible Contributor Summit is a one day event especially for community contributors to meet with each other, as well as Ansible development teams (Core, AWX/Tower, Galaxy) in person, to discuss important issues in the community and help shape the future of Ansible. For those unable to make it to Gothenburg, we welcome you to join virtually for part/all of the day. Online participation and streaming details to follow closer to the summit.

Where

Göteborg, Sweden

When

• Contributors Summit: Sunday, 29th March
• Ansible Hackathon: Monday & Tuesday 30 & 31st March
• FOSS-North: Monday & Tuesday 30 & 31st March

How

• If you plan to attend in person, please register on Eventbrite
• If you plan to attend the hackathon or any of FOSS-North please register
• If you plan to attend virtually details will be added to the Etherpad the day before

Agenda

• Please add suggested topics to the Etherpad
  For more info please see the announcement.

[gundalow]

All,
A reminder that our Virtual Contributors Summit is taking place on Sunday 29th March at 1100 UTC (What's this in my timezone)

Hope you can make it, please add your name to the bottom of the Etherpad

[gundalow]

Changes impacting Collections

If you a maintainer for a collection, please subscribe (button on right hand side) to ansible-collections/overview#45

[gundalow]

Changelog process for collections

Feedback needed

We have a continuing need for changelogs (or release notes) to cover:

• ansible/ansible - currently has a working solution using changelog fragments
• collections - two options mentioned so far are reno and towncrier
• Ansible Community Distribution (ACD) - a bundled package that includes the trimmed down ansible/ansible and a set of curated collections that will mimic the current user experience of Ansible with all batteries included (2.9 level of content). ACD has no proposed solution yet, but whatever is used by collections has to provide fragments that can be drawn up into an ACD changelog/release note.

There are various proposals outlined ansible-collections/overview#18 Please comment and vote for preferred solution.

[gundalow]

Dropping ANSIBLE_METADATA

In Ansible 2.9 and earlier we had the concept of ANSIBLE_METADATA, to express support level and deprecation. With the move to Collections, and support being defined if a Collection is in Galaxy vs Automation Hub, ANSIBLE_METADATA is no longer needed.See ansible-collections/overview#57 for background

ansible/ansible#69454 will cause ansible-test to error if ANSIBLE_METADATA is found in modules.

Call to action

• Please bulk remove the ANSIBLE_METADATA section from all modules in your collection

[gundalow]

Next Virtual Contributors Summit

We're going to set the date for our next Contributor Summit soon, please let us know what works best for you! https://doodle.com/poll/d8ttii3zpv5a2ic5

[gundalow]

Next Ansible PR review day (Collections)

The next PR day will be Wednesday 17th June 2020 from 1400UTC

See #407 (comment) for further info. Hope to see you there!

[felixfontein]

validate-modules change in devel

Until now validate-modules treated an unset default value for bool options exactly the same as default=False. This has been fixed in ansible/ansible#72699 and might cause some sanity tests to fail.

[felixfontein]

validate-modules change in devel: flags module options that might reveal secret data

There is a new test in validate-modules (ansible/ansible#73508) which reports module options that look like they could contain secret data (by the option name), but do not have no_log set. Examples are things like password, key or token.

Since the test aims at catching as many real cases as possible, it unfortunately also produces a lot of false positives. DO NOT use ignore-2.11.txt entries to ignore these! Instead, add no_log=False to the module option's argument spec entry to flag this specific option as "contains no secret data". Ignoring the error for a file will also disable this check for new module options, and this this a really bad idea!

[GeoEducator]

how can i be useful?

[Andersson007]

Hello @GeoEducator and welcome! Responded to you in another comment.