Release notes generation

[systay]

This PR changes how Vitess creates release-notes for releases.

We'll keep track of which PRs get merged by looking at the git log, and produce the release notes from that.
To group PRs in useful buckets, we'll use labels a bit more than today.

The command looks something like this:

make FROM="upstream/release-10.0" TO="upstream/master" release-notes

This would generate the release notes for all changes that have gone into the master branch since release-10.0 was forked from it.

The produced release notes look something like this:

---

Bug fixes

Query Serving

• Routing of Information Schema Queries Routing of Information Schema Queries #7841
• Panic when EOF after @ symbol Panic when EOF after @ symbol #7925

CI/Build

Cluster management

• make: build vitess as static binaries by default make: build vitess as static binaries by default #7795

Other

• update moby/term to fix darwin build issue update moby/term to fix darwin build issue #7787
• Removing Linux/amd64 specific subdependencies Removing Linux/amd64 specific subdependencies #7796
• Makefile: add cross-build target for cross-compiling client binaries Makefile: add cross-build target for cross-compiling client binaries #7806
• Bump MySQL version for docker builds to 8.0.23 Bump MySQL version for docker builds to 8.0.23 #7811

vttestserver

• docker/vttestserver: Set max_connections in default-fast.cnf at container build time docker/vttestserver: Set max_connections in default-fast.cnf at container build time #7810

---

First PRs are grouped by type, and then by component. If a PR is missing either, "Other" will be used instead.

[frouioui]

@systay - 93d1906 introduces the rendering of prPerType using go text templates. A sample output is:

## Other 
### Component: Query Serving
 - Fix bug with reserved connections to stale tablets #7879 
### Other
 - Minor cleanups around errors on the vtgate #7864
 - vreplication: performance & benchmarks (table copying) #7881
 - Planbuilder: Add fuzzer #7902
 - Memory Sort to close the goroutines when callback returns error  #7903
 - Check tablet alias before removing after error stream #7915
## Type: Bug 
### Component: Query Serving
 - Panic when EOF after @ symbol #7925

[frouioui]

Note: we were originally planning on sorting PR information (inside each component) based on their merged date. However, the issue described here cli/cli#3497 occurs. Pull requests are now sorted by their number in increasing order.

[deepthi]

This is awesome!
For anyone else following along, we will use this to generate an initial release notes which will then be edited by hand (curated) to produce a final version.

[deepthi]

Do we use the Backport me label instead?

[frouioui]

Correct. The intention is to get rid of these true/false checklists in pull requests, and instead, use them as Todos.

[deepthi]

Then let us add that guidance to the PR template as well.

[frouioui]

Added that guidance in c1f6d5b.

[systay]

And I just removed it. @shlomi-noach raised the valid objection that you need write access to the repo to be able to assign labels. I tweaked the text so it's aimed at new contributors without write access, and not aimed at maintainers.

My suggestion is that we maintainers do it for our own PRs and for any PRs we merge.

Alternatively, we could preface the label section with something that this only applies persons with write access to the repo. Not sure which is the better option ¯\_(ツ)_/¯

[deepthi]

🎉

[shlomi-noach]

Please consider that only people with Write privileges on our GitHub repo, are able to create labels. Which means the casual contributor is unable to classify their PR by labeling.

I'm not sure if this undermines the purpose of this PR...

[systay]

I don't think it does. We as maintainers should be able to handle labelling before PRs get merged.
And about backporting - deciding what gets backported and what does not has in my experience always been a discussion between maintainers.
Maybe we should just remove this comment altogether from the PR template.

[shlomi-noach]

perhaps add a HTML comment <!-- --> in the PR template to explain how we should go about labeling? Not sure if it's a great idea, because it's aimed for us the maintainers rather than the contributors. At your discretion.