Mer Blueprint New

m (Mer User Experience (UE))
m (Mer User Experience (UE))
Line 126: Line 126:
=== Mer User Experience (UE) ===
=== Mer User Experience (UE) ===
Initial thoughts on [[Memo_Reconstructed#User_Experience_Base|user experience]].
Initial thoughts on [[Maemo_Reconstructed#User_Experience_Base|user experience]].

Revision as of 02:16, 11 December 2008


Mer Project Blueprint

General Purpose

The Mer platform is a Linux distribution for mobile devices based on the Maemo platform from Nokia but developed solely by community effort. Mer goals include:

  • Improving and developing parts of Maemo that are of interest to the Maemo community.
  • Making it easier to port existing desktop applications by hildonizing and adjusting them to the tablet form factor.
  • Encouraging third party experimentation and development.
  • Supporting outdated tablet hardware no longer supported by Nokia.
  • Making Maemo a generic platform for all tablet devices, including non-Nokia ones.

Mer platform development will be done in the open, with public SCM repository, bugtrackers, and Wiki-based blueprint discussion.

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.

Collaboration infrastructure and requirements

  • Using We have a strong connection to 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<whatever>.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,<whatever>.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 for easy upstream notification of found bugs?
  • Wiki:

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.


In the beginning bootstrapping will be done by the initial interested participants.

Current most important tasks to get the wheels going:

  1. Establish teams and gather participants
  2. Mer Foundation team: Set up repository, decide on initial release codename. Decide on repository location and work with the hosters (, Work with on this one. Web-based assistant for package upload and upload rights (base on Admin of team projects?). Establish if we are just pinning, or taking in the packages we need from Ubuntu from stability? Or are we "just" pinning for the first alpha, and not pinning in next?
  3. Mer Architecture, Mer Extras & Developer Support: Hack Scratchbox 2 up to have a mapping like m-vo's, and a philosophy like the post. Look at the use of Xoo, possibly. - basically, get our basic cross-compilation SDK going. Work with to make a sbdmock builder for a sb2 sdk with a rootstrap of Mer (i386 & armel).


Maemo Community Council role

Responsibilities: General directions of Mer, upstream relations (Nokia, Ubuntu), community relations, decisions on what infrastructure to provide,

Bootstrap tasks:

  • Establish the general purpose of Mer, from perspective
  • Establish lines of communication towards upstreams and methods by which the Mer teams can use those.

Mer taskmasters/bridge/steering committee

Responsibilities: 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

Participants: Consists of the team leaders from each team. Bootstrap participants are the initial steering committee, and select initial team leaders amongst interested parties, and they manifest in the first steering committee.

Bootstrap tasks:

  • Establish Garage project and mailing lists
  • Establish short and long technical term goals of Mer.
  • Select initial team leaders amongst interested parties.

Mer Architecture

Initial thoughts on architecture for rescue and hardware support.


  • Kernel, initfs, modules, HW interfacing (open source drivers, binary blobs, etc)
  • Porting to new architectures/platforms/devices
  • Rescue capabilities for devices, and boot menu abilities - support alternative uses of the devices (Android, Gentoo, whatever.)
  • Maintaining the Mer imager, targets, builders
  • Maintaining relations with HW vendors/driver authors

Bootstrap tasks:

  • Establish garage project and mailing lists, and microblogging facility?
  • Import bzr branches of relevant stuff into git (imager, nit-bootmenu-compat, kernel modules, etc.)
  • Establish initial platforms to support: i386, 770, n8x0, n810w, beagleboard?
  • Establish reasonable method of licensing to redistributing HW binary blobs, from Nokia, in firmware images, and methods of future-proofing the contact and delivery of binary blobs in case of tool chain changes:
    • omap-nand, xloader, secondary (primarily for redistribution - FIASCO seems to support containing only kernel,initfs and rootfs. This way we can avoid messing up with corrupt images, and always allow flashing, but is this feasible since the existence of nokia-provided firmware images has to exist?)
    • bme (N800, maybe 770? are they similar?)
    • stlc45xx-cal / wlan-cal
    • retutime
    • usbflasher? is this in use?
    • wifi, bluetooth firmware
    • for previous kernel versions, umac.ko?
    • Note: this would have to be justified why this relicensing/redistribution is needed and what use the team will have of them in initfs.
  • Information about FIASCO image format from Nokia, possibly flasher, to be able to make firmware images for NITs.
  • Initial projects:
    • Kernel sub-project for Nokia Internet Tablets (both Diablo kernel and up-to-date).
    • Establish Mer initfs sub-project, kernel-agnostic, with kexec capability and rescue capabilities.
    • Support for rootfs-only setups on NITs using Diablo kernel+initfs (nit-bootmenu-compat) (mostly done)
    • Set up builder infrastructure (buildd?)
    • Establish common characteristics of devices, such as watchdog handling, verifying the system actually boots, preventing reboot loops.

Mer Foundation

Initial thoughts on foundation part. Changes are: Base upon Ubuntu jaunty, DSME, MCE is replaced by OHM (soon to be released by Nokia).


  • Userland, maintaining the pre-ui and under UI layer, connectivity daemons, power saving daemons.
  • Decides what is provided by mer foundation and what is installable through extras. Maintains repository and basic release engineering, and package upload facilities.
  • Decides upstream package integration into repository.
  • Maintain upstream compatibility (union of both Ubuntu and Maemo)
  • Work towards hardware agnosticism (OHM and friends may have hw-specific modules)


  • Establish garage project and mailing lists, and microblogging facility?
  • Import bzr branches of relevant stuff into git
  • Set up repository, establish contents of repository: Is it a pinning repository, with Ubuntu as upstream, or do we include debs and such from Ubuntu as we need them? Import mechanism? Look at infrastructure.
  • Establish upload facilities
  • Initial projects:
    • Establish what is considered part of the software base. Establish which things to import from Fremantle SDK of non-UI things and which patches to include.
    • Work on stripping down foundation: docpurge package, get dpkg-divert to play nice with it
    • Remove unneeded dependancies and figure out how we can do this in a sane manner cross-platform
    • Work on ways to make the distribution more suitable for mobile devices
    • Integrate OHM.
    • Work on libconic and connectivity daemons (this is a differentiation point - what can we do about this?)
    • Look at ke-recv's purpose in Mer
    • Upstream agreement regarding hald-addon-bme and redistribution.

Mer User Experience (UE)

Initial thoughts on user experience.


  • The user experience
  • Everything to deal with Xorg and above, that is, hildon, hildon applets, hildon libraries, etc, input method etc.
  • Main upstream compatibility (union of Ubuntu and Maemo)
  • Work towards hardware agnosticism (use HAL, OHM)
  • The look, feel and sound of Mer. Theming, icons, sounds.


  • Establish garage project and mailing lists, and microblogging facility?
  • Import bzr branches of relevant stuff into git
  • Choose which things we should integrate from Fremantle SDK dealing with UI
  • Powerlaunch as systemui?
  • Establish what base UI should be for Mer, which applications/applets/themes/etc should be included and ported.
  • Work out contribution guidelines for artwork.

Mer Extras and Developer Support

Initial thoughts:

SDK thoughts:


  • The developer experience
  • Working with applications from maemo-extras, porting, identifying Maemo-isms in applications, lack of libraries/support in Mer UE/Foundation
  • Developer relations (applications in maemo-extras)
  • The SDK (i386 cross-compilation, etc)


  • Garage project and mailing list
  • Start trying to port applications from maemo-extras, point out problems in porting, report to Mer UE/Foundation so they can include the needed features/libraries
  • Establish if we need a mer-extras repository?
  • Hack Scratchbox 2 up to have a mapping like m-vo's, and a philosophy like the post. Look at the use of Xoo, possibly.
  • Project about emulating Mer on emulators, and how to ease development for developers (scripts to help putting on real devices, etc)

Mer Translations



  • Establish garage project, mailing list, git repository, procedures
  • Import current l10n packages
  • Establish possible target languages for l10n

Mer Testing


  • Testing of everything and reporting to the different teams.
  • Release testing/QA.


  • Garage project, mailing list, team relations, wiki