On Sat, Aug 03, 2019 at 09:09:32AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Aug 02, 2019 at 07:21:05PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > On Fri, 02 Aug 2019 11:39:54 +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 5.2.6 release.
> > > There are 20 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Sun 04 Aug 2019 09:19:34 AM UTC.
> > > Anything received after that time might be too late.
> > > 
> > > The whole patch series can be found in one patch at:
> > > 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.6-rc1.gz
> > > or in the git tree and branch at:
> > > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.2.y
> > > and the diffstat can be found below.
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > All tests passing for Tegra ...
> > 
> > Test results for stable-v5.2:
> >     12 builds:	12 pass, 0 fail
> >     22 boots:	22 pass, 0 fail
> >     38 tests:	38 pass, 0 fail
> > 
> > Linux version:	5.2.6-rc1-gbe893953fcc2
> > Boards tested:	tegra124-jetson-tk1, tegra186-p2771-0000,
> >                 tegra194-p2972-0000, tegra20-ventana,
> >                 tegra210-p2371-2180, tegra30-cardhu-a04
> 
> Great!  Thanks for testing all of these and letting me know.

Hi Greg,

I stumbled across something as I was attempting to automate more parts
of our process to generate these reports. The original test results were
from a different version of the tree: 5.2.6-rc1-gdbc7f5c7df28. I suspect
that's the same thing that you were discussing with Pavel regarding the
IP tunnel patch that was added subsequent to the announcement.

Just for my understanding, does this mean that the patch still makes it
into the 5.2.6 release, or was it supposed to go into 5.2.7?

One problem that I ran into was that when I tried to correlate the test
results with your announcement email, there's no indication other than
the branch name and the release candidate name (5.2.6-rc1 in this case),
so there's no way to uniquely identify which test run belongs to the
announcement. Given that there are no tags for the release candidates
means that that's also not an option to uniquely associate with the
builds and tests.

While the differences between the two builds are very minor here, I
wonder if there could perhaps in the future be a problem where I report
successful results for a test, but the same tests would be broken by a
patch added to the stable-rc branch subsequent to the announcement. The
test report would be misleading in that case.

I noticed that you do add a couple of X-KernelTest-* headers to your
announcement emails, so I'm wondering if perhaps it was possible for you
to add another one that contains the exact SHA1 that corresponds to the
snapshot that's the release candidate. That would allow everyone to
uniquely associate test results with a specific release candidate.

That said, perhaps I've just got this all wrong and there's already a
way to connect all the dots that I'm not aware of. Or maybe I'm being
too pedantic here?

Thierry