Date   

Added some basic content to the wiki

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

Hi,

in preparation to start reporting about the testing efforts, I have added some content to the wiki to provide context. Please let me know if there is anything wrong or that might be improved.

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

Best Regards

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


Re: Maintenance policies and early considerations IV

Hidehiro Kawai
 

Hi,

(2016/09/27 17:29), Agustin Benito Bethencourt wrote:
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.
We (our company members) agree.

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.
We think CIP doesn't need to kepp the kernel API/ABI.

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


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


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


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


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.


Re: Maintenance policies and early considerations IV

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Koguchi-san,

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

Daniel

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of 小口琢夫 / KOGUCHI,
TAKUO
Sent: Friday, October 07, 2016 4:35 PM
To: 'Agustin Benito Bethencourt'; cip-dev@...
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@...
https://lists.cip-project.org/mailman/listinfo/cip-dev


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

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@...
_______________________________________________
cip-dev mailing list
cip-dev@...
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@...


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


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

9141 - 9160 of 9202