Issues with current changelog workflow

[nrdxp]

Current Issue

The current changelog generation doesn't go well with BORS. I'd like to setup everything so that only BORS is allowed to commit to core, but with the current changelog action, this isn't possible since the changelog runs after a merge. In addtion, there is currently irrelevant junk in the changelog because of github-changelog-generator/github-changelog-generator#940.

Alternatives

• I like git-journal, but it kinda seems like it's unmaintained at this point with no release in about 2 years.

• We could attempt to address the issue in the upstream changelog generator as it shouldn't be too difficult if we can just isolate the proper github API call. Doesn't seem like discussion features are well documented yet, however, as I believe they are still in beta. Once this is accomplished, we could convert the GitHub action into a pre-commit hook.

• There are a host of other changelog generation tools as well, if anyone has a good experience with another tool, please mention.

[Pacman99]

Another alternative since the plan is to have devos releases, is to just generate the changelog whenever a release is tagged. I've seen many projects do that instead. I think its cleaner, since its easier to generate a changelog off of previous commits and then format it and clean it as you wish. Also the current method is really unnecessary until a release, since you could just look at the commit message to get the same information. Its only when you have a release its useful to document everything that was included in the release.

[blaggacao]

There are no bigger features planned yet.

Maybe git journal is feature complete. 😄

I like that git journal shifts the task left and thereby is hosting provider agnostic. This goes at the cost of needing to "tag" commit messages (as opposed to "label" issues), which from my first read seem to just be the employment of preconfigured natural language perfect verb forms.

Having it generated as a pre-commit hook on every commit shortens the feedback loop and makes the documentative nature of commit messages self-evident by feeding back its final exposed representation.

Shortening feedbackloops is extremely powerful and usually leads to self-adjusting behaviour.

Since, when people fork this repo, this reverbarates downstream and educates a whole ecosystem, rgardless if hosted on github.com

It also fosters good practice of atomic commits.