Views
Community Application Support
(Added my own self.) |
(why not close the loop? ===Links=== *discussion about above in forum: [http://forum.meego.com/showthread.php?t=135]) |
||
| Line 70: | Line 70: | ||
ETA for the servers is undefined. | ETA for the servers is undefined. | ||
| + | |||
| + | ===Links=== | ||
| + | *discussion about above in forum: [http://forum.meego.com/showthread.php?t=135] | ||
Revision as of 19:19, 19 May 2010
This project is about enabling the community to create open applications and share them through a channel that is hosted in meego.com.
Contents |
Current status (18.5.2010)
Waiting for hardware.
In the mean time David (lbt) and Niels (X-Fade) have set up an OBS instance in the old maemo.org hardware. This will speed up deployment once the hardware arrives for meego.com.
Scope of this work
This project is about community built open applications that would be shared through meego.com. The project outlines what services need to be set up for supporting application sharing through meego.com.
This work is not about platform development.
The technical parts of this project relate to the official MeeGo build and repositories so, that the community build and repository infrastructure load packages form the official side, but do not upload to them.
What is the community application support
The technical parts
- Web front end for developers to upload their applications to
Later there can be a direct 'upload to service' function in the MeeGo application development IDE.
- Build server (OBS server), needed for building the applications
- Repository server, for storing the applications and catering them to the end users
- The logic for running the build and repository servers
- End user clients, for the end users of MeeGo devices to get the applications with
- A web front end to the repository, so that the application lists can also be browsed on the net
- Automated quality assurance
The social side
- Quality assurance process, initially this most likely will be human testing, but automated tools would make it much faster and simpler
- The way to manage how applications flow to the final repository from the initial build repository - not everything goes to end users directly
- Managing the users - is it completely free for all anonymous users or is there some form of user management in place?
How to start
Things to do first in parallel:
- Get hardware
- Build the clients
- Practice setting up an OBS instance
- Agree on the web interface for the client
- Work out the QA rules
- Work out the security aspects
Things that need the hardware
- Setting up the real OBS instance
- Setting up the repository
- Setting up the management interfaces
People
- The people to implement all the above mentioned parts
Initially the following people are looking at this:
- David (lbt) - OBS and repository
- Niels (X-Fade) - OBS, repository, management tools
- Bob (bspencer) - client, web interface
- Daniel (danielwilms) - client, web interface
- Carsten (Stskeeps) - OBS
- Mike (mrshaver) - web back-end
- Tero (tekojo) - co-ordination
- Jeremiah Foster - observer of the process, considering both client implementation and / or OBS instances with repos for GENIVI
Servers for the system
Some servers have been ordered, and one of those can be used to get this work going. Additional hardware is being bought now, so that we have a sensible level of hardware to go on.
ETA for the servers is undefined.
Links
- discussion about above in forum: [1]