Date   

Re: Renesas dev CIP repository announcement

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: Chris Paterson [mailto:Chris.Paterson2@...]
Sent: Wednesday, June 28, 2017 2:47 PM
..
- reboot doesn't seem to work (it works on the factory kernel 3.10).
This is a known issue that we currently have a workaround for. For development we could add this to [4], but it's a bit ugly.
OK. I think it's not so important, but it could help during CI testing to reboot the board in a soft manner.

By the way, do you have some test script to check that every module is
working fine?
Not at the moment, we are currently working on adding support for the CIP test framework, but this won't be ready for a while yet
I'm afraid.
Maybe it would be nice to have them inside the kernel as kselftests.

Thanks,
Daniel



[3] http://www.iwavesystems.com/downloads//products/cpu-modules/renesas/rz-g1m-q7-som/g20d-rz-g1m-som-block-diagram-
R1.1.pdf
[4] https://github.com/renesas-rz/renesas-cip

Kind regards, Chris


Thanks,
Daniel


Re: Project-X (minimal root filesystem) for renesas board

Daniel Sangorrin <daniel.sangorrin@...>
 

Ho Koguchi-san

-----Original Message-----
From: 小口琢夫 / KOGUCHI,TAKUO [mailto:takuo.koguchi.sw@...]
Sent: Wednesday, June 28, 2017 5:35 PM
To: Daniel Sangorrin; cip-dev@...
Cc: 'Chris Paterson'
Subject: RE: Project-X (minimal root filesystem) for renesas board

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost identical?
linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you update linux-cip.
I think this is not a good approach. We would need to have a new linux-cip folder for each
release.

Patches for the cyclone board should be on its own CIP kernel repository (where you
can merge cip releases and add tags). Then, we can choose which version we want
by specifying the repository and tag/commit_id.

- I can see some xserver-related definitions on the board's configuration file. Are those
necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine. xserver-related definition was inculude in the original. I am not
sure if it is necessary.
I don't think it is necessary since the CIP root filesystem only supports a few packages. Do you mind if I rewrite this and other
unnecessary definitions?

Thanks,
Daniel



Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m board which is equipped
with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone on the deby-armv7
folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost identical?
- I can see some xserver-related definitions on the board's configuration file. Are those
necessary?

Thanks,
Daniel

[1] https://gitlab.com/cip-playground/project-x/tree/master/deby-armv7


Re: Project-X (minimal root filesystem) for renesas board

Takuo Koguchi
 

Hi Daniel-san,

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost identical?
linux-cip directory is for linux-4.4.55-cip3.
linux-cip2 is for the previous release and it is not necessary if you update linux-cip.

- I can see some xserver-related definitions on the board's configuration file. Are those
necessary?
beaglebone.conf is based on poky/meta-yocto-bsp/conf/machine. xserver-related definition was inculude in the original. I am not sure if it is necessary.


Takuo Koguchi


-----Original Message-----
From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: Wednesday, June 28, 2017 4:05 PM
To: cip-dev@...; 小口琢夫 / KOGUCHI,TAKUO
Cc: 'Chris Paterson'
Subject: [!]Project-X (minimal root filesystem) for renesas board

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m board which is equipped
with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone on the deby-armv7
folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost identical?
- I can see some xserver-related definitions on the board's configuration file. Are those
necessary?

Thanks,
Daniel

[1] https://gitlab.com/cip-playground/project-x/tree/master/deby-armv7


Project-X (minimal root filesystem) for renesas board

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Koguchi-san,
Cc: Chris, cip-dev

I'm going to add support to project-X for the Renesas iwg20m board which is equipped with an armv7 chip.
I have noticed that you added support for beaglebone and cyclone on the deby-armv7 folder [1].

I have a few questions:
- Why do you have two directories "linux-cip" and "linux-cip2" that are almost identical?
- I can see some xserver-related definitions on the board's configuration file. Are those necessary?

Thanks,
Daniel

[1] https://gitlab.com/cip-playground/project-x/tree/master/deby-armv7


Re: Renesas dev CIP repository announcement

Chris Paterson
 

Hello Daniel,

From: Daniel Sangorrin [mailto:daniel.sangorrin@...]
Sent: 28 June 2017 04:07

Hi Chris,

-----Original Message-----
From: cip-dev-bounces@...
[mailto:cip-dev-bounces@...] On Behalf Of Chris
Paterson
Sent: Tuesday, June 20, 2017 5:49 PM
To: cip-dev@...
Subject: [cip-dev] Renesas dev CIP repository announcement

Dear CIP friends,



I’d like to announce the availability of a development repo [1] based
on the CIP Kernel for the iWave RZ/G1M Qseven Development Platform
[2].



The main aim of this repository is to allow CIP users to get up and
running with the Renesas CIP reference platform. Please note that this is
just an interim step as support for the platform is added
upstream/backported to the CIP Kernel.



Currently there are two branches, one based on v4.4.55-cip3, and the other
based on v4.4.69-cip4.



Please use the “shmobile_defconfig” configuration when compiling, and
use r8a7743-iwg20m.dtb. uImage LOADADDR should be set to
"0x40008000". For u-boot environment settings, please see the iWave
documentation that should come with the boards.





[1] https://github.com/renesas-rz/renesas-cip

[2] http://www.iwavesystems.com/rz-g1m-qseven-development-kit.html
<http://www.iwavesystems.com/rz-g1m-qseven-
development-kit.html>
I just wanted to tell you that I managed to build and boot the CIP kernel on
the iwg20m board from tftpboot.

The only problem I had was that the original u-boot environment (kernel
3.10) used /dev/mmcblk2p2, whereas for kernel CIP 4.4 (using the same
original filesystem) I had to change that to root=/dev/mmcblk0p2.
Thank you for pointing this out. I'm afraid that everyone will need to make this change if using the supplied u-boot env. Sorry I missed this.


Apart from that:
- the upper blue usb 3 connector doesn't seem to work. (it didn't work
either on the factory kernel 3.10)
The RZ/G1M only supports one channel of USB3.0. The carrier board is used for other SoC SOM modules, hence there are some connectors that will not work either due to lack of support or multiplexing - SATA, HDMI, the upper USB3.0 port.

For full details, please see the "QsevenDevKit-HardwareUserGuide" which should have come with the platform on a CD.

You can also see the block diagram on the iWave website [3].


- reboot doesn't seem to work (it works on the factory kernel 3.10).
This is a known issue that we currently have a workaround for. For development we could add this to [4], but it's a bit ugly.



By the way, do you have some test script to check that every module is
working fine?
Not at the moment, we are currently working on adding support for the CIP test framework, but this won't be ready for a while yet I'm afraid.


[3] http://www.iwavesystems.com/downloads//products/cpu-modules/renesas/rz-g1m-q7-som/g20d-rz-g1m-som-block-diagram-R1.1.pdf
[4] https://github.com/renesas-rz/renesas-cip

Kind regards, Chris


Thanks,
Daniel


Re: Renesas dev CIP repository announcement

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Chris,

-----Original Message-----
From: cip-dev-bounces@... [mailto:cip-dev-bounces@...] On Behalf Of Chris Paterson
Sent: Tuesday, June 20, 2017 5:49 PM
To: cip-dev@...
Subject: [cip-dev] Renesas dev CIP repository announcement

Dear CIP friends,



I’d like to announce the availability of a development repo [1] based on the CIP Kernel for the iWave RZ/G1M Qseven Development
Platform [2].



The main aim of this repository is to allow CIP users to get up and running with the Renesas CIP reference platform. Please note that
this is just an interim step as support for the platform is added upstream/backported to the CIP Kernel.



Currently there are two branches, one based on v4.4.55-cip3, and the other based on v4.4.69-cip4.



Please use the “shmobile_defconfig” configuration when compiling, and use r8a7743-iwg20m.dtb. uImage LOADADDR should be set
to "0x40008000". For u-boot environment settings, please see the iWave documentation that should come with the boards.





[1] https://github.com/renesas-rz/renesas-cip

[2] http://www.iwavesystems.com/rz-g1m-qseven-development-kit.html <http://www.iwavesystems.com/rz-g1m-qseven-
development-kit.html>
I just wanted to tell you that I managed to build and boot the CIP kernel on the iwg20m board from tftpboot.

The only problem I had was that the original u-boot environment (kernel 3.10) used /dev/mmcblk2p2, whereas
for kernel CIP 4.4 (using the same original filesystem) I had to change that to root=/dev/mmcblk0p2.

Apart from that:
- the upper blue usb 3 connector doesn't seem to work. (it didn't work either on the factory kernel 3.10)
- reboot doesn't seem to work (it works on the factory kernel 3.10).

By the way, do you have some test script to check that every module is working fine?

