Having maintained a distribution agnostic reference kernel (Yocto), an operating
system vendor kernel (Wind River) and finally a semi-conductor kernel (Xilinx),
there are a lot of obvious workflows and tools that are used to deliver kernels
and support them after release.
The less than obvious workflows (and tools) are often related to distro kernel
tree maintenance and balancing the needs of short term fixes (often security
related), with a model that allows long term support, all in trees that may be
carrying specific features or board support that are destined for upstream
eventually. Many methods to juggle these demands are ad-hoc or specific to the
If a tree is not (somewhat) history clean, and patch history is not tracked
over time, moving to a new kernel version, understanding why a change was made
or debugging a problem are made much harder.
All the competing demands are coupled with the need to have development supported
with the goal of getting changes into the mainline kernel. Understanding the
technical solutions (tools), workflows (tools + social) and how to support the
community at large to reduce everyone's workload is often given limited time.
Stepping back and looking at the different solutions that maintainers are using
may highlight common patterns and opportunities to collaborate/standardize on
various techniques. Less-than-ideal solutions are also valuable as lessons
learned and are worth sharing.
|I agree to abide by the anti-harassment policy||Yes|