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

Description

The WindowManager and HomeScreen under developing are named with suffix '2017' and those are used to identify old and new so far.

But this must lead to confusion and redundancy in management recipes in AGL yocto integration in the future.

From the beginning, homescreen and windowmanager used '*_git.bb' because their policy is 'single repository with multiple version'. But in the new HMI framework, it loks like the policy of 'separate repositories for each version'. So new HMI framework should use appropriate versioning to recipes instead of using '_git.bb'.

I propose to use an appropriate versioning like below.

  • Remove 2017 suffix from filename of recipes and name of pakcages for HomeScreen/WindowManager 2017.

  • Use version '2017' to recipes for HomeScreen/WindowManager 2017
    Change:

    To:

  • Add version '2016' to old libhomescreen (used by old and new)
    Change:

    To:

  • Add version '2017' to libwindowmanager (used only by new)

    To:

 

At the very latest, this should be done before new HMI framework is integrated into meta-agl/meta-agl-demo from meta-agl-devel.
 

 

Environment

None

Activity

Jan-Simon Moeller 
November 9, 2017 at 11:20 AM
(edited)

 

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

Tadao Tanikawa 
November 9, 2017 at 9:29 AM
(edited)

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.

Jan-Simon Moeller 
November 9, 2017 at 8:31 AM

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

 

Tadao Tanikawa 
November 9, 2017 at 7:21 AM
(edited)

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.

Xin Zhou 
November 7, 2017 at 3:42 AM

CC:

Fixed

Details

Assignee

Reporter

Labels

Components

Affects versions

Priority

Created November 6, 2017 at 3:15 AM
Updated September 1, 2020 at 2:37 PM
Resolved September 1, 2020 at 2:37 PM