Thanks,
Daniel


CIP testing effort weeks 23 and 24

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

Dear CIP friends,

I should have sent this report last week but I was travelling.

For those of you who are not following our work closely at gitlab.com here is a summary of the main work that Don, Robert and myself have been doing.

* Supporting B@D 0.9.1 Release through cip-dev Mailing List & #cip channel.
** Updated CIP Diagram and tweaked documentation to enhance clarity and accuracy.
** Provided support to Daniel Wagner. Thanks you for your contributions.

* Emailing of test results to a mailing list. Created a manual method, now working on automated method.

* Generating a CIP initramfs for use in our VM and how to build one from scratch.

* Linaro changed the links to their build artifacts - Uploaded updated tests-0.1.tgz to download site that contain new links.

* Request process to get some additional repositories we will need for the Action 2.
** The new mailing list for sharing test results is already in place. As soon as we can share test results we will publish it.

The coming weeks we will keep working on setting up the test results reporting, testing B@D on Windows, setting up the new repositories and define how the reports should look like.

Best Regards

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


Re: Backporting to the CIP Kernel

Chris Paterson
 

Hello Ben.

Thank you for the quick feedback.

Kind regards, Chris

From: Ben Hutchings [mailto:ben.hutchings@...]
Sent: 20 June 2017 16:15

On Tue, 2017-06-20 at 14:53 +0000, Chris Paterson wrote:
Hello Ben,

I hope the move went okay.
Thanks. It didn't entirely, but the worst is over.

I plan to start backporting some patches to the CIP Kernel soon, to
begin adding support for the Renesas CIP reference platform.

I’ve had a look at [1] and have a few of queries…

1)
11. It or an equivalent fix must already exist in Linus' tree (upstream).
Is this rule set in stone? Or can patches that have been accepted into
the relevant maintainer’s branches be backported?

Positive: We don’t have to wait up to 10 weeks for the new merge
window before backporting patches
Negative: There is a small chance that the patches will be rebased in
the move from linux-next to linux
I think it would be fine to relax this for new hardware support. There isn't
the same risk of regression if the kernel didn't support the hardware before.

2)
For submitting patches, I assume you would like them sent to cip-dev?
Yes. You can send a git pull request, but I would like to see the patches on
the list even then.

3)
For patches that add support for a new platform, would you like them
submitted in small series, as they were upstreamed? Or in one big pull
request once major support for the platform has been added upstream?
Shorter series are more easy for me to digest.

Ben.

[1]
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernel
maintenance

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: CIP Kernel release cadence

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

Hi Chris,

I think I mentioned before some of the below arguments when this topic was risen months ago. It is a good time to publish them here.

On 20/06/17 17:18, Ben Hutchings wrote:
On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:
Hello Ben,

Do you have a plan for when future releases of the CIP Kernel will be
made?

It would be good to have a fixed release cadence or roadmap, so people
using the Kernel can plan their activities accordingly.
I expect to release about every month, and whenever there's an urgent
security update (which there will be soon, for the "stack clash" issue).
I would like to keep flexibility here, that is, do not tight ourselves to releases yet for a variety of reasons. These are the main ones I can think of right now:

* We are in an LTS phase. Defining a cadence at this point might reinforce the idea that our kernel maintenance process is somehow different than LTS when, except for a few packages, it is not yet. That was intentional.

* I would like to be able to consistently test the kernel, even with a single test, before claiming to make releases, that is, before making a public commitment on any delivery process. The expectations can be higher that we can commit to.

* We do not know at this point what the maintenance cycle is going to be from the kernel community. I am not suggesting that we have to follow it, but before defining our cadence, I would have a clear idea about what upstream will do.

* A kernel release for SLTS has severe implications in other areas, like the testing tools, testing results, tests, etc. We need also to freeze/store/release them, together with the build instructions, metadata, artifacts, source code.... In other words, we need to define what "a release" means for CIP and how much effort requires.

* With the above and the fact that we are starting to put effort in -RT, I wonder if we will talk about releasing the CIP kernel or we will talk about releasing the CIP platform (assuming that at the beginning the kernel is the main bit).

Defining a release today might play against us in a year or two.

Once this said, if Members require at this point a cadence, we will provide one but I think that sticking to LTS cycle until Feb'18 and assuming that we will catch up every 4-8 weeks is the way to go. Once the 4.4 maintainer is published, let's talk to him/her and take decisions.

