Mer

Line 72: Line 72:
* NTP synchronization
* NTP synchronization
* .. others
* .. others
 +
 +
== Appendixes ==
 +
 +
=== Guidelines for branching Maemo packages ===
 +
 +
'''For packages on https://stage.maemo.org/viewcvs.cgi/projects/?root=maemo'''
 +
 +
* Rule: When we are branching Maemo packages, we branch the tags (released packages). We have to respect the author's choice to release when they think the package is stable enough for release and not follow trunk unless it is absolutely needed (and justified in changelog)
 +
* There might be certain exceptions in repository pre this rule was made, but this should stable out eventually
 +
* Get bzr, bzr-svn, and run: '''bzr svn-branching-scheme --set https://stage.maemo.org/svn/maemo''' and insert:
 +
{{
 +
projects/connectivity/*/tags/*
 +
projects/connectivity/*/trunk
 +
projects/connectivity/*/branches/*
 +
projects/email/*/tags/*
 +
projects/email/*/trunk
 +
projects/email/*/branches/*
 +
projects/haf/trunk/*
 +
projects/haf/tags/*/*
 +
projects/haf/branches/*/*
 +
}}
 +
 +
To branch a Maemo package, example, https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo0/
 +
 +
{{
 +
$ bzr branch https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo0/ epeg
 +
$ cd epeg
 +
$ cat debian/control # What is the source package called? SOURCE from now on.
 +
$ bzr push lp:~LAUNCHPADUSERNAME/m-r/SOURCE
 +
}}
 +
 +
So, a new version comes out of epeg, https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo1/
 +
 +
{{
 +
$ bzr merge https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo1/
 +
$ bzr commit -m "merged upstream changes from 0.9.0.005maemo1"
 +
$ bzr push # upload changes to launchpad
 +
}}

Revision as of 20:53, 27 November 2008

"Mer" is an experimental project, where an attempt of "reconstructing" the Maemo platform is done, based on the proposal on Maemo_Reconstructed. Mer means ocean in French, "more" in Danish, etc..

Contents

Roadmap

Iteration 1 (done)

Idea: Build as much of Maemo trunk we can, adapt to Ubuntu, chaos coding, microdocument through Jaiku, and make it work and run. Name was M-R PoC.

Results: 123MB flash for minimal Ubuntu base system, Xorg omapfb driver, tslib Hildon on top. Possible to do things like:

A choice was made to restart and do things by the book. We originally based on Mojo Handhelds Ubuntu port to ARM.

Iteration 2: Mer Alpha

Mer: Provide a experimental system for Maemo community use, as a playground to try out new technologies and ideas on. Give community a voice in system architecture and continued development of the Maemo platform post Fremantle. Give the community ability to give documented, researched input to the development process of Maemo. Mer should be cross-platform, both for i386, armel, and not rely on running on specific devices.

Upstream distribution: Ubuntu 'Jaunty' for ARM and i386. Experiment with VFP/optimized versions (use of hwcap) for libraries that would benefit from it. Maemo trunk.

Development process: Use of Launchpad. Everything must be done in bzr branches and published in the m-r project on Launchpad. Use of builders, which only accepts bzr branches and source packages and are primary uploaders to repository. Packages must compile in both i386 and armel ideally.

Microdocumentation is still done in Jaiku.

Repository: http://trac.tspre.org/mer/jaunty as primary repository. Mirrors should be added.

Phase 1: Infrastructure setup

  • Set up launchpad.net project (done).
  • Set up APT repository (done)
  • Set up i386 and armel builders (qemu and or beagleboard), which relies on clean buildd chroots (done)

Builder works by first attempting to generate a source package from a bzr branch (after getting build dependancies) in a buildd chroot, to make sure the packages are sane. Then it builds i386 and lets this do the binary i386 and binary indep packages. Then it lets the armel builder(s) do their job on compiling the package. This way we have an early warning if a package does not compile at all instead of wasting hours on waiting for armel builder to fail.

Phase 2: Establishing base system

  • Create bzr branches for Maemo trunk packages and push them to launchpad.
  • Compile these for i386, armel (first glib, then gtk, then .. ending with a full hildon desktop, python-desktop), and builder will upload to repository.
  • Establish which dependancies applications targetting the Maemo platform, use, that are not OSS or dbus wrappers. What are the portability problems of the Maemo platform.
  • Establish system architecture and abstractions (DSME, MCE, HAL, OHM, etc), must take into consideration the cross-platform nature of Mer.
  • Establish where Mer begins and where it ends in terms of what does the generic platform include, and which is platform-specific / vendor-specific.
  • Establish what constitutes stable packages for inclusion into beta/testing
  • Establish what our relation to Maemo is, - Maemo council as governing body?
  • Establish how Maemo packages conflict with desktop elements of upstream. (libgnomevfs, maemo GTK), and how these can work together.
  • Establish how close we are to being like Maemo, by trying to build packages from Extras (mer-extras?)
  • Work on image builders for the following targets:
    • N8x0 tar.gz (compat with N8x0 bootmenu-svn initfs), fully open source
    • N8x0 tar.gz (compat with N8x0 bootmenu-svn initfs), with value adders such as wifi/bluetooth firmware drivers, hald-addon-bme, gps driver, adobe flash, .. other apps, to show the ability of differentation
    • N8x0 jffs2 rootfs (for QEMU-N8x0 emulation)
    • BeagleBoard jffs2 rootfs
    • i386 tar.gz (targeting Intel D945GCLF2 board)
    • 770 tar.gz (compact with bootmenu-svn initfs), installable on RS-MMC.

Phase 3a: User interface

  • Theming (Plankton is one theme, but what other exists that are redistributable)
  • Icon sets (open license, redistributable)
  • Control panels
  • Translations?
  • Systemui (normally seen when charging, or when pressing power button, or when you're locking your screen). Powerlaunch will be used for this.
  • Experimental interactions? TV screen and wiimote?
  • Tech demos: Mer on Beagleboard, netbook, ASUS Eee Top (touch?), N8x0, 770, Pandora, Zaurus, x86+TV screen

Phase 3b: Experimental system use

  • Rescue menu & bootmenu
  • Clone-to-SD
  • Unionfs use
  • USB networking, Bluetooth PAN
  • NTP synchronization
  • .. others

Appendixes

Guidelines for branching Maemo packages

For packages on https://stage.maemo.org/viewcvs.cgi/projects/?root=maemo

  • Rule: When we are branching Maemo packages, we branch the tags (released packages). We have to respect the author's choice to release when they think the package is stable enough for release and not follow trunk unless it is absolutely needed (and justified in changelog)
  • There might be certain exceptions in repository pre this rule was made, but this should stable out eventually
  • Get bzr, bzr-svn, and run: bzr svn-branching-scheme --set https://stage.maemo.org/svn/maemo and insert:

{{ projects/connectivity/*/tags/* projects/connectivity/*/trunk projects/connectivity/*/branches/* projects/email/*/tags/* projects/email/*/trunk projects/email/*/branches/* projects/haf/trunk/* projects/haf/tags/*/* projects/haf/branches/*/* }}

To branch a Maemo package, example, https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo0/

{{ $ bzr branch https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo0/ epeg $ cd epeg $ cat debian/control # What is the source package called? SOURCE from now on. $ bzr push lp:~LAUNCHPADUSERNAME/m-r/SOURCE }}

So, a new version comes out of epeg, https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo1/

{{ $ bzr merge https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo1/ $ bzr commit -m "merged upstream changes from 0.9.0.005maemo1" $ bzr push # upload changes to launchpad }}

Retrieved from "http://wiki.maemo.org/Mer"