Maintenance policies and early considerations II
Agustin Benito Bethencourt <agustin.benito@...>
a second consideration discussed during the meeting. Feel free to provide your opinions or considerations about them.
++ How should the kernel be released?
+++ Binaries or sources
While commercial distributions like RHEL/SLE include a small number of supported kernel configurations in binary form, the CIP kernel should be primarily released as source, with the configuration controlled by its users.
+++ Kernel features
The project needs to decide which architectures, drivers and other kernel features are to be supported by the core team and its releases. This could be documented purely as human-readable text or in a machine-readable form so that the kernel build process can warn when building an unsupported configuration. It may also be sensible to specify the supported toolchain versions.
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
On 2016-09-22 11:42, Agustin Benito Bethencourt wrote:
Not sure how to read these threads as I didn't manage to follow their
evolution: This aspect of support constraints is still in scope? I think
it will be important in order to keep backporting and testing efforts
realistic. The enterprise distros are doing the same.
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
(2016/09/22 18:42), Agustin Benito Bethencourt wrote:
Hi,Basically, releasing the kernel as source is sufficient. But if we
release it as binary only for the specific reference board, users may be happy.
+++ Kernel featuresTo reduce the maintenance effort, we should limit drivers and features
to be supported (`support' in this context means tracking security/critical
bug fixes, backporting requested patches, and so on).
One idea is to express the supported features in the form of kernel
config. It is machine-readable, and it's not so difficult to covert
it to human-readable. But I'm not sure if it actually work well because
there are non-configurable features.
Hitachi, Ltd. Research & Development Group