Is there a specific reason why you need a cadence now beyond what LTS provides? I am trying to understand the details in order to think about a solution for Renesas compatible with the above.

Best Regards

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


Re: CIP Kernel release cadence

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2017-06-20 at 09:12 +0000, Chris Paterson wrote:
Hello Ben,

Do you have a plan for when future releases of the CIP Kernel will be
made?

It would be good to have a fixed release cadence or roadmap, so people
using the Kernel can plan their activities accordingly.
I expect to release about every month, and whenever there's an urgent
security update (which there will be soon, for the "stack clash" issue).

Ben.

--
Ben Hutchings
Software Developer, Codethink Ltd.


Re: Backporting to the CIP Kernel

Ben Hutchings <ben.hutchings@...>
 

On Tue, 2017-06-20 at 14:53 +0000, Chris Paterson wrote:
Hello Ben,

I hope the move went okay.
Thanks. It didn't entirely, but the worst is over.

I plan to start backporting some patches to the CIP Kernel soon, to
begin adding support for the Renesas CIP reference platform.

I’ve had a look at [1] and have a few of queries…

1)
11. It or an equivalent fix must already exist in Linus' tree (upstream).
Is this rule set in stone? Or can patches that have been accepted into
the relevant maintainer’s branches be backported?

Positive: We don’t have to wait up to 10 weeks for the new merge window before backporting patches
Negative: There is a small chance that the patches will be rebased in the move from linux-next to linux
I think it would be fine to relax this for new hardware support. There
isn't the same risk of regression if the kernel didn't support the
hardware before.

2)
For submitting patches, I assume you would like them sent to cip-dev?
Yes. You can send a git pull request, but I would like to see the
patches on the list even then.

3)
For patches that add support for a new platform, would you like them
submitted in small series, as they were upstreamed? Or in one big pull
request once major support for the platform has been added upstream?
Shorter series are more easy for me to digest.

Ben.

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

--
Ben Hutchings
Software Developer, Codethink Ltd.


Backporting to the CIP Kernel

Chris Paterson
 

Hello Ben,

 

I hope the move went okay.

 

I plan to start backporting some patches to the CIP Kernel soon, to begin adding support for the Renesas CIP reference platform.

 

I’ve had a look at [1] and have a few of queries…

 

1)

>11. It or an equivalent fix must already exist in Linus' tree (upstream).

Is this rule set in stone? Or can patches that have been accepted into the relevant maintainer’s branches be backported?

 

Positive: We don’t have to wait up to 10 weeks for the new merge window before backporting patches

Negative: There is a small chance that the patches will be rebased in the move from linux-next to linux

 

2)

For submitting patches, I assume you would like them sent to cip-dev?

 

3)

For patches that add support for a new platform, would you like them submitted in small series, as they were upstreamed? Or in one big pull request once major support for the platform has been added upstream?

 

 

