From: Guenter Roeck <linux@roeck-us.net>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mark Brown <broonie@kernel.org>, Tom Gall <tom.gall@linaro.org>,
LKML <linux-kernel@vger.kernel.org>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
Shuah Khan <shuahkh@osg.samsung.com>,
patches@kernelci.org,
Ben Hutchings <ben.hutchings@codethink.co.uk>,
linux- stable <stable@vger.kernel.org>
Subject: Re: [PATCH 4.9 00/14] 4.9.50-stable review
Date: Wed, 13 Sep 2017 12:18:12 -0700 [thread overview]
Message-ID: <20170913191812.GA3478@roeck-us.net> (raw)
In-Reply-To: <20170913185538.GA26390@kroah.com>
On Wed, Sep 13, 2017 at 11:55:38AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote:
> > On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote:
> > > On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:
> >
> > > > 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).
> >
> > Rebasing shouldn't be an issue for tags (they're not branches), and
> > changes would a disaster no matter what.
>
> Can you push --force a tag? I've never tried that, don't want to mess
> up a kernel.org tree by trying it out :)
Yes. I don't recall if it is a direct --force or if you would have to
remove the original tag first (with git push <repo> :refs/tags/<tag>).
Guenter
>
> Because of that, I haven't been tagging the -rc trees, as I didn't think
> it was really needed. The linux-stable-rc tree is just a "convenience"
> for people to use for testing, it's not really a "cannonical" tree at
> the moment because of that.
>
> > > Given that, I think reporting the SHA is better, since it reports clearly
> > > which version was tested.
> >
> > This definitely makes sense though (especially in a generalized tool),
> > defensively if nothing else. I think you ideally want both.
>
> Yes, use 'make kernelversion' to get the kernel's view of the release
> number, don't use 'git describe' please, as it does not know about
> changes to the Makefile (nor should it...)
>
> thanks,
>
> greg k-h
next prev parent reply other threads:[~2017-09-13 19:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-12 16:58 [PATCH 4.9 00/14] 4.9.50-stable review Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 01/14] mtd: nand: mxc: Fix mxc_v1 ooblayout Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 02/14] mtd: nand: qcom: fix read failure without complete bootchain Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 03/14] mtd: nand: qcom: fix config error for BCH Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 04/14] nvme-fabrics: generate spec-compliant UUID NQNs Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 05/14] btrfs: resume qgroup rescan on rw remount Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 06/14] selftests/x86/fsgsbase: Test selectors 1, 2, and 3 Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 07/14] mm/memory.c: fix mem_cgroup_oom_disable() call missing Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 09/14] ALSA: msnd: Optimize / harden DSP and MIDI loops Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 10/14] Bluetooth: Properly check L2CAP config option output buffer length Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 11/14] ARM64: dts: marvell: armada-37xx: Fix GIC maintenance interrupt Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 12/14] ARM: 8692/1: mm: abort uaccess retries upon fatal signal Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 13/14] NFS: Fix 2 use after free issues in the I/O code Greg Kroah-Hartman
2017-09-12 16:58 ` [PATCH 4.9 14/14] NFS: Sync the correct byte range during synchronous writes Greg Kroah-Hartman
2017-09-13 0:11 ` [PATCH 4.9 00/14] 4.9.50-stable review Shuah Khan
2017-09-13 2:27 ` Tom Gall
2017-09-13 3:49 ` Greg Kroah-Hartman
2017-09-13 15:05 ` Tom Gall
2017-09-13 15:22 ` Guenter Roeck
2017-09-13 16:36 ` Mark Brown
2017-09-13 18:38 ` Guenter Roeck
2017-09-13 18:55 ` Mark Brown
2017-09-13 18:55 ` Greg Kroah-Hartman
2017-09-13 19:12 ` Mark Brown
2017-09-13 19:18 ` Guenter Roeck [this message]
2017-09-13 21:30 ` Greg Kroah-Hartman
2017-09-13 22:08 ` Mark Brown
2017-09-14 2:18 ` Willy Tarreau
2017-09-14 5:34 ` Guenter Roeck
2017-09-14 22:57 ` Kevin Hilman
2017-09-13 14:33 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170913191812.GA3478@roeck-us.net \
--to=linux@roeck-us.net \
--cc=akpm@linux-foundation.org \
--cc=ben.hutchings@codethink.co.uk \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@kernelci.org \
--cc=shuahkh@osg.samsung.com \
--cc=stable@vger.kernel.org \
--cc=tom.gall@linaro.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).