@reidbaker perhaps the release process should be updated so the author or TL approver also made a reviewer on the CHANGELOG commit?

@reidbaker perhaps the release process should be updated so the author or TL approver also made a reviewer on the CHANGELOG commit?

We recently changed the process from release engineer authored changes to cherry pick requestor authored changes. I do think updating the changelog makes sense. The issue most will run into is that it will cause conflicts as each change is landed.

@reidbaker perhaps the release process should be updated so the author or TL approver also made a reviewer on the CHANGELOG commit?

We recently changed the process from release engineer authored changes to cherry pick requestor authored changes. I do think updating the changelog makes sense. The issue most will run into is that it will cause conflicts as each change is landed.

I meant when release engineer sends out the changelog PR they could add the relevant authors as reviewers, or maybe only cc them would be sufficient to not slow down the release engineer. Just a thought, it's not that important. Thank you!

Why can't the version and changelog be released synchronously? Why does it take some time or even require creating an issue to solve it?

Why can't the version and changelog be released synchronously? Why does it take some time or even require creating an issue to solve it?

They can if the release engineer (me) does not make a mistake during the release process by shipping a build without the changelog updated. As to the why it takes time that answer is longer than I wish to type but the short version is about the security of the machines that can make a signed build, machine to machine access to signing keys and multi person authorization requirements for generating signed builds.