Summary ------------------------------------------------------------------------
kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git kernel-branch: linux-4.4.y kernel-commit: b8c205d855764e3db05a17ab4d03a19a5d609bdd kernel-describe: v4.4.87-32-gb8c205d85576 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.87-32-g...
No regressions (compared to build v4.4.87)
Boards, architectures and test suites: -------------------------------------
dell-poweredge-r200 - x86_64 * boot * ltp-syscalls-tests * libhugetlbfs * kselftest
Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports
On Tue, Sep 12, 2017 at 06:50:31PM +0000, Linaro QA wrote:
Summary
kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git kernel-branch: linux-4.4.y kernel-commit: b8c205d855764e3db05a17ab4d03a19a5d609bdd kernel-describe: v4.4.87-32-gb8c205d85576
Why is this 32 patches after 4.4.87?
WHat is "-rc-4.4-oe"? And why would I remember any of this?
Can you have a "description of what you are testing" somewhere around here so I have a clue?
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.87-32-g...
No regressions (compared to build v4.4.87)
Boards, architectures and test suites:
dell-poweredge-r200 - x86_64
- boot
- ltp-syscalls-tests
- libhugetlbfs
- kselftest
So one x86 box built and booted and ran 3 test suites?
My laptop did that :)
But ok, baby steps...
greg k-h
Hi,
On Tue, Sep 12, 2017 at 3:12 PM, Greg KH gregkh@google.com wrote:
On Tue, Sep 12, 2017 at 06:50:31PM +0000, Linaro QA wrote:
Summary
kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git kernel-branch: linux-4.4.y kernel-commit: b8c205d855764e3db05a17ab4d03a19a5d609bdd kernel-describe: v4.4.87-32-gb8c205d85576
Why is this 32 patches after 4.4.87?
It's from the git describe. If you look at kernelci results you'll see exactly the same thing.
I agree I also want to see pulling from the Makefile for the proper version. I'll talk to Fathi.
WHat is "-rc-4.4-oe"? And why would I remember any of this?
first 2 bits are obvious, next is the user space being used. OE is Open Embedded as you might remember from past meetings.
You snipped the link that describes the report, terms contained within etc.
Can you have a "description of what you are testing" somewhere around here so I have a clue?
Yes, there is supposed to be a link to the test source code used for the tests. That's pending. Guessing the next time we gen reports that'll be there.
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.87-32-g...
No regressions (compared to build v4.4.87)
Boards, architectures and test suites:
dell-poweredge-r200 - x86_64
- boot
- ltp-syscalls-tests
- libhugetlbfs
- kselftest
So one x86 box built and booted and ran 3 test suites?
My laptop did that :)
dell power edge as your laptop? Must be fun on airplanes!
But ok, baby steps...
Yeah. Seriously, looks like the HiKey 4.4 job didn't fire right. We're on it.
X15s look to be passing health checks so in theory we should start generating 32 bit ARM results PDQ.
greg k-h _______________________________________________ Lts-dev mailing list Lts-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lts-dev
On 13 September 2017 at 05:28, Tom Gall tom.gall@linaro.org wrote:
Hi,
On Tue, Sep 12, 2017 at 3:12 PM, Greg KH gregkh@google.com wrote:
On Tue, Sep 12, 2017 at 06:50:31PM +0000, Linaro QA wrote:
Summary
kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git kernel-branch: linux-4.4.y kernel-commit: b8c205d855764e3db05a17ab4d03a19a5d609bdd kernel-describe: v4.4.87-32-gb8c205d85576
Why is this 32 patches after 4.4.87?
It's from the git describe. If you look at kernelci results you'll see exactly the same thing.
That's correct.
As discussed before, it's the output of git describe. Since Greg doesn't push rc tags in the stable rc tree (and doesn't want to), it is expected: i.e. the current head of my "parent" branch is based on v4.4.87, but since it has a few commits on top of that, describe has added the number of additional commits ("32") and an abbreviated object name for the commit itself ("b8c205d85576") at the end.
I agree I also want to see pulling from the Makefile for the proper version. I'll talk to Fathi.
It isn't more accurate than git describe and even lead to incorrect version. It's randomly updated or not by the developers. See previous discussion in the thread "Wrong kernel version string in lkft reports?".
If it has to be implemented, it will be another custom template. The new template applied to Greg's rc trees only due to the lack of rc tags.
WHat is "-rc-4.4-oe"? And why would I remember any of this?
first 2 bits are obvious, next is the user space being used. OE is Open Embedded as you might remember from past meetings.
You snipped the link that describes the report, terms contained within etc.
Can you have a "description of what you are testing" somewhere around here so I have a clue?
Yes, there is supposed to be a link to the test source code used for the tests. That's pending. Guessing the next time we gen reports that'll be there.
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.87-32-g...
No regressions (compared to build v4.4.87)
Boards, architectures and test suites:
dell-poweredge-r200 - x86_64
- boot
- ltp-syscalls-tests
- libhugetlbfs
- kselftest
So one x86 box built and booted and ran 3 test suites?
My laptop did that :)
dell power edge as your laptop? Must be fun on airplanes!
But ok, baby steps...
Yeah. Seriously, looks like the HiKey 4.4 job didn't fire right. We're on it.
X15s look to be passing health checks so in theory we should start generating 32 bit ARM results PDQ.
greg k-h _______________________________________________ Lts-dev mailing list Lts-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lts-dev
-- Regards, Tom
Director, Linaro Mobile Group Linaro.org │ Open source software for ARM SoCs irc: tgall_foo | skype : tom_gall
"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian _______________________________________________ Lts-dev mailing list Lts-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lts-dev
On Wed, Sep 13, 2017 at 10:01:57AM +0300, Fathi Boudra wrote:
On 13 September 2017 at 05:28, Tom Gall tom.gall@linaro.org wrote:
It's from the git describe. If you look at kernelci results you'll see exactly the same thing.
That's correct.
As discussed before, it's the output of git describe. Since Greg doesn't push rc tags in the stable rc tree (and doesn't want to), it is expected:
I think this is coming back to the fact that it's hard to work out what the tree is - it's not sufficiently obvious that this is an -rc.
I agree I also want to see pulling from the Makefile for the proper version. I'll talk to Fathi.
It isn't more accurate than git describe and even lead to incorrect version. It's randomly updated or not by the developers. See previous discussion in the thread "Wrong kernel version string in lkft reports?".
Very few trees will set versions so it's really not sensible to rely on that, that really only works for a small subset of trees and not all commits in those trees (eg, Linus only tags on releases but updates in between releases all the time).
On Tue, Sep 12, 2017 at 09:28:51PM -0500, Tom Gall wrote:
On Tue, Sep 12, 2017 at 3:12 PM, Greg KH gregkh@google.com wrote:
WHat is "-rc-4.4-oe"? And why would I remember any of this?
first 2 bits are obvious, next is the user space being used. OE is Open Embedded as you might remember from past meetings.
I think Greg has a good point here, it's really not easy to see at a glance what the trees are.
People read things by pattern matching and the patterns that this is using are not like the patterns people normally use to describe kernels. At a glance the LKFT subjects look like they're for some derivative kernel, not the kernels they're actually for, since they just add elements separated by - too.
Kernel maintainers get a lot of e-mail, often poorly directed. Being able to quickly figure out what to pay attention to is key, and for a lot of us we're doing that based on the subject lines of messages. As ever look at what the other bots are doing, what you're sending now are internal names for jobs that the infrastructure uses not display names for end users.
You snipped the link that describes the report, terms contained within etc.
Honestly if we're expecting someone to open the e-mail and then follow a link to figure out if this is something interesting to them then that's not success.
On 13 September 2017 at 16:06, Mark Brown broonie@kernel.org wrote:
On Tue, Sep 12, 2017 at 09:28:51PM -0500, Tom Gall wrote:
On Tue, Sep 12, 2017 at 3:12 PM, Greg KH gregkh@google.com wrote:
WHat is "-rc-4.4-oe"? And why would I remember any of this?
first 2 bits are obvious, next is the user space being used. OE is Open Embedded as you might remember from past meetings.
I think Greg has a good point here, it's really not easy to see at a glance what the trees are.
People read things by pattern matching and the patterns that this is using are not like the patterns people normally use to describe kernels. At a glance the LKFT subjects look like they're for some derivative kernel, not the kernels they're actually for, since they just add elements separated by - too.
A couple of weeks ago we renamed the internal projects. I posted the proposal of naming scheme and there were no comments. I'm perfectly OK to change the names we're using, but what should we change them to? Is there any better naming convention to use?
Kernel maintainers get a lot of e-mail, often poorly directed. Being able to quickly figure out what to pay attention to is key, and for a lot of us we're doing that based on the subject lines of messages. As ever look at what the other bots are doing, what you're sending now are internal names for jobs that the infrastructure uses not display names for end users.
from kernelci: lsk/linux-linaro-lsk-v4.4-android How is that different to what lkft sends? How am I supposed to know what 'lsk' means without opening the email?
milosz
You snipped the link that describes the report, terms contained within etc.
Honestly if we're expecting someone to open the e-mail and then follow a link to figure out if this is something interesting to them then that's not success.
Lts-dev mailing list Lts-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lts-dev
On Tue, Sep 19, 2017 at 02:38:25PM +0100, Milosz Wasilewski wrote:
On 13 September 2017 at 16:06, Mark Brown broonie@kernel.org wrote:
first 2 bits are obvious, next is the user space being used. OE is Open Embedded as you might remember from past meetings.
I think Greg has a good point here, it's really not easy to see at a glance what the trees are.
People read things by pattern matching and the patterns that this is using are not like the patterns people normally use to describe kernels. At a glance the LKFT subjects look like they're for some derivative kernel, not the kernels they're actually for, since they just add elements separated by - too.
A couple of weeks ago we renamed the internal projects. I posted the proposal of naming scheme and there were no comments. I'm perfectly OK to change the names we're using, but what should we change them to? Is there any better naming convention to use?
I think the problem is that you are trying to use the internal name that bits of LKFT uses as a display name for end users and that's not going to end well - you probably need at least some blanks and some splitting things up.
Kernel maintainers get a lot of e-mail, often poorly directed. Being able to quickly figure out what to pay attention to is key, and for a lot of us we're doing that based on the subject lines of messages. As ever look at what the other bots are doing, what you're sending now are internal names for jobs that the infrastructure uses not display names for end users.
from kernelci: lsk/linux-linaro-lsk-v4.4-android How is that different to what lkft sends? How am I supposed to know what 'lsk' means without opening the email?
You're thinking about that the wrong way round - kernelci is displaying names from the tree it's working with, not making up new names for things which don't otherwise exist.
If you know what the LSK is and care about it then you know that's interesting, and the branch name there is exactly the branch name in the LSK tree so if you work with it you'll have seen that string. On my system I can do git operations on lsk/linux-linaro-lsk-v4.4-android since I named the remote for LSK. If someone is getting the LSK mails they'll probably have no problem.
On 19 September 2017 at 15:00, Mark Brown broonie@kernel.org wrote:
On Tue, Sep 19, 2017 at 02:38:25PM +0100, Milosz Wasilewski wrote:
On 13 September 2017 at 16:06, Mark Brown broonie@kernel.org wrote:
first 2 bits are obvious, next is the user space being used. OE is Open Embedded as you might remember from past meetings.
I think Greg has a good point here, it's really not easy to see at a glance what the trees are.
People read things by pattern matching and the patterns that this is using are not like the patterns people normally use to describe kernels. At a glance the LKFT subjects look like they're for some derivative kernel, not the kernels they're actually for, since they just add elements separated by - too.
A couple of weeks ago we renamed the internal projects. I posted the proposal of naming scheme and there were no comments. I'm perfectly OK to change the names we're using, but what should we change them to? Is there any better naming convention to use?
I think the problem is that you are trying to use the internal name that bits of LKFT uses as a display name for end users and that's not going to end well - you probably need at least some blanks and some splitting things up.
I'm still waiting for a proposal what and how to change. As I wrote, I have no problem changing things.
Kernel maintainers get a lot of e-mail, often poorly directed. Being able to quickly figure out what to pay attention to is key, and for a lot of us we're doing that based on the subject lines of messages. As ever look at what the other bots are doing, what you're sending now are internal names for jobs that the infrastructure uses not display names for end users.
from kernelci: lsk/linux-linaro-lsk-v4.4-android How is that different to what lkft sends? How am I supposed to know what 'lsk' means without opening the email?
You're thinking about that the wrong way round - kernelci is displaying names from the tree it's working with, not making up new names for things which don't otherwise exist.
Right, so because you know that 'lsk' means everyone else know as well. The git repo is https://git.linaro.org/kernel/linux-linaro-stable.git. How does this map to 'lsk'? It's exactly the same story. 'lsk' is kernelci's internal project name and this somehow is OK while lkft's internal project names are not.
milosz
If you know what the LSK is and care about it then you know that's interesting, and the branch name there is exactly the branch name in the LSK tree so if you work with it you'll have seen that string. On my system I can do git operations on lsk/linux-linaro-lsk-v4.4-android since I named the remote for LSK. If someone is getting the LSK mails they'll probably have no problem.
On Tue, Sep 19, 2017 at 04:07:04PM +0100, Milosz Wasilewski wrote:
On 19 September 2017 at 15:00, Mark Brown broonie@kernel.org wrote:
I think the problem is that you are trying to use the internal name that bits of LKFT uses as a display name for end users and that's not going to end well - you probably need at least some blanks and some splitting things up.
I'm still waiting for a proposal what and how to change. As I wrote, I have no problem changing things.
Personally for:
lkft/linux-stable-rc-4.4-oe: no regressions found in build v4.4.87-32-gb8c205d85576
I'd have something like:
stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE
off the top of my head, though other people might want to bikeshed that a bit more.
from kernelci: lsk/linux-linaro-lsk-v4.4-android How is that different to what lkft sends? How am I supposed to know what 'lsk' means without opening the email?
You're thinking about that the wrong way round - kernelci is displaying names from the tree it's working with, not making up new names for things which don't otherwise exist.
Right, so because you know that 'lsk' means everyone else know as well. The git repo is
I don't know where that one came from specifically but I suspect you'll find most of the names come from what people ask for ("could you add my $NAME tree at $URL" or similar).
https://git.linaro.org/kernel/linux-linaro-stable.git. How does this map to 'lsk'? It's exactly the same story. 'lsk' is kernelci's internal project name and this somehow is OK while lkft's internal project names are not.
It's not just that leading bit, it's the whole name that's different with what LKFT is doing especially the attempt to put the tree, branch and userspace into the same unbroken string.
On Sep 19, 2017, at 10:50 AM, Mark Brown broonie@kernel.org wrote:
On Tue, Sep 19, 2017 at 04:07:04PM +0100, Milosz Wasilewski wrote:
On 19 September 2017 at 15:00, Mark Brown broonie@kernel.org wrote:
I think the problem is that you are trying to use the internal name that bits of LKFT uses as a display name for end users and that's not going to end well - you probably need at least some blanks and some splitting things up.
I'm still waiting for a proposal what and how to change. As I wrote, I have no problem changing things.
Personally for:
lkft/linux-stable-rc-4.4-oe: no regressions found in build v4.4.87-32-gb8c205d85576
I'd have something like:
stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE
Yeah I see where you’re going with that. You could further pre-pend something like:
kernel.org/stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE linaro.org/hikey-stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE AOSP/common.git/android-4.4-o: no regressions found for v4.4.87-32-gb8c205d85576 on Android
This attempts to then give more of a pointer as to where the tree is coming from.
Example 1: community tree, git name, followed by branch Example 2: linaro.org tree that blends the upstream with the hikey support for 4.4 Example 3: AOSP project etc
off the top of my head, though other people might want to bikeshed that a bit more.
from kernelci: lsk/linux-linaro-lsk-v4.4-android How is that different to what lkft sends? How am I supposed to know what 'lsk' means without opening the email?
You're thinking about that the wrong way round - kernelci is displaying names from the tree it's working with, not making up new names for things which don't otherwise exist.
Right, so because you know that 'lsk' means everyone else know as well. The git repo is
I don't know where that one came from specifically but I suspect you'll find most of the names come from what people ask for ("could you add my $NAME tree at $URL" or similar).
https://git.linaro.org/kernel/linux-linaro-stable.git. How does this map to 'lsk'? It's exactly the same story. 'lsk' is kernelci's internal project name and this somehow is OK while lkft's internal project names are not.
It's not just that leading bit, it's the whole name that's different with what LKFT is doing especially the attempt to put the tree, branch and userspace into the same unbroken string.
On Tue, Sep 19, 2017 at 11:02:24AM -0500, Tom Gall wrote:
On Sep 19, 2017, at 10:50 AM, Mark Brown broonie@kernel.org wrote:
On Tue, Sep 19, 2017 at 04:07:04PM +0100, Milosz Wasilewski wrote:
On 19 September 2017 at 15:00, Mark Brown broonie@kernel.org wrote:
I think the problem is that you are trying to use the internal name that bits of LKFT uses as a display name for end users and that's not going to end well - you probably need at least some blanks and some splitting things up.
I'm still waiting for a proposal what and how to change. As I wrote, I have no problem changing things.
Personally for:
lkft/linux-stable-rc-4.4-oe: no regressions found in build v4.4.87-32-gb8c205d85576
I'd have something like:
stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE
Yeah I see where you’re going with that. You could further pre-pend something like:
kernel.org/stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE linaro.org/hikey-stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE AOSP/common.git/android-4.4-o: no regressions found for v4.4.87-32-gb8c205d85576 on Android
This attempts to then give more of a pointer as to where the tree is coming from.
Example 1: community tree, git name, followed by branch Example 2: linaro.org tree that blends the upstream with the hikey support for 4.4 Example 3: AOSP project etc
That's much better.
But again, I don't know what -rc you are actually testing for that first one (or really any of them.)
Your refusal to use 'make kernelversion' to drag in the -rc number seems odd to me. I can't put tags in the -rc git tree, so you can't ever work off of that, sorry.
And again, "v4.4.87-32-gb8c205d85576" only means that you are running something based on 4.4.87 + 32 patches. I generate the linux-stable-rc tree by scripts and have no idea what the git commit id is, as it gets thrown away and rewritten a lot.
Now if you said: "v4.4.88-rc1" that would make sense, as that is how everyone else refers to these trees.
If working off of the git tree is too much work, just grab the quilt series and generate your own kernel tree, or pick things up from the emails and apply those, that also works. The git tree is made to try to make it easier for you all, but please don't treat it as anyone can ever refer to a git commit id and it will be there tomorrow :)
thanks,
greg k-h
On Tue, Sep 19, 2017 at 11:02:24AM -0500, Tom Gall wrote:
On Sep 19, 2017, at 10:50 AM, Mark Brown broonie@kernel.org wrote:
I'd have something like:
stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE
Yeah I see where you’re going with that. You could further pre-pend something like:
kernel.org/stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE
One thing to watch out for is that if your prefix becomes too long the actual subject gets obscured - you've got about 40 characters before that starts to happen.
On 19 September 2017 at 17:02, Tom Gall tom.gall@linaro.org wrote:
On Sep 19, 2017, at 10:50 AM, Mark Brown broonie@kernel.org wrote:
On Tue, Sep 19, 2017 at 04:07:04PM +0100, Milosz Wasilewski wrote:
On 19 September 2017 at 15:00, Mark Brown broonie@kernel.org wrote:
I think the problem is that you are trying to use the internal name that bits of LKFT uses as a display name for end users and that's not going to end well - you probably need at least some blanks and some splitting things up.
I'm still waiting for a proposal what and how to change. As I wrote, I have no problem changing things.
Personally for:
lkft/linux-stable-rc-4.4-oe: no regressions found in build v4.4.87-32-gb8c205d85576
I'd have something like:
stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE
Yeah I see where you’re going with that. You could further pre-pend something like:
kernel.org/stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE linaro.org/hikey-stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE AOSP/common.git/android-4.4-o: no regressions found for v4.4.87-32-gb8c205d85576 on Android
This attempts to then give more of a pointer as to where the tree is coming from.
Example 1: community tree, git name, followed by branch Example 2: linaro.org tree that blends the upstream with the hikey support for 4.4 Example 3: AOSP project etc
OK. So the real names that we currently have will be: android.googlesource.com/hikey-linaro/android-hikey-linaro-4.4 git.linaro.org/linux-lts/lts-4.4.y-hikey git.linaro.org/arm64-stable-rc/4.4.y-rc-hikey git.kernel.org/linux/master git.kernel.org/linux-next/master git.kernel.org/linux-stable/linux-4.4.y git.kernel.org/linux-stable/linux-4.9.y git.kernel.org/linux-stable-rc/linux-4.4.y git.kernel.org/linux-stable-rc/linux-4.9.y
Is that what we want to be in the subject?
milosz
off the top of my head, though other people might want to bikeshed that a bit more.
from kernelci: lsk/linux-linaro-lsk-v4.4-android How is that different to what lkft sends? How am I supposed to know what 'lsk' means without opening the email?
You're thinking about that the wrong way round - kernelci is displaying names from the tree it's working with, not making up new names for things which don't otherwise exist.
Right, so because you know that 'lsk' means everyone else know as well. The git repo is
I don't know where that one came from specifically but I suspect you'll find most of the names come from what people ask for ("could you add my $NAME tree at $URL" or similar).
https://git.linaro.org/kernel/linux-linaro-stable.git. How does this map to 'lsk'? It's exactly the same story. 'lsk' is kernelci's internal project name and this somehow is OK while lkft's internal project names are not.
It's not just that leading bit, it's the whole name that's different with what LKFT is doing especially the attempt to put the tree, branch and userspace into the same unbroken string.
On 19 September 2017 at 16:50, Mark Brown broonie@kernel.org wrote:
On Tue, Sep 19, 2017 at 04:07:04PM +0100, Milosz Wasilewski wrote:
On 19 September 2017 at 15:00, Mark Brown broonie@kernel.org wrote:
I think the problem is that you are trying to use the internal name that bits of LKFT uses as a display name for end users and that's not going to end well - you probably need at least some blanks and some splitting things up.
I'm still waiting for a proposal what and how to change. As I wrote, I have no problem changing things.
Personally for:
lkft/linux-stable-rc-4.4-oe: no regressions found in build v4.4.87-32-gb8c205d85576
I'd have something like:
stable-rc/linux-v4.4.y: no regressions found for v4.4.87-32-gb8c205d85576 on OE
I can try that. Most of the bits are already in place.
off the top of my head, though other people might want to bikeshed that a bit more.
from kernelci: lsk/linux-linaro-lsk-v4.4-android How is that different to what lkft sends? How am I supposed to know what 'lsk' means without opening the email?
You're thinking about that the wrong way round - kernelci is displaying names from the tree it's working with, not making up new names for things which don't otherwise exist.
Right, so because you know that 'lsk' means everyone else know as well. The git repo is
I don't know where that one came from specifically but I suspect you'll find most of the names come from what people ask for ("could you add my $NAME tree at $URL" or similar).
https://git.linaro.org/kernel/linux-linaro-stable.git. How does this map to 'lsk'? It's exactly the same story. 'lsk' is kernelci's internal project name and this somehow is OK while lkft's internal project names are not.
It's not just that leading bit, it's the whole name that's different with what LKFT is doing especially the attempt to put the tree, branch and userspace into the same unbroken string.
internal project name will stay the same. What is reported in the email subject might be different. This isn't ideal, but gives hopefully some improvement.
milosz
kernel-build-reports@lists.linaro.org
-
Fathi Boudra -
Greg KH -
Linaro QA -
Mark Brown -
Milosz Wasilewski -
Tom Gall