Summary ------------------------------------------------------------------------
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.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-4.9-oe/build/v4.9.51
No regressions (compared to build v4.9.50)
Boards, architectures and test suites: -------------------------------------
hi6220-hikey - arm64 * libhugetlbfs * ltp-syscalls-tests * kselftest * boot
dell-poweredge-r200 - x86_64 * libhugetlbfs * ltp-syscalls-tests * kselftest * boot
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
On Wed, Sep 20, 2017 at 01:17:15PM +0000, Linaro QA wrote:
Summary
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.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-4.9-oe/build/v4.9.51
What is the difference between this test run and the "lkft/linux-stable-4.9-rc-oe" test run?
And again, what is "oe", and why do we care about it here? What does its kernel tree contain that matters?
thanks,
greg k-h
On Wed, Sep 20, 2017 at 05:07:58PM +0200, Greg KH wrote:
On Wed, Sep 20, 2017 at 01:17:15PM +0000, Linaro QA wrote:
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
What is the difference between this test run and the "lkft/linux-stable-4.9-rc-oe" test run?
It's stable vs the stable-rc (ie, the actual official release of what was in the -rc tree).
And again, what is "oe", and why do we care about it here? What does its kernel tree contain that matters?
It's the userspace - we're just in a meeting now where there was a decision to change things around so the format is like the one that we were discussing in the other thread which is hopefully clearer in separating out the kernel from the userspace.
On Wed, Sep 20, 2017 at 04:21:34PM +0100, Mark Brown wrote:
On Wed, Sep 20, 2017 at 05:07:58PM +0200, Greg KH wrote:
On Wed, Sep 20, 2017 at 01:17:15PM +0000, Linaro QA wrote:
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
What is the difference between this test run and the "lkft/linux-stable-4.9-rc-oe" test run?
It's stable vs the stable-rc (ie, the actual official release of what was in the -rc tree).
Hm, so when I do a new release, we are going to get this tested twice, given that both repos get the "release"? That doesn't seem wise :)
And again, what is "oe", and why do we care about it here? What does its kernel tree contain that matters?
It's the userspace - we're just in a meeting now where there was a decision to change things around so the format is like the one that we were discussing in the other thread which is hopefully clearer in separating out the kernel from the userspace.
Yes that would be great, saw it after I wrote this one.
greg k-h
On Wed, Sep 20, 2017 at 06:52:21PM +0200, Greg KH wrote:
On Wed, Sep 20, 2017 at 04:21:34PM +0100, Mark Brown wrote:
It's stable vs the stable-rc (ie, the actual official release of what was in the -rc tree).
Hm, so when I do a new release, we are going to get this tested twice, given that both repos get the "release"? That doesn't seem wise :)
But... more testing is better right? :) It's pretty much what all the other automatic stuff does, so long as the testing load doesn't overwhelm the systems it's going to be the easiest way to help people find things if they go trawling for historic information and I guess also provides a bit of security against mistakes.
On Wed, Sep 20, 2017 at 06:00:57PM +0100, Mark Brown wrote:
On Wed, Sep 20, 2017 at 06:52:21PM +0200, Greg KH wrote:
On Wed, Sep 20, 2017 at 04:21:34PM +0100, Mark Brown wrote:
It's stable vs the stable-rc (ie, the actual official release of what was in the -rc tree).
Hm, so when I do a new release, we are going to get this tested twice, given that both repos get the "release"? That doesn't seem wise :)
But... more testing is better right? :) It's pretty much what all the other automatic stuff does, so long as the testing load doesn't overwhelm the systems it's going to be the easiest way to help people find things if they go trawling for historic information and I guess also provides a bit of security against mistakes.
When it is the same exact git commit id, hopefully something in the test framework will "know" it has already started a test run for that same commit...
Well, I can dream...
greg k-h
On Wed, Sep 20, 2017 at 07:15:40PM +0200, Greg KH wrote:
On Wed, Sep 20, 2017 at 06:00:57PM +0100, Mark Brown wrote:
But... more testing is better right? :) It's pretty much what all the other automatic stuff does, so long as the testing load doesn't overwhelm the systems it's going to be the easiest way to help people find things if they go trawling for historic information and I guess also provides a bit of security against mistakes.
When it is the same exact git commit id, hopefully something in the test framework will "know" it has already started a test run for that same commit...
Well, I can dream...
To me the report vs the duplicate test runs are a separate thing - it's probably useful to do the report for consistency, if it happens to recycle old test results to do it that's just a useful implementation optimization (and possibly you might get a few extras if there's new or fixed infrastructure somewhere).
Though wouldn't the commit ID have changed anyway when you updated the Makefile from -rc to final?
On Thu, Sep 21, 2017 at 03:49:38PM +0100, Mark Brown wrote:
On Wed, Sep 20, 2017 at 07:15:40PM +0200, Greg KH wrote:
On Wed, Sep 20, 2017 at 06:00:57PM +0100, Mark Brown wrote:
But... more testing is better right? :) It's pretty much what all the other automatic stuff does, so long as the testing load doesn't overwhelm the systems it's going to be the easiest way to help people find things if they go trawling for historic information and I guess also provides a bit of security against mistakes.
When it is the same exact git commit id, hopefully something in the test framework will "know" it has already started a test run for that same commit...
Well, I can dream...
To me the report vs the duplicate test runs are a separate thing - it's probably useful to do the report for consistency, if it happens to recycle old test results to do it that's just a useful implementation optimization (and possibly you might get a few extras if there's new or fixed infrastructure somewhere).
Though wouldn't the commit ID have changed anyway when you updated the Makefile from -rc to final?
Yes, but that commit is is identical to the commit id in the linux-stable tree, as that is where it comes from. The point being that the two trees are related, so if the same exact commit shows up in both places, no need to run the tests twice, right?
I don't know if the system can handle stuff like this though, if not, it's not a big deal, just will cut down on test system loads, and email outputs.
thanks,
greg k-h
kernel-build-reports@lists.linaro.org
-
Greg KH -
Linaro QA -
Mark Brown