Mer Blueprint New

= Mer Project Blueprint =

General Purpose
The purpose of Mer is to make Maemo a general platform for tablet devices (including Nokia devices), to make it more developer-friendly, and to bring it into alignment with standard Linux distributions. It is also within the philosophy that the platform should be "hackable", a main selling point with open-source friendly hardware.

We should stop seeing the tablets as strictly under-powered embedded systems, and see them for what they really are—powerful, power-efficient, economical handheld computers. Not simply hopped-up electronic calendars, but real computers that are capable of almost as much computing as a laptop.

Development of the Mer platform (non-device-specific and non-vendor-specfic differentiation) should be done in the open, with public SCM, bugtrackers and blueprints. This way, developers can adjust their applications to later 'stable' releases and know what is coming regarding the API.

One of the goals of the Mer platform is that it should be easy to port an existing desktop application by hildonizing it and adjusting to the form factor of a tablet, without having to deal with platform particularities like what features the busybox version of a tool uses or other factors. A secondary goal is to have a platform that is flexible enough to encourage experimentation and development for tablets.

Collaboration infrastructure and requirements

 * Using garage.maemo.org. We have a strong connection to maemo.org, so, and many users and potential contributors are already registered with the services.
 * Advantages of garage: mailing lists per project, bug tracking, news, file releases, forums, svn, git (upcoming)
 * Each team and sub-team should have a garage project. Each garage project should be able to make git.maemo.org/projectname/ .git - where they host their master/release tags/etc of the areas they are responsible for.
 * Each user should be able to have their own personal git repositories, for example, git.maemo.org/~username/ .git. This will make it possible to branch existing git trees, and host them on garage, and lower the entry level for contributing to Mer. Similar possibilites can be seen on launchpad. Also has the advantage of making each team able to merge the changes from the user, even if he/she vanishes, and encourage development in the open.
 * Using bugzilla.maemo.org for easy upstream notification of found bugs?
 * Wiki: wiki.maemo.org

Development method
Each team should work through SCRUM Maemo.org_Sprints, - since the teams are spread over several timezones, daily reporting should consist of microblogging?, - maybe a way to automatize the reporting in % through scripts and established form of the microblogging items. Meeting-less cos of several timezones?

Each team should have a team master which is responsible for the area, and selects gatekeepers for the git repositories, who in turn selects commits to be merged from (if in development). Everyone should be able to join the team, and commit to items in the sprint, but not everyone has commit rights for the git repositories at first, and should push their updates from their personal repos/branches to the gatekeepers.

maemo.org council role
General directions of Mer, upstream relations (Nokia, Ubuntu), community relations

Mer taskmasters/bridge/committee
Consists of the team leaders from each team. Establishes specific short and long term goals of Mer based on the general directions of Mer from council. They meet regularly and decide on the high level goals of each team and release planning.