ocf demo / Sandbox/pcoval/for/qemux86 64

[rzr]

1 part to test workflow
this can be independently merged

[rzr]

I will test this patch set once the minnowboard branch land on github too

[rzr]

I tested successfully this patch set on minnowboard branch and documented how to replicate until it's merged :

https://at.projects.genivi.org/wiki/display/GDP/OCF

@as2902b

[tom--pollard]

I've built and deployed this on the qemu branch, it 'works' to the extent at which I expect it to behave so it gets a +1 from me in that sense.

[rzr]

thx @tom--pollard , btw if @jeremiah can help to relocate https://github.com/TizenTeam/meta-genivi-ocf-demo to GENIVI GH then I will fixup the url , or do it after it will also work

[jeremiah]

I've created: https://github.com/GENIVI/meta-genivi-ocf-demo

Does that help?

[rzr]

Thanks I will change url to the new one once merged

GENIVI/meta-genivi-ocf-demo#1

@as2902b

[rzr]

as @tom--pollard suggested iotivity layer can be integrated first without demos

[gunnarx]

The maintainers ultimately decide, but personally I'm opposed to including anything that is not yet being used in GDP. There is a big chance that actually exercizing the functionality becomes delayed and we just build up cruft in our project. As of today I think iotivitiy is only a dependency needed for the OCF demo.

The alternative is demonstrating something that fully works, i.e the "demo", then asking if we want that functionality exposed in GDP (which would likely need that most users have access to any hardware the demo needs and other aspects), and assuming there is a decision to include it, then integrate the whole function together with its needed dependencies.

[tom--pollard]

@rzr my point was that I think ocf-demo should be a part of meta-genivi-dev, as it's mainly just adding to the genivi-dev-platform bb image

[rzr]

Well merging components one per one would make cooperation smoother or easier, that's why I wanted to start with this simple iotivitymap app to validate the "development" platform.

Who to bother to decide if meta-oic is part of GDP or should stay in demo layer ?

[tom--pollard]

meta-oic is fine as a seperate layer imo, it's the ocf demo layer that seems excessive as it's own standalone layer

[jonathanmaw]

I am also in favour of merging this now, to make it easier to get the ocf demo merged later.

[rzr]

@jonathanmaw Good this was my plan too

@tom--pollard expect more to come into genivi-oicf layer (RVI gateway etc) as the moment there is just a basic sample to validate iotivity on gdp and then we'll can integate the remaining stuff , ok ?

I am adding @toscalix to this thread, to track this PR too

[as2902b]

IMHO, getting meta-oic to be part of the GDP is an important first step.
The OCF gateway & OCF servers can be part of the meta-genivi-ocf-demo. These are the key building blocks for the demo.
The Android, Tizen mobile and Gear S2 apps can be independently hosted in a public repo, since it is only for validation/example purpose.

Having an meta-oic integrated GDP gives us the flexibility to deploy the OCF-RVI gateway within GDP, without the need for a separate entity to host the gateway. It is one of the deployment models we have in mind.

Note : We use OIC and OCF interchangeably since the organization has been renamed recently.

[tom--pollard]

I presume you would want meta-oic merged to all target branches?

[rzr]

In any branch you want to let us continue the integration part.

I can work on qemu , minnow or rpi ..

[jonathanmaw]

Merging to all branches, in anticipation of patches to meta-genivi-dev which will add the ocf demo (so this patch can be properly exercised)

[gunnarx]

I'm ok if you want to actual git merges in steps, just long as the complete function exists and has been decided to be merged. For any function (not OCF specifically) as I said the decision to include it in entirety depends on the value of the function, the ability for all (most) users to appreciate and run the function (any special hardware required?) and so on. Such a decision I think ought to be discussed on the GDP call as a feature prioritization thing. In this case we saw it at AMM but in other cases demonstrating it on the meeting over WebEx, a short movie or whatever would make sense to convince everyone it should be included.

But today's call also opened the idea about optional features, and we might improve our understanding of how to handle such features in a good way.

[gunnarx]

+1 on keeping layers separate, generally speaking.