[cip-dev] Maintenance policies and early considerations II

[cip-dev] Maintenance policies and early considerations II

[Agustin Benito Bethencourt]

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 at codethink.co.uk

[cip-dev] Maintenance policies and early considerations II

[Jan Kiszka]

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

[cip-dev] Maintenance policies and early considerations II

[Hidehiro Kawai]

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