From: "Kevin Hilman" <khilman@baylibre.com>
To: kernelci@groups.io, dan.rue@linaro.org, kernelci@groups.io
Subject: Re: Weekly Meeting 2019-01-14 #minutes
Date: Mon, 14 Jan 2019 13:56:29 -0800 [thread overview]
Message-ID: <7hfttukinm.fsf@baylibre.com> (raw)
In-Reply-To: <20190114155044.g2xy3a5e42ynivj7@xps.therub.org>
"Dan Rue" <dan.rue@linaro.org> writes:
> - Attendees: Charles Oliveira, Daniel Díaz, Guenter Roeck, Guillaume
> Tucker, Dan Rue, Mark Brown, Matt Hart
>
> - [matt]
> - Scrap HTML emails everywhere?
> - Ask HTML receivers
> - In kernel defconfig build lists
> - Kernel tree owner can update the defconfig list without us having
> to roll out updated configs
> - [mark] let’s see what 0day does and others; how do they solve
> this?
> - [drue] perhaps a separate repo that manages configs like this
> out of band from the kernel tree and out of band from kernelci’s
> release cycle. This could also be useful to manage and support
> fragments.
> - [gtucker] what’s the actual usecase of wanting to filter
> defconfigs?
> - [matt] speed
> - [mark] well kernelci’s point is coverage. If you just want one
> built, you don’t need kernelci.
> - [matt] we’ll wait until the yaml work is completed by gtucker
> before making any changes here
> - Very useful for testing
> - [gtucker] Other way to do this is in build-configs.yaml with all
> the other build configuration settings (see initial work in
> kernelci-core-staging PR #75)
We need flexibility in which defconfigs are built per tree, but also per
arch and probably per toolchain, so having this in a simple file in tree
is not sufficient.
IMO, the build-configs.yaml stuff that Guillaume is working on is the
way to go forward.
> - [gtucker]
> - Test regressions merged on staging, testing last changes to the test
> reports
> - Adding fix for MIPS (remove hacks and use gcc-7)
Thanks!
> - V4l2 & dynamic metadata: adding a template parameter to the
> test-configs.yaml test plans settings to specify the video driver to
> use in the test (discovering the driver name at runtime isn’t
> practical with current LAVA)
>
> - [drue]
> - Next steps on ‘[Help] How to use kernelci to establish a local CI
> lab?’?
> - [chaws] I mentioned this repo:
> https://github.com/kernelci/kernelci-core, but still unsure what
> the next step is
> - Li’s asking for support using kernelci-docker locally, not adding
> a lab to kernelci. There are a lot of versions of this repo in the
> wild, so it’s not clear who should help him. Matt can show him how
> he does it.
I'm not sure about a lot of versions, but we (BayLibre) are working
primarily on this one, which is also deployed for AGL:
https://github.com/lucj/kernelci-docker
Kevin
next prev parent reply other threads:[~2019-01-14 21:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 15:50 Weekly Meeting 2019-01-14 #minutes Dan Rue
2019-01-14 21:56 ` Kevin Hilman [this message]
2019-01-14 22:01 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7hfttukinm.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=dan.rue@linaro.org \
--cc=kernelci@groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox