User: Password:
|
|
Subscribe / Log in / New account

The return of the Mer project

From:  Carsten Munk <carsten-41UWDLvetLrYtjvyW6yDsg-AT-public.gmane.org>
To:  meego-dev <meego-dev-WXzIur8shnEAvxtiuMwx3w-AT-public.gmane.org>, meego-commits-WXzIur8shnEAvxtiuMwx3w-AT-public.gmane.org
Subject:  MeeGo Reconstructed - a plan of action and direction for MeeGo
Date:  Mon, 3 Oct 2011 08:01:17 +0200
Message-ID:  <CAK=iLr==_LKE7p3tyez55rtkvzi7LPTkYJtAJ_JkZ0Rs87ZXgw@mail.gmail.com>
Archive-link:  Article

Hi all,

MeeGo is dead ... long live Tizen !! - Haven't we heard that before? -
Maemo, Moblin?

We need a community that transcends the mere branding of MeeGo, Maemo,
Moblin - and now Tizen.

A lot of proposals have been put forward:
* Move to Tizen and trust that "They'll get it right this time"
* Merge or join some existing projects (like the Qt Project, Debian,
openSUSE, etc)
* Keep MeeGo alive by approaching the Linux Foundation

The goal is to find a truly sustainable way for MeeGo and other
interested communities to work with Tizen.

Our solution is the Mer Project:

How does the concept of a truly open and inclusive integration
community for devices sound? After all if "upstream is king" - then
contributions will end up the same place, no matter if it's Tizen,
Maemo, MeeGo or openSUSE.

Some history - many of us in MeeGo originated from a project called
Mer, short for Maemo Reconstructed - where we approached doing a open
mobile platform through reconstruction of the Maemo platform into a
open platform. We were big on open governance, open development and
open source.

For a few months a group of us have been working on various scenarios
of change in MeeGo [1] and now that the Tizen news is out in the open,
it's time to talk about what we as a community can make happen next.
To make it clear: this is not in any way an anti-Tizen or anti-Intel
project, but a direction we can and will go in - we strongly want to
collaborate with Tizen and Intel.

We will continue to welcome contribution and participation from the
hacker community - in fact we aim to make it so easy to port to a new
vendor device that a single hacker could do it for their device.

We decided to approach the problems and potential scenarios of change
in MeeGo in the light of the reallocation of resources caused by what
is now known as the Tizen work. There have not been any Trunk/1.3
releases since August and Tablet UX has totally stalled. What really
works (and works quite well) is the Core. It's time to take the pieces
and use them for reconstruction.

We have some clear goals:

* To be openly developed and openly governed as a meritocracy
* That primary customers of the platform are device vendors - not end-users.
* To provide a device manufacturer oriented structure, processes and
tools: make life easy for them
* To have a device oriented architecture
* To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5)
* To innovate in the mobile OS space

Now we'd like to talk a bit about what specific initiatives we propose to take:

0) Becoming MeeGo 2.0

Our work has the intended goal of being MeeGo 2.0 - and we hope that
the Linux Foundation will see our work as a worthy succesor within the
MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e.
supporting HTML5/WAC and the application story there and feed back to
that ecosystem.

1) Modularity. A set of architectural components for making devices.

Rather than dictate the architecture we will support collaboration and
the flexibility to easily access off-the-shelf components for device
projects. Component independence permits focused feature and delivery
management too.

Initially the project will be developing a Core for basing products on
and will split UX and hardware adaptations out into seperate projects
within the community surrounding the Core.

2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for
building products with.

We have already taken MeeGo and cut it into a set of 302 source
packages that can boot into a Qt UI along with standard MeeGo stack
pieces. This work can be seen already at [2] and we've made our first
release and have had it booting on devices already[6].

To ease maintenance, we would like to encourage people to participate
in the Core work of the Tizen project, utilizing their work where we
can in Mer: why do the same work twice? Even if Tizen turns out to be
dramatically different, the maintenance load of 302 source packages -
much of it typical Linux software, is significantly lower than that of
the 1400 packages found in MeeGo today.

Using another lesson learned from MeeGo, we also want to port this
work to everywhere, ARMv6/7 - hardfp, softfp, i486, Atom, MIPS, etc -
allowing much more freedom for porting to new devices.

3) Change governance towards a more technically oriented one, similar
to the Yocto Project

