Date   

Re: Introduction

Urs Gleim
 

Hi,

my name is Urs Gleim. I am with Siemens Corporate Technology. I have a history in embedded systems development with all the big proprietary embedded operating systems out there. I worked in projects in the domains automotive (mainly infotainment), industry automation, healthcare and others. Today I am more in the managing role pushing the shift to open source software and (embedded) Linux in particular in the company (lessons learnt from the work with other OS's :-) We run the internal "Corporate Competence Center Embedded Linux" and support businesses units migrating to and maintaining Linux for their products.

The experiences of the last years showed that the way each and every company is building their own customized Linux versions, tool chains, and test infrastructure could be done much more efficiently and more sustainable. Even inside each company there are several solutions for different products.

We have different product cycles and requirements compared to consumer products, data centers, for example. So what every company in the area of systems used in rail, traffic control, healthcare, power generation/transmission, etc. does is: i. adapting Linux for their needs (in terms of build environment, test, features, ...), ii. maintaining these solutions for years.

Furthermore, having standard configurations would lead to a common platform as a basis for others building upon those platform (libraries, network protocols, tools). At the end this is an ecosystem involving and bringing together different communities/projects, suppliers, and the companies creating products. In other domains there are efforts going in the same direction (e.g., AGL, Genivi). So we believe we can do much more by joining forces in the operating system area and Linux will be established even more in the industrial world. One of the strongest pain points today is the effort we spend for (super) long-term maintenance, for each product, in each company. So we start addressing this by creating a  harmonized build and test infrastructure and agreeing on common super long-term maintained kernel versions and patch cycles.

I am looking forward working with you.

Best regards,
Urs


On 16.09.2016 09:53, KOBAYASHI Yoshitake wrote:
Hi all,

My name is Yoshitake Kobayashi. I am working for Toshiba.
I've been working on operating system related topics for more than 20 years.
Currently, I've been leading an embedded Linux team in Toshiba to provide Linux
environments for our embedded products.
For open source related projects, I represent Toshiba for three projects which
include CIP, Debian-LTS [1] and Linux Foundation CE Linux project [2].
I've also made several presentations at Embedded Linux Conferences [3].
In retrospect, the most of my presentations relate to start CIP.

For CIP, I am one of the founding member. So, CIP is really exciting and
challenging project for us. I am looking forward to working with you.

----------------------------------------------------------------
[1] https://www.freexian.com/en/services/debian-lts.html
[2] https://www.linuxfoundation.org/projects/core-embedded-linux
[3] http://www.embeddedlinuxconference.com/
----------------------------------------------------------------

Best regards,
Yoshi

On 2016/09/15 17:30, Agustin Benito Bethencourt wrote:
Hi,

On 15/09/16 08:50, Daniel Sangorrin wrote:
Hi Ben,

I've been asked to introduce myself to the list, before getting into
discussions.  So here's a very brief summary.

I've been working on the Linux kernel for about 10 years, including
co-maintenance of Debian's kernel package for most of that time.  Debian
provides security support for each stable release for 5 years, and in
support of that I backported many fixes to 2.6.32-longterm and took on
maintenance of the 3.2-longterm and 3.16-longterm branches.

I'm now adding another part-time role as lead kernel maintainer for the
CIP.  I look forward to working with you all to establish a project and
process that can extend the support lifetime even further.

Ben.

Welcome to the CIP project. It's great to have such an experienced maintainer
in the project. Looking forward to working with you too!

Daniel, can you tell us a little about yourself?

My name is Agustín Benito Bethencourt. I represent Codethink at CIP. I've managed teams-programs-projects for some years ago, the last in the open.

I am looking forward to find out how we are going to deal with this outstanding challenge, keeping a Linux system alive and healthy for many years in mission critical environments. I think it is an exciting one.

Best Regards

Agustin


Best regards,
Daniel

--
IoT Technology center
Toshiba Corp. Industrial ICT solutions,
Daniel SANGORRIN



--
Ben Hutchings
Software Developer, Codethink Ltd.


_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev



_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Use cases behind CIP story

Urs Gleim
 

Hi,

On 16.09.2016 12:30, Agustin Benito Bethencourt wrote:
It might be better to provide some typical development and maintenance
schedule/process
to explain why CIP is important for civil infrastructure systems.
Agree.

There is another aspect that many do not consider when approaching the
maintenance problem which is risk.

We are very use to nowadays to evaluate maintenance costs. But
maintenance might involve very high risks in certain environments and
tackle them might require a heavy investment. This might heavily
affect the maintenance policies.
let me try to sketch one example for typical rail automation products:
- development time of a new system: 3-5 years
- customer specific adaptions: 2-4 years
- initial safety certifications / authorization: 1 year
- safety certifications / authorization for follow-up releases: 3-6 months
(depending on amount of changes)
- lifetime today typically 25 years, for some systems up to 50 years

Especially the time (and money) required for the certification for new
releases explains why in general there are no frequent updates.
If new releases are necessary, e.g. because of security reasons the
above mentioned efforts can be drastically reduced by only changing
minor parts (efforts of course vary on type of system and safety level).
Less changes mean less effort. Switching a kernel version is not
considered to be a small change. That's why these products typically
stick to a kernel version for long time which has been tested
extensively in the system environment.

We have similar situations in other domains. Healthcare, for example.
The product lifetimes are shorter, typically 10-15 years. Still there
are certifications (like FDA) which have to be done on system level
which lead to the same problems.

In addition to this there is a general trend that safety critical
functions are more and more implemented in software. This means that the
number of products having those certification need will further increase.

I would also like to state one important point: the super-long-term
maintenance is not a crazy idea by some industry people. It is done
already. Only that it is done behind closed doors by privately
maintained patch-sets. And this is what we would like to change.

best regards,
Urs


Re: cip-dev Digest, Vol 4, Issue 14: IRC not Practical

Don Brown <don.f.brown@...>
 

Hi Everyone,

#Alternatives to a Mailing List

Slack has been taking the business world by storm, however, The free version has some serious limitations on it. So I started looking for Slack alternatives and found the (4) alternatives listed below. For comparison, I captured the features and pricing (if any) 

In my research, I wanted to find solutions that were free and preferably Open Source Software. I wanted to make it easy to use, especially for anyone outside the group. I also wanted to find a solution that would allow sub-groups to be formed. Lastly, the ability to download the software and host the site myself would be a plus, but not a requirement.

##Google Groups

###Features
- All of your discussions in one place
- Express yourself with rich-text editing including images
- People power discussions - Photos, nicknames, and automatic translations for the international community members
- Speed matters - Keyboard shortcuts
Mobile friendly - Access from anywhere using your mobile device.

###Pricing
100% Free

##Fleep

###Features
- Unlimited message history
- Unlimited number of conversations
- Unlimited number of integrations
- Share up to 5GB files per user
- Native Mobile & Desktop apps for 
- Android
- iOS
- Windows
- Mac
- Teams - create and manage unlimited number of Fleep teams

###Pricing
Free, but Limited to 5GB of file storage per use before having to upgrade to Premium - which has 50GB of storage per users

##Ryver

###Features:
- Unlimited users
- Unlimited guests
- Unlimited teams
- Unlimited chats
- Unlimited posts
- Unlimited search
- Unlimited data
- Native Mobile & Desktop apps for
- iOS
- Android
- Mac Desktop
- Windows Desktop

###Pricing
100% Free!


##Rocket.Chat

###Features:
- Can be self-hosted
- Video Conference
- Helpdesk
- File Sharing
- Voice Messages
- Link Preview
- API for GitLab, JIRA, Confluence, etc...
- Extendability
Native Mobile apps for:
- Android
- iOS

###Pricing
100% Free!


##Summary
Overall, my biggest concern was being able to extract all of the information in a group if it became necessary to move it to another platform, like if a company went out of business, changed their terms of service or they abandoned the application. 

Clearly, Google Groups provide the most stability in this regard. Additonally, it integrates to Google Hangouts where team members can video chat, share screens and collaborate on a whiteboard.

As a side note, many comments included a reference to encrypted communications. In a corporation with trade secrets and development of patentable technology, I might agree. However, for an open source platform like CIP, I  believe this is a "nice to have," and not a "need to have."

##References:
Burger, R. (2016). The top 13 Slack alternatives [Blog entry]. Capterra. <http://blog.capterra.com/the-top-13-slack-alternatives/>


---
Right before I posted this, I saw that a Google Group has already been created. I decided to post it anyway so the team members can see the alternative in case we ever need to move.

Thank you Nori & Jeff for creating the Google Group!




Sincerely,

Don Brown. PMP
don.f.brown@...
Mobile: (317) 560-0513
Here's to Life, Linux and the Pursuit of Happiness

On Sat, Sep 24, 2016 at 8:00 AM, <cip-dev-request@...project.org> wrote:
Send cip-dev mailing list submissions to
        cip-dev@...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.cip-project.org/mailman/listinfo/cip-dev
or, via email, send a message with subject or body 'help' to
        cip-dev-request@...ect.org

You can reach the person managing the list at
        cip-dev-owner@...t.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cip-dev digest..."


Today's Topics:

   1. Re: New IRC channel for #cip (Gleim, Urs)


----------------------------------------------------------------------

Message: 1
Date: Sat, 24 Sep 2016 13:52:36 +0200
From: "Gleim, Urs" <urs.gleim@...>
To: cip-dev@...
Subject: Re: [cip-dev] New IRC channel for #cip
Message-ID: <3f48e9be-d159-c3a9-ce76-79fe6e2f17f6@...>
Content-Type: text/plain; charset="windows-1252"

Hi,

just a remark: we have some proxy restrictions in the company which
result in the fact that IRC is not really practically usable. So our
main communication channel would be the mailing list I am afraid.

best regards,
Urs


On 19.09.2016 18:32, Agustin Benito Bethencourt wrote:
> Hi,
>
> CIP has a new IRC channel. #cip in irc.freenode.net. Please check the
> logs at https://irclogs.baserock.org/cip/
>
> I would welcome if you can report that you successfully accessed to it
> through webchat. Some corporations do not provide access to IRC
> through the default ports. Maybe accessing through web would be the
> alternative.
>
> Best regards
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20160924/779ba938/attachment-0001.html>

------------------------------

_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


End of cip-dev Digest, Vol 4, Issue 14
**************************************


Re: New IRC channel for #cip

Paul Sherwood
 

On 2016-09-24 12:52, Gleim, Urs wrote:
just a remark: we have some proxy restrictions in the company which
result in the fact that IRC is not really practically usable. So our
main communication channel would be the mailing list I am afraid.
This is a problem for many companies, actually, but I hope we can still encourage people to participate in IRC, mainly because there are so many established FOSS projects and contributors actively using IRC. It's old-school, but it has been working very well for several decades now. Using the newer services (Slack, Google Groups etc) may seem to achieve similar functionality but they don't achieve the same direct connection to other communities.

Codethink's default recommendation to get IRC in the situation you have at Siemens would be to setup a web-based service. We've had success with Shout [1] and its fork The Lounge [2]. Basically these allow people to participate in IRC directly from a web-browser. Normally people run the server on a tiny/cheap cloud machine, eg AWS. Both relatively easy to setup, either by members directly, or maybe by Linux Foundation?

Alternatively we'd be happy to create accounts on our existing Shout instance [3] if that's of interest.

br
Paul

[1] https://github.com/erming/shout
[2] https://thelounge.github.io
[3] https://chat.codethink.co.uk


Re: Maintenance policies and early considerations IV

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

On 22/09/16 14:59, Agustin Benito Bethencourt wrote:
Hi,

at CIP we need to have a clear view of what "Support" means in the
context of the Super Long Term Support kernel.

++ What kind of support will CIP provide? To whom?

CIP will support its members and their developers, not system
administrators or end users. With the current number of members, there
should not be a need for a 'first line' of support between them and the
CIP core developers, though that may change if membership grows
significantly.

Commercial Linux based distributions like RHEL promise that a subset of
the kernel module API and ABI remains stable within a major release, so
that many out-of-tree modules can be used without needing to update the
module source or binaries along with the kernel. Some IHVs rely on this
to distribute driver modules in binary form.

CIP should avoid making any such promise because:

* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not is difficult and risky - CIP
users set their own kernel configurations, so there will not be a single
kernel ABI for IHVs to target anyway
Correction:

Upstream fixes frequently change the kernel module API and/or ABI and backporting them in a way that is difficult and risky - CIP users set their own kernel configurations, so there will not be a single kernel ABI for IHVs to target anyway


* CIP users are responsible for binary releases of both the kernel and
out-of-tree modules, so can ensure that they are properly synchronised.

* The criteria for backporting bug fixes will presumably be based on
'stable-kernel-rules.txt'. However, In CIP context, it is recommended
to be more precise than that.

Best Regards
Best regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: Maintenance policies and early considerations III

Daniel Sangorrin
 

Hi Agustin,

Sorry for the late reply.

+++ Request to members from maintainer

During the meeting Ben requested CIP members to provide him some
guidelines or policies currently followed to choose security patches.
This information will hopefully provide some light that help maintainers
to define some basic policies for choosing security fixes. This policies
need to be tested over time.

Due to the length of the maintenance period, it is unlikely that the
same person/team maintain the kernel for the entire life cycle so the
main policies at least need to be left written.
I think that one possible guideline for backporting security patches to the CIP kernel
is to look at kernel CVEs [1]. A table (probably only accessible by members)
indicating whether a CIP kernel is vulnerable or not to a CVE would be of great help.

Another source of bug/security fixes will be the PREEMPT RT patch. We will probably
need to check whether bugs found in new versions are properly backported to our
CIP kernels.
# I see that Ben is already doing this! [2]

Finally, we may need to decide how to disclosure bugs that we may find ourselves
while testing the CIP kernels. I guess we will need to make sure that all members are
ready for the disclosure.

Best regards
Daniel

[1] http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
[2] https://lkml.org/lkml/2016/9/29/473


Public wiki

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

CIP ha set up a public wiki. It has very little content at this point and there is no policy yet to add editors. We are sorting things out.

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start

Please take a look and let me know what can we do to improve it. we will include the link in tomorrow's presentation at LinuxCon EU.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: Public wiki

Urs Gleim
 

Just a remark, the presentation is tomorrow, 10/6

--
Urs Gleim | Siemens AG | Corporate Technology

Am 04.10.2016 um 19:50 schrieb Agustin Benito Bethencourt <agustin.benito@codethink.co.uk>:

Hi,

CIP ha set up a public wiki. It has very little content at this point and there is no policy yet to add editors. We are sorting things out.

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start

Please take a look and let me know what can we do to improve it. we will include the link in tomorrow's presentation at LinuxCon EU.

Best Regards

--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Public wiki

Yoshitake Kobayashi
 

Hi Agustin,

Here are some links for CIP presentations. Probably the following information is also a candidate contents for CIP wiki.

* Towards Sustainable Systems with the Civil Infrastructure Platform (LinuxCon NA 2016, August 2016)
URL: http://events.linuxfoundation.org/sites/events/files/slides/CIP-LinuxConNA.pdf

* Introducing the Civil Infrastructure Platform Project (LinuxCon Japan, July 2016)
URL: http://events.linuxfoundation.jp/sites/events/files/slides/Intriducing_the_CIP-LCJ2016.pdf

* Introducing the Civil Infrastructure Platform Project (ELC 2016, April 2016)
Note: This is the first official presentation by the CIP
URL: http://events.linuxfoundation.org/sites/events/files/slides/Introducing%20the%20Civil%20Infrastructure%20Platform.pdf

-----------------
The following presentation was made before the CIP launch, but it might be a good reference to know how and why we start the CIP.

* Applying the Linux to the Civil Infrastrucure (LinuxCon Japan 2015, June 2015)
URL: http://elinux.org/images/7/74/Applying_Linux_to_the_Civil_Infrastructure-LinuxCon_Japan_2015.pdf

* Applying Linux to the Social Infrastructure BoF (ELC 2015, Apr 2015)
URL: http://events.linuxfoundation.org/sites/events/files/slides/ELC_2015_SIP.pdf

* Using Embedded Linux for Infrastructure Systems (ELC Europe, October 2014)
URL: http://events.linuxfoundation.jp/sites/events/files/slides/ELCE2014-Using%20Embedded%20Linux%20for%20Infrastructure%20Systems.pdf
-----------------

Best regards,
Yoshi

On 2016/10/05 2:50, Agustin Benito Bethencourt wrote:
Hi,

CIP ha set up a public wiki. It has very little content at this point and there is no policy yet to add editors. We are sorting things out.

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start

Please take a look and let me know what can we do to improve it. we will include the link in tomorrow's presentation at LinuxCon EU.

Best Regards


Re: Public wiki

Agustín Benito Bethencourt <agustin.benito@...>
 

Hi,

I think it is already there.

On 5 October 2016 20:58:09 CEST, KOBAYASHI Yoshitake <yoshitake.kobayashi@toshiba.co.jp> wrote:
Hi Agustin,

Here are some links for CIP presentations. Probably the following
information is also a candidate contents for CIP wiki.

* Towards Sustainable Systems with the Civil Infrastructure Platform
(LinuxCon NA 2016, August 2016)
URL:
http://events.linuxfoundation.org/sites/events/files/slides/CIP-LinuxConNA.pdf

* Introducing the Civil Infrastructure Platform Project (LinuxCon
Japan, July 2016)
URL:
http://events.linuxfoundation.jp/sites/events/files/slides/Intriducing_the_CIP-LCJ2016.pdf

* Introducing the Civil Infrastructure Platform Project (ELC 2016,
April 2016)
Note: This is the first official presentation by the CIP
URL:
http://events.linuxfoundation.org/sites/events/files/slides/Introducing%20the%20Civil%20Infrastructure%20Platform.pdf

-----------------
The following presentation was made before the CIP launch, but it might
be a good reference to know how and why we start the CIP.

* Applying the Linux to the Civil Infrastrucure (LinuxCon Japan 2015,
June 2015)
URL:
http://elinux.org/images/7/74/Applying_Linux_to_the_Civil_Infrastructure-LinuxCon_Japan_2015.pdf

* Applying Linux to the Social Infrastructure BoF (ELC 2015, Apr 2015)
URL:
http://events.linuxfoundation.org/sites/events/files/slides/ELC_2015_SIP.pdf

* Using Embedded Linux for Infrastructure Systems (ELC Europe, October
2014)
URL:
http://events.linuxfoundation.jp/sites/events/files/slides/ELCE2014-Using%20Embedded%20Linux%20for%20Infrastructure%20Systems.pdf
-----------------

Best regards,
Yoshi


On 2016/10/05 2:50, Agustin Benito Bethencourt wrote:
Hi,

CIP ha set up a public wiki. It has very little content at this point
and there is no policy yet to add editors. We are sorting things out.

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start

Please take a look and let me know what can we do to improve it. we
will include the link in tomorrow's presentation at LinuxCon EU.

Best Regards

Sent from mobile. Please excuse my brevity.
--
Agustín Benito Bethencourt
@toscalix


Re: Maintenance policies and early considerations IV

Takuo Koguchi
 

Hi Agustin,
Let me understand what you wrote.
CIP should avoid making any such promise because:

* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not is difficult and risky - CIP
users set their own kernel configurations, so there will not be a
single kernel ABI for IHVs to target anyway
Correction:

Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that is difficult and risky - CIP users set
their own kernel configurations, so there will not be a single kernel ABI for IHVs to
target anyway
Is the correction correct?
I thought you wrote;
* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not (change the kernel module API and/or ABI )is difficult and risky - CIP
Am I wrong?

Takuo Koguchi


Re: Maintenance policies and early considerations IV

Daniel Sangorrin
 

Hi Koguchi-san,

I think you are right. It's my fault, sorry.

Daniel

-----Original Message-----
From: cip-dev-bounces@lists.cip-project.org [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of 小口琢夫 / KOGUCHI,
TAKUO
Sent: Friday, October 07, 2016 4:35 PM
To: 'Agustin Benito Bethencourt'; cip-dev@lists.cip-project.org
Subject: Re: [cip-dev] Maintenance policies and early considerations IV

Hi Agustin,
Let me understand what you wrote.
CIP should avoid making any such promise because:

* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not is difficult and risky - CIP
users set their own kernel configurations, so there will not be a
single kernel ABI for IHVs to target anyway
Correction:

Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that is difficult and risky - CIP users set
their own kernel configurations, so there will not be a single kernel ABI for IHVs to
target anyway
Is the correction correct?
I thought you wrote;
* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not (change the kernel module API and/or ABI )is difficult and risky - CIP
Am I wrong?

Takuo Koguchi



_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev


Re: Maintenance policies and early considerations IV

Ben Hutchings <ben.hutchings@...>
 

On Fri, 2016-10-07 at 07:34 +0000, 小口琢夫 / KOGUCHI,TAKUO wrote:
Hi Agustin,
Let me understand what you wrote.
CIP should avoid making any such promise because:

* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not is difficult and risky - CIP
users set their own kernel configurations, so there will not be a
single kernel ABI for IHVs to target anyway
Correction:

Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that is difficult and risky - CIP users set
their own kernel configurations, so there will not be a single kernel ABI for IHVs to
target anyway
Is the correction correct?
The first version is what I wrote, and the correction says something I
did not mean to say.

I thought you wrote;
* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not (change the kernel module API and/or ABI )is difficult and risky - CIP
Am I wrong?
No, you understand me rightly.

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


ELCE talk about embedded systems long term maintenance

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

the slides[1] from the talk "Long-Term Maintenance, or how to (mis-)manage embedded systems for 10+ years" by Jan Luebbe are available.

I assume by next week we will have the video.

[1] http://events.linuxfoundation.org/sites/events/files/slides/PRE-trunk-ELCE-LongTermMaintenance.pdf
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


First CIP kernel will be 4.4

Agustin Benito Bethencourt <agustin.benito@...>
 

Hi,

At LinuxCon EU, during the CIP talk it was announced that the first CIP kernel will be 4.4

Please find the slides of all the 2016 talks about CIP in our wiki[1].

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@codethink.co.uk


Re: 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


Re: Maintenance policies and early considerations IV

Jan Kiszka
 

On 2016-09-22 14:59, Agustin Benito Bethencourt wrote:
Hi,

at CIP we need to have a clear view of what "Support" means in the
context of the Super Long Term Support kernel.

++ What kind of support will CIP provide? To whom?

CIP will support its members and their developers, not system
administrators or end users. With the current number of members, there
should not be a need for a 'first line' of support between them and the
CIP core developers, though that may change if membership grows
significantly.

Commercial Linux based distributions like RHEL promise that a subset of
the kernel module API and ABI remains stable within a major release, so
that many out-of-tree modules can be used without needing to update the
module source or binaries along with the kernel. Some IHVs rely on this
to distribute driver modules in binary form.

CIP should avoid making any such promise because:

* Upstream fixes frequently change the kernel module API and/or ABI and
backporting them in a way that does not is difficult and risky - CIP
users set their own kernel configurations, so there will not be a single
kernel ABI for IHVs to target anyway

* CIP users are responsible for binary releases of both the kernel and
out-of-tree modules, so can ensure that they are properly synchronised.

* The criteria for backporting bug fixes will presumably be based on
'stable-kernel-rules.txt'. However, In CIP context, it is recommended
to be more precise than that.
Nit: it's stable_kernel_rules.txt. We should start this way and
augment/adjust rules after discussions as we find potential conflicts.

Sounds reasonable to me in general.

Jan

--
Siemens AG
Corporate Technology
Research & Technology Center
CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux
Otto-Hahn-Ring 6
81739 Muenchen
Tel.: +49 89 636-634006
Fax: +49 89 636-33045
mailto:jan.kiszka@siemens.com

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard
Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief
Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina
Kugel, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin
and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB
12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322


Re: Maintenance policies and early considerations I

Hidehiro Kawai
 

Hi,

I'm sorry for the late response.

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

during the Technical Committee Meeting, last Monday, Ben Hutchings
brought to the attention of the participants several topics to consider.
I would like to bring them here. This is the first one

++ When do CIP should pick up a kernel?

+++ Maintainability effort

New major versions of commercial Linux Distributions are released at 3-4
year intervals, so that typically only 4 versions need to be supported
at one time. Given that CIP's support period is meant to be even
longer, it won?t be sustainable to extend every 'long term' branch, but
only takes on a new branch every 2-4 years.
Assuming we release new products in every 2 years, 2-3-year release
cycle would be feasible.

Maintaining multiple branches is hard work, but its effort would be
decreased after 5 years from the release.

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

+++ Backport effort

The longer the intervals between new CIP branches, the greater need
there will be for CIP or individual members to backport new hardware
support (which carries its own risks).

+++ Trade-off

This trade-off is perhaps the most difficult issue to decide.


Best Regards


Re: 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


Re: Maintenance policies and early considerations III

Hidehiro Kawai
 

Hi,

(2016/09/22 21:56), Agustin Benito Bethencourt wrote:
Hi,

the below considerations were discussed during the Members meeting.
There is no conclusion yet about how to proceed.

++ Security fixes

+++ Out-of-tree drivers

The embedded systems that CIP will be used in will also often require
out-of-tree drivers and will sometimes include other changes of unknown
quality to their kernel. It needs to be made clear to members that
these modifications are unsupported, and that when they want the CIP
core team to address a bug found in such a modified kernel they must
first demonstrate that it exists in the CIP source release.
I agree on that. CIP don't need to care about out-of-tree drivers.

+++ Security updates

Commercial Linux based distributions like RHEL/SLE typically has
security updates available for the most serious issues (such as
privilege escalation) within a few days of them being publicly known, if
not on the first day.

CIP may be able to achieve this with its source releases but its members
may take much longer to release and deploy binary updates, maybe due to
valid concerns about the risk of regression or limited opportunities to
deploy updates. In the worst case, they may use CIP as an
advertising/compliance point but rarely bother to update. For this
reason Ben H. thinks it's important to draw on the work of the Kernel
Self-Protection Project to add mitigations against common types of
vulnerability. That work is slowly filtering into mainline and at least
some of it could be backported.
I think it is important to prepare for zero-day attacks, and the Kernel
Self-Protection Project would help it. If it could be backported,
doing it is preferred. But does it make the long-term maintenance difficult?

+++ Request to members from maintainer

During the meeting Ben requested CIP members to provide him some
guidelines or policies currently followed to choose security patches.
This information will hopefully provide some light that help maintainers
to define some basic policies for choosing security fixes. This policies
need to be tested over time.

Due to the length of the maintenance period, it is unlikely that the
same person/team maintain the kernel for the entire life cycle so the
main policies at least need to be left written.
Basically, I expect CIP supports all CVEs which are related to supported
features by CIP. But human resources are limited, so CIP members might
need to prioritize them depending on their impact.

Best regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

41 - 60 of 7061