Branch for kernelci

Branch for kernelci

[Todd Kjos]

Please add testing for Will Deacon's ARM64 staging tree to kernelci:

[web] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-kernelci
[git] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

It would make sense to have dashboard available as "arm64" or some
other unique tree name (eg "https://kernelci.org/job/arm64").

The owners of this tree are the ARM64 maintainers: will@kernel.org and
catalin.marinas@arm.com (CC'd)

-Todd

Re: Branch for kernelci

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Tue, Oct 15, 2019 at 01:52:36PM -0700, Todd Kjos via Groups.Io wrote:
> Please add testing for Will Deacon's ARM64 staging tree to kernelci:

> [web] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-kernelci
> [git] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

> It would make sense to have dashboard available as "arm64" or some
> other unique tree name (eg "https://kernelci.org/job/arm64").

> The owners of this tree are the ARM64 maintainers: will@kernel.org and
> catalin.marinas@arm.com (CC'd)

Are you sure they are interested in this?  When asked previously they
indicated that they didn't see any extra value in covering their tree
specifically separately to -next.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Branch for kernelci

[Catalin Marinas]

On Wed, Oct 16, 2019 at 10:56:36AM +0100, Mark Brown wrote:
> On Tue, Oct 15, 2019 at 01:52:36PM -0700, Todd Kjos via Groups.Io wrote:
> > Please add testing for Will Deacon's ARM64 staging tree to kernelci:
> 
> > [web] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-kernelci
> > [git] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> 
> > It would make sense to have dashboard available as "arm64" or some
> > other unique tree name (eg "https://kernelci.org/job/arm64").
> 
> > The owners of this tree are the ARM64 maintainers: will@kernel.org and
> > catalin.marinas@arm.com (CC'd)
> 
> Are you sure they are interested in this?  When asked previously they
> indicated that they didn't see any extra value in covering their tree
> specifically separately to -next.

Will can comment on the reasoning but I guess it came as a request from
him since he also created the arm64/for-kernelci branch. This might as
well be the same as for-next/core but tested in isolation rather than
with the whole linux-next tree.

-- 
Catalin

Re: Branch for kernelci

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On Wed, Oct 16, 2019 at 01:38:34PM +0100, Catalin Marinas wrote:
> On Wed, Oct 16, 2019 at 10:56:36AM +0100, Mark Brown wrote:

> > Are you sure they are interested in this?  When asked previously they
> > indicated that they didn't see any extra value in covering their tree
> > specifically separately to -next.

> Will can comment on the reasoning but I guess it came as a request from
> him since he also created the arm64/for-kernelci branch. This might as
> well be the same as for-next/core but tested in isolation rather than
> with the whole linux-next tree.

Yeah, that was what you'd both rejected doing before which was why I was
surprised (plus the fact that this was coming via Todd rather than one
of you).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Branch for kernelci

[Will Deacon]

On Wed, Oct 16, 2019 at 01:54:16PM +0100, Mark Brown wrote:
> On Wed, Oct 16, 2019 at 01:38:34PM +0100, Catalin Marinas wrote:
> > On Wed, Oct 16, 2019 at 10:56:36AM +0100, Mark Brown wrote:
> 
> > > Are you sure they are interested in this?  When asked previously they
> > > indicated that they didn't see any extra value in covering their tree
> > > specifically separately to -next.
> 
> > Will can comment on the reasoning but I guess it came as a request from
> > him since he also created the arm64/for-kernelci branch. This might as
> > well be the same as for-next/core but tested in isolation rather than
> > with the whole linux-next tree.
> 
> Yeah, that was what you'd both rejected doing before which was why I was
> surprised (plus the fact that this was coming via Todd rather than one
> of you).

I asked Todd about this yesterday because we're dealing with an ABI
regression in 5.4 which wasn't picked up until -rc3, so figured that this
was probably worth doing after all. Perhaps it wouldn't have helped for this
specific case, but it turns out that one person's LTP isn't quite the same
as another person's LTP!

So yes, I'm interested in having our for-kernelci branch picked up despite
not seeing the benefit in the past.

Thanks,

Will

Re: Branch for kernelci

[Veronika Kabatova]

----- Original Message -----
> From: "Will Deacon" <will@kernel.org>
> To: "Mark Brown" <broonie@kernel.org>
> Cc: "Catalin Marinas" <catalin.marinas@arm.com>, kernelci@groups.io, tkjos@google.com
> Sent: Wednesday, October 16, 2019 6:46:22 PM
> Subject: Re: Branch for kernelci
> 
> On Wed, Oct 16, 2019 at 01:54:16PM +0100, Mark Brown wrote:
> > On Wed, Oct 16, 2019 at 01:38:34PM +0100, Catalin Marinas wrote:
> > > On Wed, Oct 16, 2019 at 10:56:36AM +0100, Mark Brown wrote:
> > 
> > > > Are you sure they are interested in this?  When asked previously they
> > > > indicated that they didn't see any extra value in covering their tree
> > > > specifically separately to -next.
> > 
> > > Will can comment on the reasoning but I guess it came as a request from
> > > him since he also created the arm64/for-kernelci branch. This might as
> > > well be the same as for-next/core but tested in isolation rather than
> > > with the whole linux-next tree.
> > 
> > Yeah, that was what you'd both rejected doing before which was why I was
> > surprised (plus the fact that this was coming via Todd rather than one
> > of you).
> 
> I asked Todd about this yesterday because we're dealing with an ABI
> regression in 5.4 which wasn't picked up until -rc3, so figured that this
> was probably worth doing after all. Perhaps it wouldn't have helped for this
> specific case, but it turns out that one person's LTP isn't quite the same
> as another person's LTP!
> 

Hi,

if you're mentioning the regression from this thread [0] you'd need to have
the tree added to CKI, not KernelCI. Not sure if we're ready to handle
mainline/next speed of development yet but we can discuss the specifics and
decide based on that. The issue/PR with details be submitted here [1].


We only enabled Sasha's stable-next branch two weeks ago and openposix tests
last week so we're definitely happy they are catching issues right away!

We are actively collaborating with KernelCI but right now the testing
systems, machine pools and testsuites are pretty much independent.

> So yes, I'm interested in having our for-kernelci branch picked up despite
> not seeing the benefit in the past.
> 

Glad to see the interest for CI!

Let me know if you have any questions,
Veronika


[0] https://lists.linaro.org/pipermail/linux-stable-mirror/2019-October/137969.html
[1] https://gitlab.com/cki-project/pipeline-data

> Thanks,
> 
> Will
> 
> 
> 
> 

Re: Branch for kernelci

[Will Deacon]

On Wed, Oct 16, 2019 at 01:28:44PM -0400, Veronika Kabatova wrote:
> ----- Original Message -----
> > From: "Will Deacon" <will@kernel.org>
> > To: "Mark Brown" <broonie@kernel.org>
> > Cc: "Catalin Marinas" <catalin.marinas@arm.com>, kernelci@groups.io, tkjos@google.com
> > Sent: Wednesday, October 16, 2019 6:46:22 PM
> > Subject: Re: Branch for kernelci
> > 
> > On Wed, Oct 16, 2019 at 01:54:16PM +0100, Mark Brown wrote:
> > > On Wed, Oct 16, 2019 at 01:38:34PM +0100, Catalin Marinas wrote:
> > > > On Wed, Oct 16, 2019 at 10:56:36AM +0100, Mark Brown wrote:
> > > 
> > > > > Are you sure they are interested in this?  When asked previously they
> > > > > indicated that they didn't see any extra value in covering their tree
> > > > > specifically separately to -next.
> > > 
> > > > Will can comment on the reasoning but I guess it came as a request from
> > > > him since he also created the arm64/for-kernelci branch. This might as
> > > > well be the same as for-next/core but tested in isolation rather than
> > > > with the whole linux-next tree.
> > > 
> > > Yeah, that was what you'd both rejected doing before which was why I was
> > > surprised (plus the fact that this was coming via Todd rather than one
> > > of you).
> > 
> > I asked Todd about this yesterday because we're dealing with an ABI
> > regression in 5.4 which wasn't picked up until -rc3, so figured that this
> > was probably worth doing after all. Perhaps it wouldn't have helped for this
> > specific case, but it turns out that one person's LTP isn't quite the same
> > as another person's LTP!
> > 
> 
> if you're mentioning the regression from this thread [0] you'd need to have
> the tree added to CKI, not KernelCI. Not sure if we're ready to handle
> mainline/next speed of development yet but we can discuss the specifics and
> decide based on that. The issue/PR with details be submitted here [1].

Hopefully the two aren't mutually exclusive, so if you're able to add the
branch to CKI as well then that would be great.

Will

Re: Branch for kernelci

[Veronika Kabatova]

----- Original Message -----
> From: "Will Deacon" <will@kernel.org>
> To: "Veronika Kabatova" <vkabatov@redhat.com>
> Cc: kernelci@groups.io, "Mark Brown" <broonie@kernel.org>, "Catalin Marinas" <catalin.marinas@arm.com>,
> tkjos@google.com
> Sent: Thursday, October 17, 2019 1:50:55 AM
> Subject: Re: Branch for kernelci
> 
> On Wed, Oct 16, 2019 at 01:28:44PM -0400, Veronika Kabatova wrote:
> > ----- Original Message -----
> > > From: "Will Deacon" <will@kernel.org>
> > > To: "Mark Brown" <broonie@kernel.org>
> > > Cc: "Catalin Marinas" <catalin.marinas@arm.com>, kernelci@groups.io,
> > > tkjos@google.com
> > > Sent: Wednesday, October 16, 2019 6:46:22 PM
> > > Subject: Re: Branch for kernelci
> > > 
> > > On Wed, Oct 16, 2019 at 01:54:16PM +0100, Mark Brown wrote:
> > > > On Wed, Oct 16, 2019 at 01:38:34PM +0100, Catalin Marinas wrote:
> > > > > On Wed, Oct 16, 2019 at 10:56:36AM +0100, Mark Brown wrote:
> > > > 
> > > > > > Are you sure they are interested in this?  When asked previously
> > > > > > they
> > > > > > indicated that they didn't see any extra value in covering their
> > > > > > tree
> > > > > > specifically separately to -next.
> > > > 
> > > > > Will can comment on the reasoning but I guess it came as a request
> > > > > from
> > > > > him since he also created the arm64/for-kernelci branch. This might
> > > > > as
> > > > > well be the same as for-next/core but tested in isolation rather than
> > > > > with the whole linux-next tree.
> > > > 
> > > > Yeah, that was what you'd both rejected doing before which was why I
> > > > was
> > > > surprised (plus the fact that this was coming via Todd rather than one
> > > > of you).
> > > 
> > > I asked Todd about this yesterday because we're dealing with an ABI
> > > regression in 5.4 which wasn't picked up until -rc3, so figured that this
> > > was probably worth doing after all. Perhaps it wouldn't have helped for
> > > this
> > > specific case, but it turns out that one person's LTP isn't quite the
> > > same
> > > as another person's LTP!
> > > 
> > 
> > if you're mentioning the regression from this thread [0] you'd need to have
> > the tree added to CKI, not KernelCI. Not sure if we're ready to handle
> > mainline/next speed of development yet but we can discuss the specifics and
> > decide based on that. The issue/PR with details be submitted here [1].
> 
> Hopefully the two aren't mutually exclusive, so if you're able to add the
> branch to CKI as well then that would be great.
> 

Of course not. Is testing on aarch64 sufficient or do you need other
architectures too?

I submitted [0] the initial config, please check if the repo and email
information are correct or if we should add e.g. ARM list (didn't see
it in the initial email but checking just in case).


[0] https://gitlab.com/cki-project/pipeline-data/merge_requests/19/diffs


Veronika

> Will
> 
> 
> 
> 

Re: Branch for kernelci

[Will Deacon]

Hi Veronika,

On Thu, Oct 17, 2019 at 07:31:14AM -0400, Veronika Kabatova wrote:
> > On Wed, Oct 16, 2019 at 01:28:44PM -0400, Veronika Kabatova wrote:
> > > > I asked Todd about this yesterday because we're dealing with an ABI
> > > > regression in 5.4 which wasn't picked up until -rc3, so figured that this
> > > > was probably worth doing after all. Perhaps it wouldn't have helped for
> > > > this
> > > > specific case, but it turns out that one person's LTP isn't quite the
> > > > same
> > > > as another person's LTP!
> > > > 
> > > 
> > > if you're mentioning the regression from this thread [0] you'd need to have
> > > the tree added to CKI, not KernelCI. Not sure if we're ready to handle
> > > mainline/next speed of development yet but we can discuss the specifics and
> > > decide based on that. The issue/PR with details be submitted here [1].
> > 
> > Hopefully the two aren't mutually exclusive, so if you're able to add the
> > branch to CKI as well then that would be great.
> > 
> 
> Of course not. Is testing on aarch64 sufficient or do you need other
> architectures too?

Oh, good question! I suppose the two targets we care about the most are
arm64 kernel with both arm64 and arm32 userspace.

> I submitted [0] the initial config, please check if the repo and email
> information are correct or if we should add e.g. ARM list (didn't see
> it in the initial email but checking just in case).

Brilliant, thanks very much. I hadn't considered adding the list, but I
guess it doesn't hurt so please feel free to add
linux-arm-kernel@lists.infradead.org as well.

Curious: why 'olddefconfig' instead of 'defconfig'? Are there some options
required by CKI that aren't present in defconfig?

Will

Re: Branch for kernelci

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

On Thu, Oct 17, 2019 at 05:02:43PM +0100, Will Deacon wrote:

> Curious: why 'olddefconfig' instead of 'defconfig'? Are there some options
> required by CKI that aren't present in defconfig?

In general anything that's doing runtime tests will need some extra
config options to get the functionality they're trying to test enabled,
for example for kselftests there's fragments in tree as
tools/testing/selftests/*/config (a lot though not all of those tend to
end up in defconfigs but other testsuites end up adding more).  This was
why Anders was looking at making allmodconfig bootable, it'd reduce the
need for this.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Branch for kernelci

[Veronika Kabatova]

----- Original Message -----
> From: "Will Deacon" <will@kernel.org>
> To: "Veronika Kabatova" <vkabatov@redhat.com>
> Cc: kernelci@groups.io, "Mark Brown" <broonie@kernel.org>, "Catalin Marinas" <catalin.marinas@arm.com>,
> tkjos@google.com
> Sent: Thursday, October 17, 2019 6:02:43 PM
> Subject: Re: Branch for kernelci
> 
> Hi Veronika,
> 
> On Thu, Oct 17, 2019 at 07:31:14AM -0400, Veronika Kabatova wrote:
> > > On Wed, Oct 16, 2019 at 01:28:44PM -0400, Veronika Kabatova wrote:
> > > > > I asked Todd about this yesterday because we're dealing with an ABI
> > > > > regression in 5.4 which wasn't picked up until -rc3, so figured that
> > > > > this
> > > > > was probably worth doing after all. Perhaps it wouldn't have helped
> > > > > for
> > > > > this
> > > > > specific case, but it turns out that one person's LTP isn't quite the
> > > > > same
> > > > > as another person's LTP!
> > > > > 
> > > > 
> > > > if you're mentioning the regression from this thread [0] you'd need to
> > > > have
> > > > the tree added to CKI, not KernelCI. Not sure if we're ready to handle
> > > > mainline/next speed of development yet but we can discuss the specifics
> > > > and
> > > > decide based on that. The issue/PR with details be submitted here [1].
> > > 
> > > Hopefully the two aren't mutually exclusive, so if you're able to add the
> > > branch to CKI as well then that would be great.
> > > 
> > 
> > Of course not. Is testing on aarch64 sufficient or do you need other
> > architectures too?
> 
> Oh, good question! I suppose the two targets we care about the most are
> arm64 kernel with both arm64 and arm32 userspace.
> 

I think we only have arm64. Thanks for answer, I'll adjust the tree
config to only use aarch64 for now.

> > I submitted [0] the initial config, please check if the repo and email
> > information are correct or if we should add e.g. ARM list (didn't see
> > it in the initial email but checking just in case).
> 
> Brilliant, thanks very much. I hadn't considered adding the list, but I
> guess it doesn't hurt so please feel free to add
> linux-arm-kernel@lists.infradead.org as well.
> 

Will add!

> Curious: why 'olddefconfig' instead of 'defconfig'? Are there some options
> required by CKI that aren't present in defconfig?
> 

We're using Fedora config files with this option. I honestly don't know if
there are any tests depending on it, but we are trying to build kernels
close to the Fedora ones.


I'll get all the CKI configs in place and the first test run should start
soon after they are merged.


Veronika

> Will
> 

Re: Branch for kernelci

[Guillaume Tucker]

[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]

On Wed, Oct 16, 2019 at 5:55 PM Will Deacon <will@kernel.org> wrote:

> On Wed, Oct 16, 2019 at 01:54:16PM +0100, Mark Brown wrote:
> > On Wed, Oct 16, 2019 at 01:38:34PM +0100, Catalin Marinas wrote:
> > > On Wed, Oct 16, 2019 at 10:56:36AM +0100, Mark Brown wrote:
> >
> > > > Are you sure they are interested in this?  When asked previously they
> > > > indicated that they didn't see any extra value in covering their tree
> > > > specifically separately to -next.
> >
> > > Will can comment on the reasoning but I guess it came as a request from
> > > him since he also created the arm64/for-kernelci branch. This might as
> > > well be the same as for-next/core but tested in isolation rather than
> > > with the whole linux-next tree.
> >
> > Yeah, that was what you'd both rejected doing before which was why I was
> > surprised (plus the fact that this was coming via Todd rather than one
> > of you).
>
> I asked Todd about this yesterday because we're dealing with an ABI
> regression in 5.4 which wasn't picked up until -rc3, so figured that this
> was probably worth doing after all. Perhaps it wouldn't have helped for
> this
> specific case, but it turns out that one person's LTP isn't quite the same
> as another person's LTP!
>
> So yes, I'm interested in having our for-kernelci branch picked up despite
> not seeing the benefit in the past.
>

Sure, sorry for the delay in getting this sorted out.  There are
a few pieces of information needed in order to add a branch to
kernelci.org, and to avoid repeating the same questions every
time I've now made a Github issue template just for that:

  https://github.com/kernelci/kernelci-core/issues/new/choose

Would you be so kind as to filing one of those?  You'll be the
first one actually using this template so I hope it'll be
self-explanatory but please let us know if you have any questions
or comments.

Thanks,
Guillaume


> 
>
>

[-- Attachment #2: Type: text/html, Size: 2755 bytes --]

Re: Branch for kernelci

[Will Deacon]

Hi Guillaume,

Thanks for the reply.

On Tue, Oct 22, 2019 at 08:53:03PM +0100, Guillaume Tucker wrote:
>    On Wed, Oct 16, 2019 at 5:55 PM Will Deacon <[1]will@kernel.org> wrote:
>      So yes, I'm interested in having our for-kernelci branch picked up
>      despite
>      not seeing the benefit in the past.
> 
>    Sure, sorry for the delay in getting this sorted out.  There are
>    a few pieces of information needed in order to add a branch to
>    [2]kernelci.org, and to avoid repeating the same questions every
>    time I've now made a Github issue template just for that:
> 
>      [3]https://github.com/kernelci/kernelci-core/issues/new/choose
> 
>    Would you be so kind as to filing one of those?  You'll be the
>    first one actually using this template so I hope it'll be
>    self-explanatory but please let us know if you have any questions
>    or comments.

Hmm, so I don't actually have a github account anymore and it feels a bit
OTT to create one just to fill in a form... Is the form accessible some
other way?

Will

Re: Branch for kernelci

[Guillaume Tucker]

[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]

On Wed, Oct 23, 2019 at 5:42 PM Will Deacon <will@kernel.org> wrote:

> Hi Guillaume,
>
> Thanks for the reply.
>
> On Tue, Oct 22, 2019 at 08:53:03PM +0100, Guillaume Tucker wrote:
> >    On Wed, Oct 16, 2019 at 5:55 PM Will Deacon <[1]will@kernel.org>
> wrote:
> >      So yes, I'm interested in having our for-kernelci branch picked up
> >      despite
> >      not seeing the benefit in the past.
> >
> >    Sure, sorry for the delay in getting this sorted out.  There are
> >    a few pieces of information needed in order to add a branch to
> >    [2]kernelci.org, and to avoid repeating the same questions every
> >    time I've now made a Github issue template just for that:
> >
> >      [3]https://github.com/kernelci/kernelci-core/issues/new/choose
> >
> >    Would you be so kind as to filing one of those?  You'll be the
> >    first one actually using this template so I hope it'll be
> >    self-explanatory but please let us know if you have any questions
> >    or comments.
>
> Hmm, so I don't actually have a github account anymore and it feels a bit
> OTT to create one just to fill in a form... Is the form accessible some
> other way?


 Alright then, I'll ask you a couple of things here instead:

How much build coverage do you need for your branch?  Is it just
for arm64, or do you need other architectures to be built as
well?  Do you need only the main defconfig or do you want all the
variants such as allmodconfig, defconfig with big-endian...

How often do you expect your branch to be updated?  Every branch
is monitored hourly on kernelci.org, so if it's updated less
often then it's easier to cope with a larger build coverage.

Which recipients should receive the email reports?  The standard
reports are for builds and basic tests (boot and checks for
kernel errors).  I guess that should be Catalin, you and
linux-arm-kernel as for CKI?

Guillaume

[-- Attachment #2: Type: text/html, Size: 2769 bytes --]

Re: Branch for kernelci

[Will Deacon]

Hi Guillaume,

On Wed, Oct 23, 2019 at 07:16:42PM +0100, Guillaume Tucker wrote:
>    On Wed, Oct 23, 2019 at 5:42 PM Will Deacon <[1]will@kernel.org> wrote:
>      On Tue, Oct 22, 2019 at 08:53:03PM +0100, Guillaume Tucker wrote:
>      >      [3][4]https://github.com/kernelci/kernelci-core/issues/new/choose
>      >
>      >    Would you be so kind as to filing one of those?  You'll be the
>      >    first one actually using this template so I hope it'll be
>      >    self-explanatory but please let us know if you have any questions
>      >    or comments.
> 
>      Hmm, so I don't actually have a github account anymore and it feels a
>      bit OTT to create one just to fill in a form... Is the form
>      accessible some other way?
> 
>     Alright then, I'll ask you a couple of things here instead:
>    How much build coverage do you need for your branch?  Is it just
>    for arm64, or do you need other architectures to be built as
>    well?  Do you need only the main defconfig or do you want all the
>    variants such as allmodconfig, defconfig with big-endian...

arm64 only, with build coverage for allnoconfig, defconfig and allmodconfig.
The boot/runtime tests only need to worry about defconfig.

>    How often do you expect your branch to be updated?  Every branch
>    is monitored hourly on [5]kernelci.org, so if it's updated less
>    often then it's easier to cope with a larger build coverage.

Hard to tell, but at most maybe once a day?

>    Which recipients should receive the email reports?  The standard
>    reports are for builds and basic tests (boot and checks for
>    kernel errors).  I guess that should be Catalin, you and
>    linux-arm-kernel as for CKI?

Yes, please.

Thanks,

Will

Re: Branch for kernelci

[Guillaume Tucker]

[-- Attachment #1: Type: text/plain, Size: 2587 bytes --]

Hi Will,

On Fri, Oct 25, 2019 at 5:01 PM Will Deacon <will@kernel.org> wrote:

> Hi Guillaume,
>
> On Wed, Oct 23, 2019 at 07:16:42PM +0100, Guillaume Tucker wrote:
> >    On Wed, Oct 23, 2019 at 5:42 PM Will Deacon <[1]will@kernel.org>
> wrote:
> >      On Tue, Oct 22, 2019 at 08:53:03PM +0100, Guillaume Tucker wrote:
> >      >      [3][4]
> https://github.com/kernelci/kernelci-core/issues/new/choose
> >      >
> >      >    Would you be so kind as to filing one of those?  You'll be the
> >      >    first one actually using this template so I hope it'll be
> >      >    self-explanatory but please let us know if you have any
> questions
> >      >    or comments.
> >
> >      Hmm, so I don't actually have a github account anymore and it feels
> a
> >      bit OTT to create one just to fill in a form... Is the form
> >      accessible some other way?
> >
> >     Alright then, I'll ask you a couple of things here instead:
> >    How much build coverage do you need for your branch?  Is it just
> >    for arm64, or do you need other architectures to be built as
> >    well?  Do you need only the main defconfig or do you want all the
> >    variants such as allmodconfig, defconfig with big-endian...
>
> arm64 only, with build coverage for allnoconfig, defconfig and
> allmodconfig.
> The boot/runtime tests only need to worry about defconfig.
>

Sure.

Meanwhile, we should hopefully soon have a bootable allmodconfig
on arm64 using KBUILD_ALLCONFIG to pick default choices from the
regular defconfig.  You might be interested in that when it
happens, the KernelCI parts are all in place and Anders is now on
the case to make it actually work with tweaks in the defconfig.


> >    How often do you expect your branch to be updated?  Every branch
> >    is monitored hourly on [5]kernelci.org, so if it's updated less
> >    often then it's easier to cope with a larger build coverage.
>
> Hard to tell, but at most maybe once a day?
>

That's fine, it's mostly an issue for branches that get built
with the full range of combinations and new each revision
produces over 200 kernels binaries...


> >    Which recipients should receive the email reports?  The standard
> >    reports are for builds and basic tests (boot and checks for
> >    kernel errors).  I guess that should be Catalin, you and
> >    linux-arm-kernel as for CKI?
>
> Yes, please.
>

OK here's the pull request for the record:

    https://github.com/kernelci/kernelci-core/pull/224

If all goes well this should be enabled later this week during
the next kernelci.org update.

Thanks,
Guillaume

[-- Attachment #2: Type: text/html, Size: 3945 bytes --]