We'd like to propose a revamp of governance based upon the Yocto
Project governance - which is much more geared towards open technical
work - encouraging collaboration and discussion. You can look at a
description of this at [3].

4) Work towards better vendor relations and software to support these
as well as easier contribution methods.

As part of our "customer oriented" goal we're improving delivery
methods from Mer. We are designing simpler and more resilient update
mechanisms to support smaller and more distributed organisations
(think outsourcing too!). We want to encourage easy upstream
contribution and easy following and  patching of the MeeGo source tree
- even with local vendor patches.

5) Initial reference vendor - the Community Edition

To make our work focused, the Community Edition handset work[4] will
continue based on the Mer Core. It will act as a model of a reference
vendor [5] and will provide feedback into the project about delivery
methods and problems caused by changes.

We recognise that much needs to be done:
* Hosting and build systems
* Finances & Legal
but these are well understood (if not trivial) problems.

If you're interested, want to comment or participate - in both
community or commercial contexts - feel free to give feedback to this
mailing list post, or to #mer IRC channel on irc.freenode.net.

[1] http://mer-l-in.blogspot.com/2011/08/restructure-meego-by...
[2] http://monster.tspre.org:2080/project/packages?project=Me...
, http://monster.tspre.org/~prjfetcher/mer/README.txt ,
http://monster.tspre.org/~prjfetcher/mer/releases/0.20110...
[3] http://www.yoctoproject.org/about/governance
[4] http://wiki.meego.com/ARM/N900
[5] http://mer-l-in.blogspot.com/2011/08/meego-lead-by-exampl...
[6] http://www.youtube.com/embed/fouPJRLygNQ?hl

Best regards,
Carsten Munk
David Greaves
Robin Burchell
on behalf of the Mer Project
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev-WXzIur8shnEAvxtiuMwx3w@public.gmane.org
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines



(Log in to post comments)

The return of the Mer project