[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipkernelmaintenance

 

Kind regards, Chris


CIP Kernel release cadence

Chris Paterson
 

Hello Ben,

 

Do you have a plan for when future releases of the CIP Kernel will be made?

 

It would be good to have a fixed release cadence or roadmap, so people using the Kernel can plan their activities accordingly.

 

 

Kind regards, Chris


Renesas dev CIP repository announcement

Chris Paterson
 

Dear CIP friends,

 

I’d like to announce the availability of a development repo [1] based on the CIP Kernel for the iWave RZ/G1M Qseven Development Platform [2].

 

The main aim of this repository is to allow CIP users to get up and running with the Renesas CIP reference platform. Please note that this is just an interim step as support for the platform is added upstream/backported to the CIP Kernel.

 

Currently there are two branches, one based on v4.4.55-cip3, and the other based on v4.4.69-cip4.

 

Please use the “shmobile_defconfig” configuration when compiling, and use r8a7743-iwg20m.dtb. uImage LOADADDR should be set to "0x40008000". For u-boot environment settings, please see the iWave documentation that should come with the boards.

 

 

[1] https://github.com/renesas-rz/renesas-cip

[2] http://www.iwavesystems.com/rz-g1m-qseven-development-kit.html

 

Kind regards, Chris


New repository request kernelci-frontend-config

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

Hi,

in order to fix the technical issue explained early this week in the mailing list and take control of how future changes in the kernelci-frontend-config upstream repo, we need to mirror in cip-testing subgroup that repository from Github.

So in cip-testing subgroup I need to create a new repo:

Name: kernelci-frontend-config

mirror of https://github.com/kernelci/kernelci-frontend-config

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


CIP testing project: outcome of the OSSJ

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

Dear CIP friends,

as you know, B@D was released right before OSSJ started. I would like to thank the LF and the CIP board for doing the extra effort to go through the license clearance/approval process on time. I would also like to thank my colleagues at Codethink for putting extra hours on the release to make it happen right before the event.

++ B@D at the CIP open workshop

I invested about 20 min talking about what B@D is about and about the next steps in the CIP testing project. The intention is to repeat the workshop at ELCE. Hopefully there we will have a technical session and even a training session, if there is enough interest.

++ B@D at the CIP booth

I was happily surprised when I saw that Renesas made it and could show B@D working at the CIP booth on their new dev board to test the CIP kernel. They will need some time to publish and upstream the board support but they are working on it. It was a simple still great demo. Congrats.

++ B@D release impact

It was of great help to have the Twitter account set up before the release so we could make some noise with the release and get some followers to start with.

Specially cool was to have the Chinese translations of the release social media messages:

https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingmanagement#marketing-material-and-plan

Thanks SZ Lin. I hope we had some hits in Taiwan and maybe in China. We will try to get additional translations the next time.

I will be collecting some references/mentions of the release in this ticket: https://gitlab.com/cip-project/cip-testing/testing/issues/89 Feel free to add those you are aware of.

I plan to submit a talk about our progress in the testing front for ELCE. Action 2: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting

++ Release feedback

As expected, most of the people I talked to about B@D or approached me at OSSJ/ALS did not know much about it so I spent most of the time explaining what it is, the use-case behind it, why we needed such a tool, what will be our relation with upstream, etc.

I am a member of the AGL CIAT group. AGL have a new project to build a testing infrastructure service so I spent some time talking to other CIAT members about it and how we can join forces, assuming that the service architecture AGL is going for (semi-centralised) and ours (decentralised) has significant differences. Some of the tools will be the same though so there will be cross-roads that we will need to detect (even anticipate) and take advantage of to collaborate.

I also had an interesting conversation with Alan Bennet, Director at Linaro. We worked together back in the days when kernelci.org was designed and developed within Linaro. He was interested in the use case behind B@D. Since I had a talk at ALS about testing in automotive, I mentioned B@D too. As you probably know, Linaro is the organization behind LAVA and KernelCI, the tools used in kernelci.org

++ Improvements or requests

I got two requests from the event that has been already discussed within the testing team:

* B@D running behind a proxy: https://gitlab.com/cip-project/cip-testing/testing/issues/99
** We will need help from contributors to test the changes out of this ticket, specially from those of you who work behind a proxy.

* B@D working on Windows: https://gitlab.com/cip-project/cip-testing/testing/issues/106
** It would be of great help if any of you help us with this use case, since we do not use Windows machines on daily basis. If there are no takers, we will do it.

Feel free to join the CIP testing team on Friday at 10:00 UTC through Google Hangout to discuss the above or any other topic related with B@D or testing at CIP: https://plus.google.com/hangouts/_/codethink.co.uk/team-event-cip?hceid=YWd1c3Rpbi5iZW5pdG9AY29kZXRoaW5rLmNvLnVr.m6jv292u7masvpa1lb221rom1g&authuser=1

Did you get any additional feedback?

Best Regards

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


Re: Some outcome of the OSSJ event

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

Hi,

On 14/06/17 15:33, Agustin Benito Bethencourt wrote:
Hi,

1.- During the Open Source Summit Japan two blog post were published on
the CIP website apart from the B@D release announcement.

The first one was written by Nori:
https://www.cip-project.org/blog/2017/06/07/event-report-open-source-summit-japan-2017


I wrote the second one:
https://www.cip-project.org/blog/2017/06/01/board-at-desk-bd-and-forthcoming-challenges


You can follow these and other updates through our brand new twitter
account: @cip_project

2.- I was glad to see Renesas showing B@D at the CIP booth with their
RZ/G1M board. As I have mentioned before, CIP booth was one of the top
ones. I mean it. Congratulations to Hitachi, Toshiba, Plat'Home and
Renesas crew for the effort and the results.

3.- Check the slides from Yoshi's talk at OSSJ about CIP:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences
It was well attended.

4.- I really liked Wolfgang's talk providing an overview of Real Time
OSs. It required more time than he had but still was worth it. Let's
wait for the videos.

5.- The CIP TSC meeting was intense. Check the minutes:
https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_may302017


6.- Any feedback from the open workshop? I would like to hear what you
have to hear before providing mine :-)
7.- Have you read the CIP Whitepaper that was presented at the event? Link: https://wiki.linuxfoundation.org/_media/civilinfrastructureplatform/whitepaper_short.pdf (direct link).

There was a printed version in Japanese at the booth. I assume it won't be long before that version is also published in our wiki.

Anything else that should be mentioned? I will write about B@D in a separate mail.

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


Some outcome of the OSSJ event

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

Hi,

1.- During the Open Source Summit Japan two blog post were published on the CIP website apart from the B@D release announcement.

The first one was written by Nori: https://www.cip-project.org/blog/2017/06/07/event-report-open-source-summit-japan-2017

I wrote the second one: https://www.cip-project.org/blog/2017/06/01/board-at-desk-bd-and-forthcoming-challenges

You can follow these and other updates through our brand new twitter account: @cip_project

2.- I was glad to see Renesas showing B@D at the CIP booth with their RZ/G1M board. As I have mentioned before, CIP booth was one of the top ones. I mean it. Congratulations to Hitachi, Toshiba, Plat'Home and Renesas crew for the effort and the results.

3.- Check the slides from Yoshi's talk at OSSJ about CIP: https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipconferences It was well attended.

4.- I really liked Wolfgang's talk providing an overview of Real Time OSs. It required more time than he had but still was worth it. Let's wait for the videos.

5.- The CIP TSC meeting was intense. Check the minutes: https://wiki.linuxfoundation.org/civilinfrastructureplatform/tsc-meetings/tsc_mm_may302017


6.- Any feedback from the open workshop? I would like to hear what you have to hear before providing mine :-)


Best Regards

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


Where to follow or report the CIP testing project bugs

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

Hi,

in order to follow the CIP testing project current bugs or reporting new ones, please go to https://gitlab.com/cip-project/cip-testing/testing/boards/322796?&label_name[]=bug

You will need to have a gitlab.com account to report them.

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


Re: Request of a new mailing list

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

Hi,

On 13/06/17 22:30, Annie Fisher wrote:
Greetings,

I've submitted for the cip-testing-results
<mailto:cip-testing-results@...> mail list and have
added Agustin as the administrator. This process usually takes 1-2
days, so will come back to this group once the mail list has been finalized.
Thank you very much.


Take care and hope you all are well.
I enjoyed the event. I think CIP organised a great booth at OSSJ.


Cheers,
Annie

Annie Fisher, MPA CSM
Program Manager, The Linux Foundation
Location & Time-zone: San Francisco, CA, PST
web: https://www.linuxfoundation.org/
email: afisher@... <mailto:afisher@...>


On Tue, Jun 13, 2017 at 11:14 AM, Agustin Benito Bethencourt
<agustin.benito@... <mailto:agustin.benito@...>>
wrote:

Hi,

public, please so people can join.




On 13 June 2017 18:41:07 CEST, Annie Fisher
<afisher@... <mailto:afisher@...>>
wrote:

Greetings Agustin,

Thank you for this information. One more question: would you
like this to be a mail list that is private (the moderator
approves all those who subscribe)?

Thanks so much...will work to get this set up ASAP.

Cheers,
Annie

Annie Fisher, MPA CSM
Program Manager, The Linux Foundation
Location & Time-zone: San Francisco, CA, PST
web: https://www.linuxfoundation.org/
<https://www.linuxfoundation.org/>
email: afisher@...
<mailto:afisher@...>


On Tue, Jun 13, 2017 at 5:32 AM, Agustin Benito Bethencourt
<agustin.benito@...
<mailto:agustin.benito@...>> wrote:

Hi Annie,

the data for the mailing list is:
* Proposed name: cip-testing-results@...
<mailto:cip-testing-results@...>
* Admin: agustin.benito@...
<mailto:agustin.benito@...>
** I would add a second person from a different company.

I will configure the mailing list through the mailman
interface once I have the credentials.


On 31/05/17 07:22, Agustin Benito Bethencourt wrote:

Hi,

in order for the CIP testing project to start working on
milestone 2 we
need to have a mailing list to provide test-results.

The proposed name for the list is:

cip-testing-results@...
<mailto:cip-testing-results@...>

Best Regards

Best Regards
--
Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito@...
<mailto:agustin.benito@...>



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

8961 - 8980 of 9278