On Thu, Sep 21, 2017 at 10:57:20AM +0100, Milosz Wasilewski wrote:
On 20 September 2017 at 18:26, Greg KH gregkh@google.com wrote:
On Wed, Sep 20, 2017 at 06:22:11PM +0100, Milosz Wasilewski wrote:
On 20 September 2017 at 16:08, Greg KH gregkh@google.com wrote:
On Wed, Sep 20, 2017 at 01:37:49PM +0000, Linaro QA wrote:
Summary
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 089d7720383d7bc9ca6b8824a05dfa66f80d1f41 git describe: v4.9.51 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.51
No regressions (compared to build v4.9.50-79-g8d96ea41a3ee)
What is this random 79 patch tree on top of 4.9.50?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/c... than before that there was: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/c...
So you all triggered new test runs when I pushed out a new git tree and not off of when I did the announcement? Wait, I don't think I did a git push of the few new patches I added, did I?
that's automated in jenkins, so I think you did the push.
If we use make kernelversion both above commits would show 4.9.51-rc1.
Yeah, welcome to confusion, but again, that's how Linus's tree runs, and that's how we all know to identify the version.
can't the second one (with 79 patches) be named 4.9.51-rc2? Otherwise it will be very confusing stating "4.9.51-rc1 no regressions compared to 4.9.51-rc1".
In "theory" it should, but sometimes I have to add fix-up patches to the tree based on the -rc1 review. Sometimes I never do a -rc2 with them, as if the reporter says it fixes the issue, then I just do a release as-is.
Just like Linus doesn't do a -rc9 with the changes from -rc8 before he does a -final release.
thanks,
greg k-h