From: Guenter Roeck <linux@roeck-us.net>
To: Mark Brown <broonie@kernel.org>
Cc: Tom Gall <tom.gall@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.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 11:38:02 -0700 [thread overview]
Message-ID: <20170913183802.GA16037@roeck-us.net> (raw)
In-Reply-To: <20170913163655.nfdhr5gnl4sn4zsz@sirena.org.uk>
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.
>
I should have been more specific; my comment assumed that the tag
would be reapplied (using git tag -f) to the tip of the rebased branch.
There should be no problem if each branch update is accompanied by
a new tag.
Guenter
> > 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.
next prev parent reply other threads:[~2017-09-13 18:38 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 [this message]
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
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=20170913183802.GA16037@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).