On 2020-09-17 10:43, Paul Barker wrote:
Hi folks,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.And spreading the workload of course!