(Add policy) |
(Add link to thoughs on community OBS.) |
||
| Line 27: | Line 27: | ||
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. | 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. | ||
| + | ===Community OBS=== | ||
| + | The origin for all community apps is the community OBS. Thoughts on [[Community_Office/Task_Forces/MeeGo_Surrounds_and_Extras/Community_OBS|community OBS structure, teams and PPAs]] | ||
===Targets=== | ===Targets=== | ||
Now, it's not yet clear what OBS targets Apps should build against. Currently [https://build.pub.meego.com/project/list_public we have]: | Now, it's not yet clear what OBS targets Apps should build against. Currently [https://build.pub.meego.com/project/list_public we have]: | ||
Goal: Design and document the Surrounds and Extras areas for MeeGo
Contents |
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.
The origin for all community apps is the community OBS. Thoughts on community OBS structure, teams and PPAs
Now, it's not yet clear what OBS targets Apps should build against. Currently we have:
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.
To get promotion and maintenance processes going we need to define policies for:
See also the not-so-updated Community Application Support - please complement both pages appropriately.--Qgil 16:23, 14 January 2011 (UTC)