On 17/09/2020 10:40, Bas Mevissen wrote:
On 2020-09-17 10:43, Paul Barker wrote:
Hi folks,I would suggest calling it something like meta-kernel.org then. Naming
After a bit of a break I'm looking again at the meta-kernel layer and
I've got some changes planned. I'd like to get some feedback on these
from anyone who has looked at or used the meta-kernel layer.
1) Change the name to meta-vanilla-kernel. This reflects the focus on
providing a fast moving layer for vanilla kernel recipes, covering
only what is available on kernel.org. Other common kernel recipes
(e.g. Linaro or Android common kernels) will no longer be considered
for acceptance into this layer. This clear focus should hopefully
reduce some of the confusion about the goals of this layer.
something "vanilla" might cause confusion as well.
I wasn't going to be blamed for the bike shedding of this but as we've
gotten started I'll stick my oar in. My suggestion would be
meta-mainline-kernel, meta-linux-kernel or potentially
meta-upstream-kernel but I'm not so keen on that. Vanilla is a confusing
term for people not in the game and you know at some point there will be
a "vanilla-pi" or "vanilla" board where you're going to hit confusion.
As an aside I saw no issues with meta-kernel as it's _the_ Linux kernel
from _the_ Linux kernel git repositories. Confusion due to doublespeak
from downstream kernel vendors should be corrected and not adhered to.
2) The dunfell branch will no longer get new non-LTS kernel recipes.
Providing non-LTS recipes on a stable branch has led to people
depending on kernels which are now out of their support period - I'd
like to drop the recipes for the 5.3.y and 5.6.y kernels but users are
depending on them so I'll have to keep them. To avoid this
proliferating, only LTS kernels and the bleeding edge mainline recipe
will be updated on the stable branch from now >>
3) Aggressively drop end-of-life kernels on the master branch.
4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is
I think these are fair, I can't speak for how other people are using the
layer but I would imagine as with most embedded boards, they're using
the tooling rather than the plain upstream recipes and the real value is
in catching problems with -next kernel compilation early and the
fixes/features pushed back to kernel.bbclass.
5) Document the test coverage for meta-kernel. We don't test perf,
lttng or any out-of-tree modules. This layer isn't meant to replace
the linux-yocto recipes, the goals are different. If you're releasing
products based on meta-kernel you obviously need to do your own
testing on the components you're actually using.
I wouldn't be expecting anything more than basic build and boot on qemu
to be fair. Again, IMO the value of this is in the toolchain test and
6) Document the policy for kernel patches. Patches for the kernel will
only be carried in this layer as a last resort. Kernel patches should
be submitted upstream and go through the usual process for inclusion
in the stable kernel releases.
Compilation patches only I would say.
7) Disable GitLab CI for this layer. It's costing me about £70 per
month to run CI for this layer and I need to eliminate that expense.
If anyone can sponsor this or host the CI service that would be welcome.
8) Add Jon Mason and Ross Burton (both at ARM) as backup maintainers
to reduce the bus factor for the layer. I'll continue to be the
primary maintainer for this layer but this will give some coverage if
I'm unable to continue working on it.