> But this process make the end user hard to know what's in the release > since so many patches enter into the branch after it create.
> The difference between commit id or order make the user life even more harder. I don't see how so. If someone is interested in a released branch why bother with the diff in history with master? Release notes are there to highlight significant new features and the branch git log is also available. And users of tarballs don't have any git log. > The ideal process is that only the block issue after community vote > can be cherry-pick to the release branch once the release branch is > created. All of the cherry-picked changes went through PRs, even the most trivial of them. The reason being (other than to kick the CI checks and benefit from the tests) is for everyone to see what's being back ported. On Mon, Apr 20, 2020 at 4:04 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > > The difference between commit id or order make the user life even more > > harder. > > The release tarballs have no GIT information in them. That information > is available on the branch, but AFAIK all users of releases use the > tarballs with no git information. Only the release notes describes what > is in the release. > >
