[PROPOSAL] Standardize release notes generation script

[Swiddis]

Is your feature request related to a problem? Please describe

Generating release notes has long been a pain point across teams. Searching through any of OpenSearch, OpenSearch-Dashboards, or opensearch-build for "automate release notes" turns up several issues on the topic. By some historical action addressing this problem, a release notes drafter action seems to have been added to most repos (I'm struggling to find a good source issue but https://github.com/opensearch-project/OpenSearch/issues/789 seems related).

I don't know about everyone else, but I've long struggled to get this action to work correctly -- it seems tied up with the GH release process, and its commit range isn't explicitly selectable. As I've assembled release notes for several releases, I've long yearned for a tool where I can just say "Here's a commit range, go."

Describe the solution you'd like

Solving my own problem, I've made a tool that does exactly this: make_release.py. I've successfully used it to generate notes for three releases now on dashboards-observability, and it's seen adoption from other team members and other teams, as well.

I'd like to propose making this script more "standard", by introducing it in an official repository (here?). Doing so would make it more discoverable and trusted by other devs throughout the org, and I think make release note generation less painful overall, with less time spent fighting the release action (or making releases manually!). The script also has the benefit that, for backport PRs, it can trace most of them back to the original pre-backport PR and link that instead, which makes it easier to directly access a change's discussion and credit the appropriate devs for their work.

In my opinion, this seems more reliable long-term for making a fully automatic release notes process. An example would be by introducing it into automation that we can configure with more granularity, e.g. autocut PRs that update the notes live from merged PRs. (Although I recognize that this dream doesn't hold sufficient caution for the remains of the action that came before...)

Describe alternatives you've considered

Do nothing -- continue as we have. I'll continue advertising the script as a personal project for anyone who needs it. (I'll admit: this issue is itself a form of advertising this script.)

Additional context

Dblock's live-changelog proposal https://github.com/opensearch-project/OpenSearch/issues/1868 is a good way to eliminate the problem at the source, but it's hard to get team buy-in when it's not already part of our PR culture (as the proposal itself getting blocked shows).

There's another proposal to formalize PR labels across the org, https://github.com/opensearch-project/.github/issues/156, that we use in dashboards-observability and that the script is configured for. They also discuss automation, but it looks like the issue is still open and hasn't been updated since January.

It would be funny if I'm just missing something obvious and the release action works fine for everyone else.

[derek-ho]

+1 Can we please make this into a opensearch-bot action that can raise a PR for all repos come release time automatically? This may also involve standardizing enforcing PR labels across the org.

[Swiddis]

This may also involve standardizing enforcing PR labels across the org.

Thanks for calling this out explicitly -- we use this already in our repos, and the script relies on this convention. I edited some more info into the "additional context" building on this and linking further discussion.

[peterzhuamazon]

https://github.com/opensearch-project/opensearch-plugins/blob/main/RELEASE_NOTES.md

[gaiksaya]

Hi @Swiddis Did you go through the automation in the above link https://github.com/opensearch-project/opensearch-plugins/blob/main/RELEASE_NOTES.md#automation I believe multiple plugins are using it today. Can you go through it and see if this solves your problem?