Note: This is a DRAFT update on compliance for the 18 August 2010 TSG meeting. This is not a final policy. Mark Skarpness is leading this discussion.
Contents |
This is an update on the compliance approach for MeeGo and the plans specifically related to the MeeGo 1.1 release.
The main motivation and goal for MeeGo compliance is strong specification and enforcement of application compatibility between MeeGo products and releases. Simply put, we want to make it possible for an application developer to write a MeeGo compliant application once and run it on any MeeGo compliant device.
MeeGo compliance addresses two categories of compliance: MeeGo compliant applications and MeeGo compliant devices / software products (which will be referred to simply as "devices"). In both cases, the use of the MeeGo brand will be granted based on being compliant. Following is an overview of the approach for each of these.
For MeeGo compliant devices, we're taking a stack-based compliance approach, meaning that all MeeGo devices must use the same core software stack. Referring to the MeeGo architecture diagram, this core software stack is the MeeGo OS base layer plus the MeeGo OS Middleware layer.
In addition to a sharing the same core software stack, MeeGo compliance will have profiles for each device category (Netbook, Handset, In-Vehicle, and so on). A profile specifies additional required components for the profile (e.g. providing device category APIs), minimum hardware requirements and minimum hardware component requirements (such as cellular modem in the handset profile).
It's important to note that the device profiles won't require the inclusion of a complete user experience - but rather the UI framework providing core user interaction and APIs.
A MeeGo compliant device would be compliant to the MeeGo core software stack definition and one (or more) device category profiles.
Given that definition of compliance for devices / software products, MeeGo compliance for applications will verify that an application's external dependencies are satisfied by a MeeGo compliant device (in other words, that any libraries or other dependencies of the application are provided within the core software stack and target device profile)
An application can be written to be dependent only on the MeeGo core software stack - in which case it would run on any MeeGo compliant device. However, applications with UI would typically target a specific device profile - so for example an application could be MeeGo Handset Compliant - meaning that it would run on any device compliant with the MeeGo Handset profile.
Stack-based compliance means that a compliant device / software product must use the MeeGo package set without re-packaging - including the MeeGo version of RPM and the MeeGo package names.
Compliance requires the use of the MeeGo source packages for required components, and that any applied patches (e.g. to fix bugs found in the field) must not effect API, ABI, or defined functionality of interfaces.
Additional packages (beyond those required by compliance) may be added as long as they don't override MeeGo packages or provide functions with the same namespace of MeeGo APIs. Of course there will also be additional packages and components required to adapt MeeGo to run on a specific hardware platform (we call this "Hardware Adaptation Software" in MeeGo) - the compliance specification will call out any specific packages or components that may vary based on hardware capabilities.
The full details of the compliance requirements will be provided in a MeeGo compliance specification and tools will be provided to verify both device and application compliance.
For 1.1, our plan is to have the first draft of the compliance specification published by the end of August, first versions of the application and device compliance tools available by the end of September, and final versions of the 1.1 specification and the tools ready along with the 1.1 project release at the end of October.