Posted Oct 3, 2011 16:01 UTC (Mon) by tajyrink (subscriber, #2750) [Link]

See also Jos Poortvliet's invitation to openSUSE and my invitation to Debian (and elsewhere) and overview. The main reason why these are needed is that MeeGo has many newcomers to the FOSS world, and we felt important that they are let known that in addition to Tizen, there are also other things one can do with the same people as during MeeGo. Especially since understandably, given how communication was (not) handled, all of the community aren't yet actually rejoicing about Tizen.

Mer may now be the obvious choice if we get it going, and of course Tizen itself as well when it becomes more tangible and the trust hopefully builds again. But as all of these are more or less intertwined, it doesn't make sense to get fixated on exactly one thing. The first information I've had on Tizen sounds like the reference distribution implementation there will be of lesser importance than the MeeGo reference implementation. Maybe one can actually make for example Debian flavor that is Tizen compliant? Or a tizen meta-package. At least that's what I'd hope for.

The return of the Mer project

Posted Oct 3, 2011 19:20 UTC (Mon) by oak (guest, #2786) [Link]

So the new "MeeGo" Mer is rpm (OBS etc) based whereas the old "Maemo" Mer was deb based?

The return of the Mer project

Posted Oct 4, 2011 6:24 UTC (Tue) by pabs (subscriber, #43278) [Link]

Correct. For those who would prefer deb there is always Debian:

http://losca.blogspot.com/2011/10/from-meego-to-tizen-deb...

The return of the Mer project

Posted Oct 3, 2011 20:17 UTC (Mon) by alogghe (subscriber, #6661) [Link]

Mer still seems to have libxml2 in it's core (I haven't found a recent package list)?

What's the value in maintaining a full distro?

Having watched it fail repeatedly in openmoko, maemo, and now meego I personally have little interest in any project that does this.

It's far more preferable as a user and a developer to simply login to a debian or ubuntu box and select "mer" as a ui flavor.

The return of the Mer project

Posted Oct 3, 2011 21:02 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

Mer is not an UI - those are Plasma Active or the MeeGo touch thing. Mer is meant to be a distro, like Debian, but specifically tailored to embedded devices.

The return of the Mer project

Posted Oct 3, 2011 21:07 UTC (Mon) by xxiao (guest, #9631) [Link]

really? rpm is floated for embedded devices to say the least.
sadly, OE(read Yocto/Intel) is also rpm-by-default nowadays. Intel is ruining things badly wherever it has anything to do with non-PC devices.

The return of the Mer project

Posted Oct 4, 2011 8:30 UTC (Tue) by aleXXX (subscriber, #2742) [Link]

What's the issue with rpm ?
It's basically an archiving file format, with more or less the same capabilities as deb, isn't it ?

Alex

The return of the Mer project

Posted Oct 4, 2011 9:30 UTC (Tue) by sebas (subscriber, #51660) [Link]

I think primarily, it's a religion, not an archiving / packaging format ;-)

That seems to be the root cause for the neverending deb vs. rpm debate (which totally misses the point, IMO).

The return of the Mer project

Posted Oct 4, 2011 12:04 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

The formats are probably much of a muchness, but the default tools for interactive RPM selection sent me reaching for the titanium sporks. (Whereas I always found dselect quite congenial, and its successor aptitude likewise.)

Is there a deb-based distro release using systemd as its default PID 1 yet?

The return of the Mer project

Posted Oct 4, 2011 12:30 UTC (Tue) by niner (subscriber, #26151) [Link]

I wonder what you mean by "default tools for interactive RPM selection"? Have you ever tried YaST?

The return of the Mer project

Posted Oct 4, 2011 12:41 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

Briefly. I've got a machine with OpenSUSE installed, but I don't actually use it. I seem to remember finding it significantly less congenial than aptitude or dselect.

The return of the Mer project

Posted Oct 4, 2011 13:35 UTC (Tue) by vonbrand (guest, #4458) [Link]

The alternative you aren't acustomed to use to the point that the fingers know how to do common tasks will seem a lot less congenial. Nothing very surprising there.

The return of the Mer project

Posted Oct 4, 2011 13:33 UTC (Tue) by vonbrand (guest, #4458) [Link]

At the root of all geek religious wars, be it vi vs emacs, BSD vs Linux, RPM vs deb, is that the alternatives fought over are different in details, but almost exactly the same in terms of functionality.

The return of the Mer project

Posted Oct 5, 2011 4:20 UTC (Wed) by k8to (subscriber, #15413) [Link]

It can get a bit silly, but some of the details can sort of matter.

As for the deb/rpm case, I'd say the formats and related tools have done some learning from each other, at least, which is useful.

But yeah the froth is probably eternal.

The return of the Mer project

Posted Oct 10, 2011 13:11 UTC (Mon) by BlueLightning (subscriber, #38978) [Link]

sadly, OE(read Yocto/Intel) is also rpm-by-default nowadays.

I'm sorry but this is untrue. OpenEmbedded-Core (the new basis for OE) is still configured for ipk packaging by default. The Yocto Project uses rpm by default but can be easily configured to use ipk. Whilst you may not understand it there is high demand for rpm amongst commercial embedded build system users and we have to cater for that.

That said, just because we support rpm, it does not mean that ipk is deprecated or that it will suffer. We treat any issue with ipk packaging as seriously as we would treat an equivalent issue with rpm. FWIW, for many of my development build setups I usually use ipk myself.

Maemo was based on .deb and GTK+

Posted Oct 4, 2011 12:49 UTC (Tue) by debacle (subscriber, #7114) [Link]

while Mer seems to base on .rpm and Qt, right? It's probably only a matter of taste, but I enjoyed my N770 and N800 back then.

Still, I wonder, whether there is still any need for a dedicated "embedded Linux distribution"? E.g. in my company we are producing an embedded device using standard Debian (not Emdebian), the "universal operating system". We looked at embedded distributions, such as Ångstrøm(?), but there is a huge advantage in using the same OS on our servers, some desktops, and the embedded device.

Maemo was based on .deb and GTK+

Posted Oct 6, 2011 6:47 UTC (Thu) by HBM (guest, #72284) [Link]

Well having the possibility to exactly reproduce the image is worth having
an own embedded distribution. Besides of that you might wan't to tweak your init stuff and you might be size constrained where the /var/lib/dpkg stuff hurts. I am using ptxdist where can choose between init,upstart or systemd.

Maemo was based on .deb and GTK+

Posted Oct 6, 2011 8:04 UTC (Thu) by debacle (subscriber, #7114) [Link]

That's what we do with Debian: We use upstart instead of sysvinit, removed some stuff we don't need on an embedded device, and we tweaked the system here and there. But it's still Debian (Squeeze). We're using a script that calls debootstrap and does some "cleanup" to create our installation image.


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds