Suffix 2017 for new HMI framework should be corrected to appropriate version.

: I agree with your points. We made the decision during the dev-calls to be able to switch back.

The simple reason was : -EnoSource . W/O seeing the source code somewhere, we don't know what it is.

In general:

As usual it would have been better to enhance the components in place, but this was not done and we had to crunch-down a big patch-bomb into its components.

This required the staging area of the recipes and now we'll clean-up and move the pieces in the final places.

It is good to do it and I'm really happy to move the recipes and the git trees to a new location/merge into existing now as we know what presents are in the box.

TLDR:  RELEASE EARLY, RELEASE OFTEN.

Of cause, let's discuss more detail in next week

About placing the recipes for homescreen/windowmanager,  it was an unintentional, honest mistake that putting new recipes for next version of homescreen/windowmanager into another place than meta-agl-demo because old ones were already there and new homescreen/windowmanager should have been just next version of them.

I guess _git.bb was the cause of this confusion and whether repositories are different or not is not essential because naming/management of packages and repository are different things.

Storing new recipes for new version into meta-agl/meta-agl-demo is acceptable if properly PREFERRED_VERSION is supplied (developing next version is always unstable and staging, it's no problem ). 

Maybe I should have noticed earlier, but we should have put only configuration/template for enabling new hmi framework into meta-agl-devel and recipes for them kept storing original place with right form as next version.

-san:: We wanted to have a switch between 'old world' and 'new world' until we can fully migrate the default implementation.

As the 2 systems cannot coexist and provide the same functionality, the recommendation to Zheng was to add a 'switch'. Recipe inclusion based on a conditional was used first, but is rather ugly, that is why we recommended to put the virtual/ + PREFERRED_PROVIDER in place.

So call me guilty on that.

Of course, once we consolidate into just one Solution and just one set of git repo's this goes away.

Let's discuss it next week f2f. Also meta-agl-devel if not the final place - yes. But we needed to have a staging point to get the code in to work on it as a community. And before we see the code, we cannot tell what is there and give advice where to place it - see the reasoning ?

Virtual provider for libhomescreen, Change 11761 doesn't make sense.

A virtual provider can be used as a placeholder for the actual provider if several different recipes provide the same functionality and the actual provider would be determined at build time.

This means that each actual providers should have not only the same functionality but also API compatibility when virtual provider provides library.  As a result,  applications don't need to care about differences between the actual providers.

For example, virutal/libgles2 provides glesv2.pc (i.e. libGLESv2), virtual/jpeg provides libjpeg or libjpeg-turbo. 

On the other hand, as far as I know, libhomescreen-2017 has not compatible with old one for CES2017. If libhomescreen(old) is selected for homescreen-2017(new), bitbake would fail or system cannot run normally. A system integrator should take care about other dependencies to correct.

 IMHO, this mean that virtual/libhomescreen doesn't make sense as the placeholder for the actual provider and it is preferable to treat them as different versions.

This is why I proposed versioning rather than use virtual providers.

CC: