2014-07-10 13:37 GMT+02:00 Counihan, Tom <[email protected]>: > The thread triggers in my head a question - what is the boundary of common? > My investigation leads me here: > https://wiki.tizen.org/wiki/Common > "Strictly speaking, Tizen:Common is not a "vertical" profile. It's the common > base for other profiles (IVI, Mobile and other forthcoming profiles)." > > Then here more detail: https://wiki.tizen.org/wiki/Common_Packages > Where I see "Common/Wayland" but no Common/X11.
DLF: If you look in that page in Display Architecture https://wiki.tizen.org/wiki/Common#Display_Architectures You will notice that X11 has always been planned but was not yet supported. We are now working to activate that support for the Mobile profile which has a dependency with X induced by a lot of their Apps. > > I appreciate it's a challenging task to adjudicate. But my mind wanders to > upcoming IOT, and wonder for example if such a device has no audio/display > behaviour, is Pulse so common, or even wayland/x11/xwalk itself? DLF: As you can see in the table previously pointed, support for devices with neither X nor Wayland is also in our long term objective. As you say it could very be that for IoT neither of these display technology are adequate and pulse might be an overkill. But so far with our current established profiles, that is more od a theoretical question. > > My fundamental question I guess is, what is the criteria for elevating > something into common or relegating it to profile specific? DLF: Far far it's pretty simple : - Common is what is used in all current profiles. https://wiki.tizen.org/wiki/Common_Packages Now the fact that the project is also called common can create some confusion because the project also includes some packages which cannot / donot need to be shared : - hardware adaptation layers (required to ru on a specific platform) - dev tools, test and demo tools (heavy link to the environment) - shared packages The later are packages that we keep their because they are used/or candidate to be used by multiple profiles or multiple architectures (elf, qt, oFono or more recently Dlnya). It allows to check that we offer a ready to go version of them to any profile who would wish to use them and allows us to reduce their maintenance cost while enabling them for all architecture in one go. > Secondly, what is the change control process for managing this transition > into or out of any components current allocation? The architecture group is in charge of the deciding what is common. Elevation from a profile specific to Common will generally start by a stage phase in the Shared group. That what is currently happening with Dlyna which is moving form ivi to Shared as we speak. Dominig _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
