CHANGELOG: add an in-repo changelog file

[cyphar]

This will make releases much simpler. I've back-filled the changelog
with everything since runc 1.0.0 (there's not much point going further
back than that).

Signed-off-by: Aleksa Sarai cyphar@cyphar.com

[cyphar]

The idea is that we will always keep the main branch CHANGELOG accurate (we can add unreleased 1.0.z sections for patches that have been backported) and people submitting patches to runc which are impact/changelog need to add their changelog entry to the file.

[kolyshkin]

LGTM overall; added some nits that can either be addressed here, or post-merge if we want to release am rc faster.

[thaJeztah]

and people submitting patches to runc which are impact/changelog need to add their changelog entry to the file.

In general, I applaud that effort; it's good to have the changelog entry written together with the pull request. That said, (of course depending somewhat on how many changes are relevant to the changelog), but I know a couple of repositories that take this approach, and it's often "merge conflict hell" (which would potentially happen twice; once for the main branch, and one for the backport).

Not sure what a good solution is though (also because "changelog-worthy" can be a bit of a grey area; a bug fix may initially seem "minor", but later turn out to be affecting many users, so worthy to mention).

GitHub's auto-generated release-notes may help (to some extend). Other approaches I've seen is for contributors to add a new file in a changelogs/ directory (to prevent the conflicts), which then get included in a changelog, but that's a bit "quirky" / "noisy" as well.

[thaJeztah]

This change itself LGTM

(but perhaps we can find a solution to the above, but that can be resolved / discussed separately)

[kolyshkin]

LGTM

[cyphar]

Yeah maybe changelog/ would be less prone to conflicts but I think we can revisit the issue if we end up with a lot of conflicts. Having something is better than nothing imho.