lkml.org 
[lkml]   [2017]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4.9 00/14] 4.9.50-stable review
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@linuxfoundation.org> 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@linuxfoundation.org> 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

\
 
 \ /
  Last update: 2017-09-13 17:22    [W:0.073 / U:0.352 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site