Date   

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

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


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: Maintenance policies and early considerations III

Daniel Sangorrin <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


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: 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: 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: 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: 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: New IRC channel for #cip

Urs Gleim
 

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



Maintenance policies and early considerations IV

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

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.

Best Regards

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


Maintenance policies and early considerations III

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

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.

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

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

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


Maintenance policies and early considerations II

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

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


Maintenance policies and early considerations I

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

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.

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

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


Re: CIP Mailing List Submission

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

Hi,

On 21/09/16 14:25, Don Brown wrote:
Hi Everyone,

I am Don Brown and I'm an individual contributor to CIP, although I am
looking for an employer that would allow me to work on CIP as part of my
employment. I am based in Indianapolis, IN. I have a rather unique
skillset that I'll offer to you as we create the use cases.
Welcome Don.


I received my Bachelor of Science in Computer Integrated Manufacturing
Technology (CIMT) from Purdue University. Out of college, I worked for
Allen-Bradley as an Applications Engineer and then worked as a Software
Controls Engineer for several small machine builders until I landed at
the Eli Lilly Corporate Center managing the Utility and Building
Automation Systems. In 2009 I moved to Schneider Electric as a Program
Manager for Energy Saving Projects for the GSA. In 2015, I returned to
the Lilly Corporate Center as an Engineering Specialist responsible for
Research automation equipment.

For the past 9.5 years, I've been teaching at ITT Technical Institute in
both the Information Technology and Electronics Technology programs. I
taught several courses, but the relevant ones for CIP are:

* Linux Networking
* Linux Security
* C Programming
* C++ Programming
* Microprocessors & Microcontrollers
* Programmable Logic Controllers (PLC's)
* Java I & II Programming

I am currently working on my Masters degree in Computer Science with a
specialization in Computer Systems Security at Colorado Technical
University (Distance Learning). I expect to graduate in June 2017.

I am looking forward to working with you all. Please let me know if
there is anything I can do to help develop the use cases. Do we have a
format or template we can use?
Not that I am aware of. Since use cases will be part of the LinuxCon Eu and ELCE CIP talks, maybe that could be a starting point.


Thank you!

Sincerely,

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


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


CIP Mailing List Submission

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

Hi Everyone,

I am Don Brown and I'm an individual contributor to CIP, although I am looking for an employer that would allow me to work on CIP as part of my employment. I am based in Indianapolis, IN. I have a rather unique skillset that I'll offer to you as we create the use cases.

I received my Bachelor of Science in Computer Integrated Manufacturing Technology (CIMT) from Purdue University. Out of college, I worked for Allen-Bradley as an Applications Engineer and then worked as a Software Controls Engineer for several small machine builders until I landed at the Eli Lilly Corporate Center managing the Utility and Building Automation Systems. In 2009 I moved to Schneider Electric as a Program Manager for Energy Saving Projects for the GSA. In 2015, I returned to the Lilly Corporate Center as an Engineering Specialist responsible for Research automation equipment.

For the past 9.5 years, I've been teaching at ITT Technical Institute in both the Information Technology and Electronics Technology programs. I taught several courses, but the relevant ones for CIP are: 
  • Linux Networking
  • Linux Security
  • C Programming
  • C++ Programming
  • Microprocessors & Microcontrollers
  • Programmable Logic Controllers (PLC's)
  • Java I & II Programming
I am currently working on my Masters degree in Computer Science with a specialization in Computer Systems Security at Colorado Technical University (Distance Learning). I expect to graduate in June 2017.

I am looking forward to working with you all. Please let me know if there is anything I can do to help develop the use cases. Do we have a format or template we can use?

Thank you!

Sincerely,

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


Re: Stay at Berlin for ELCE

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

Hi,

On 21/09/16 11:51, Masato Minda wrote:
Dear All;

I am Masato Minda of Plat'Home. Please coll me "minmin".

I will attend the ELCE on behalf of my colleagues. And, I will do an exhibition and demonstration in the ELCE.

I have to book a flight and hotel for ELCE.

I would choose the flight to arrive at the venue in the afternoon of October 10. And I will leave Berlin on October 14.

How do you think about this schedule?
I will be there on the 10th and leave the same day that you. So I guess is fine.

(My schedule is not fixed.)

Regards,

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


Stay at Berlin for ELCE

minmin@plathome.co.jp
 

Dear All;

I am Masato Minda of Plat'Home. Please coll me "minmin".

I will attend the ELCE on behalf of my colleagues. And, I will do an exhibition and demonstration in the ELCE.

I have to book a flight and hotel for ELCE.

I would choose the flight to arrive at the venue in the afternoon of October 10. And I will leave Berlin on October 14.

How do you think about this schedule?
(My schedule is not fixed.)

Regards,

Masato Minda


New IRC channel for #cip

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

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

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

8321 - 8340 of 8370