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@xxxxxxxxxx> > > > > 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
Attachment:
signature.asc
Description: PGP signature
