Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Guenter Roeck]

On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:
> On Tue, Sep 12, 2017 at 10:49 PM, Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Tue, Sep 12, 2017 at 09:27:45PM -0500, Tom Gall wrote:
> >>
> >> > On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> <snip>
> >>
> >> Results from testing on Linaroâs small but growing test farm.
> >>
> >> ------------------------------------------------------------------------
> >> Summary
> >> ------------------------------------------------------------------------
> >>
> >> kernel: 4.9.50-rc1
> >> kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> kernel-branch: linux-4.9.y
> >> kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
> >> kernel-describe: v4.9.49-15-gedfaa5f69b96
> >
> > Howcome 'git describe' does not show 4.9.50-rc1?
> 
> git describe looks for the most recent tag.
> 
> Since there isn't a 4.9.50-rc1 tag, we get 4.9.49 + 15 patches etc.
> 
> Does it make sense to create tags for the RC(s) so git describe gets
> it right? Given the right version is in the Makefile kinda feels like
> that'd be a belt and suspenders approach.
> 
Depends. A tag only makes sense if the branch isn't rebased, otherwise
(if the tag can change) it would be misleading (as would be to report
the version number from Makefile).

I usually don't report the SHA, mostly for historic reasons
from times when I had to create the git branch myself. I sometimes
report it if/when I notice that the branch changed after the review
request e-mail.

Given that, I think reporting the SHA is better, since it reports clearly
which version was tested.

Guenter