Revision as of 14:37, 27 January 2011

Goal: Design and document the Surrounds and Extras areas for MeeGo

Apps - the area formerly known as "Extras"

Borrowing Andrew Flegg (Jaffa)'s mission statement for MeeGo Community Apps: we need to ensure a vibrant and quality area for community open source software.

So MeeGo Apps is the community app store and follows on from the successful Maemo Extras.

This should allow app developers to build MeeGo compliant (and other) apps and distribute them to users.

What makes Apps different from a 'random repository' is the community QA process that is applied; the objective of this QA process is to permit users to trust the apps and to deliver a collection of apps that a commercial vendor could enable on a shipping device (as Nokia did with 'Maemo Extras' on the N900).

Clearly then, there needs to be some processes (and automation) to define how QA checks are carried out and what to do when certain events occur. We already have a process automation system (called BOSS - it's is being developed by Nokia and is essentially an integration of various OSS libraries) - now we need to decide what processes and criteria we use to manage and promote apps. Initially I suggest we start with the Maemo Extras process and refine that.

When we talk about process we are also talking about policy. I've discussed this below and quite a few of the points apply to Apps.

Targets

Now, it's not yet clear what OBS targets Apps should build against. Currently we have:

• MeeGo:1.1:Core
• MeeGo:1.1:Core:Handset
• MeeGo:1.1:Core:IVI
• MeeGo:1.1:Core:Netbook

These correspond to the MeeGo Core and then a number of UXes. However there are plans to consolidate them in the main MeeGo OBS - but how should the Apps area look? Should a handset user be presented with apps which were only intended to run on a netbook? OTOH is this anything to do with the repo and build target - should it be determined by metadata and selectively presented by the download application?

Well, until this is resolved, an app developer simply needs to enable each target that the app supports to make it available in that repository.

I think the discussion up to this point is fairly simple and uncontentious; we can start to address the issues mentioned and just get on with it and start to deliver MeeGo Apps :)

However, as mentioned, the Apps area allows both MeeGo-compliant and MeeGo-extra applications. MeeGo-compliant apps are those which only use libraries in MeeGo core/UX; MeeGo-extra apps have a little extra open-source goodness sprinkled in... Surrounds.

See also the not-so-updated Community Application Support - please complement both pages appropriately.--Qgil 16:23, 14 January 2011 (UTC)

Members

• Lbt
• xfade