Hi,

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.


Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...

On 2016-09-22 11:42, Agustin Benito Bethencourt wrote:

Hi,

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.

Ack.

+++ 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.

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.

Regards,
Jan

--
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Hi,

(2016/09/22 18:42), Agustin Benito Bethencourt wrote:

Hi,

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.

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 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.

To 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.

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group