On 2020-09-17 10:43, Paul Barker wrote:
Hi folks,
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.
I would suggest calling it something like meta-kernel.org then. Naming
something "vanilla" might cause confusion as well.
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 on.
I would recommend maintaining a "kernel-stable" moving target recipe
that tracks the latest stable version of kernel.org. This is of use for
people needing a very recent kernel, while needing a stable environment
for the rest of the system (so where master is no option).
3) Aggressively drop end-of-life kernels on the master branch.
Always good to keep the amount of kernels at an absolut minimum to limit
the amount of testing and maintenance.
4) Drop all non-LTS kernel recipes in the gatesgarth branch when it is
created.
See 2); additionally the next-to-be-lts might be considered
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.
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.
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.
And spreading the workload of course!
Thanks,
--
Paul Barker
Konsulko Group
Regards,
Bas.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50706): https://lists.yoctoproject.org/g/yocto/message/50706
Mute This Topic: https://lists.yoctoproject.org/mt/76905426/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
