On Mon, Apr 20, 2020 at 11:21 PM Abdelatif Guettouche <abdelatif.guettou...@gmail.com> wrote: > > > 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?
Yes, only if the release don't have any bug, but the software always has bug, right? how people fix the issue? the first step is git clone the code from github: 1.Review the difference between the release and master 2.Review the history to see whether other people already fix the issue 3.... > Release notes are there to highlight significant new features and the > branch git log is also available. Release notes also need add a section to describe the pathes we cherry-pick from master after the branch is created since they are very important information. > 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. > > > >
