Public feature / patch tracking system, automated Release Notes generation from PRs

[t-lo]

Issue

• Features and patches are not tracked across channels / releases
• Release notes are assembled manually, with some guidance from scripts

Impact

• Patch / feature progression is intransparent / not easily accessible for Flatcar community
• Assembling release notes - for larger releases in particular, e.g. major Stable releases - take significant manual effort.
  Manual assembly of release notes is error prone and often requires additional engineering time on top of the write-up, to cross-check release notes contents.
• Security information like CVEs need even more time since CVE contect needs to be manually looked up for every CVE fixed in a release.

Ideal future state

• Feature / patch progression from Alpha -> Beta -> Stable (i.e. the respective PRs) is visually accessible, e.g. via a project board
  • Automation (GH actions) is in place to update the board on each release
• PRs follow a strict format and either include optional release notes text (opt-in) or even enforce structure with default release notes text (with exceptions - “opt-out”).
• Tooling and automation exists to fully auto-generate release notes and CVE information, given two commits (branch tips, tags) as input

[pothos]

I think we are good for now and will close this:

• For change log generation we have show-changes in https://github.com/flatcar-linux/flatcar-build-scripts (used for the release note draft) that uses the info of the coreos-overlay/portage-stable/scripts release note entries the PR template mandates
• The list of CVEs that impact a build is not generated (work ongoing in this area) but one can check whether a CVE is marked as fixed in the changelog folder
• For PRs that we backport we state the branches we backport to in the PR and we have is-pr-in-branches in https://github.com/flatcar-linux/flatcar-build-scripts as a helper to check if that was really done