Guidance (& enforce) changelog/fragments

[gundalow]

The release managers need to define the rules for changelog/fragments

Need a set of rules that we can encode in CI

Why

We are currently causing some back-and-forth in backport PRs which is bad as:

• Annoys community
• Wastes Release Managers time
• Means some backport PRs may not make it in the release and have to wait
• Changelog isn't as full as it should be

Options

• Option 1: Does every backport need a changelog/fragment
• Option 2: Everything apart from PRs that only affect tests/ or docs/

[nitzmahone]

+1 for option 2...

Ideally we'd figure out the right set of stuff for devel so the backports are "free" (that was the original hope all along). One other thing that makes that easier is that back in July, Github added a delete button on individual files in PRs, so nuking a spurious changelog fragment is much easier than adding a new one. Now that it's easy, maybe we should add a bot tickler for all devel PRs marked bugfix or feature, and just delete spurious fragments before merge.

[willthames]

Option 2 should be all PRs except docs, tests, and new plugins/modules

But otherwise I'm in agreement, we really don't want backport PRs to be different to standard PRs.

[abadger]

We can also have the changelog generation script decide to omit certain classes of changelog from generation (ie: normal bugfixes get omitted from alpha1)

[gundalow]

Docs: https://github.com/ansible/ansible/pull/48172

[webknjaz]

I have a GitHub integration prototype for such linter now. Source: https://github.com/sanitizers/chronographer-github-app Demo: https://github.com/sanitizers/browntruck/pull/1/checks?check_run_id=40780645

[geerlingguy]

Now that collections are a thing, I think more and more collections will have the same challenge. Related issue in the Kubernetes Collection's issue tracker: https://github.com/ansible-collections/kubernetes/issues/40

[felixfontein]

@geerlingguy this also affects all changelog fragments added after stable-2.9 was branched, which would have appeared in the 2.10 changelog but which won't affect the new ansible-base package. @sivel has been working on a script which tries to map existing changelog fragments to collections.

And while changelog fragments are overkill for most small collections, they are still useful for large ones such as community.general.

[webknjaz]

Ref: https://github.com/ansible-community/community-topics/issues/64.