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
Posted Oct 3, 2011 16:01 UTC (Mon)
by tajyrink (subscriber, #2750)
[Link]
Posted Oct 3, 2011 19:20 UTC (Mon)
by oak (guest, #2786)
[Link] (1 responses)
Posted Oct 4, 2011 6:24 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
http://losca.blogspot.com/2011/10/from-meego-to-tizen-deb...
Posted Oct 3, 2011 20:17 UTC (Mon)
by alogghe (subscriber, #6661)
[Link] (11 responses)
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.
Posted Oct 3, 2011 21:02 UTC (Mon)
by jospoortvliet (guest, #33164)
[Link] (10 responses)
Posted Oct 3, 2011 21:07 UTC (Mon)
by xxiao (guest, #9631)
[Link] (9 responses)
Posted Oct 4, 2011 8:30 UTC (Tue)
by aleXXX (subscriber, #2742)
[Link] (7 responses)
Alex
Posted Oct 4, 2011 9:30 UTC (Tue)
by sebas (guest, #51660)
[Link] (6 responses)
That seems to be the root cause for the neverending deb vs. rpm debate (which totally misses the point, IMO).
Posted Oct 4, 2011 12:04 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (3 responses)
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?
Posted Oct 4, 2011 12:30 UTC (Tue)
by niner (subscriber, #26151)
[Link] (2 responses)
Posted Oct 4, 2011 12:41 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Oct 4, 2011 13:35 UTC (Tue)
by vonbrand (subscriber, #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.
Posted Oct 4, 2011 13:33 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (1 responses)
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.
Posted Oct 5, 2011 4:20 UTC (Wed)
by k8to (guest, #15413)
[Link]
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.
Posted Oct 10, 2011 13:11 UTC (Mon)
by BlueLightning (subscriber, #38978)
[Link]
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.
Posted Oct 4, 2011 12:49 UTC (Tue)
by debacle (subscriber, #7114)
[Link] (2 responses)
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.
Posted Oct 6, 2011 6:47 UTC (Thu)
by HBM (guest, #72284)
[Link] (1 responses)
Posted Oct 6, 2011 8:04 UTC (Thu)
by debacle (subscriber, #7114)
[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.The return of the Mer project
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
The return of the Mer project
The return of the Mer project
The return of the Mer project
The return of the Mer project
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
It's basically an archiving file format, with more or less the same capabilities as deb, isn't it ?
The return of the Mer project
The return of the Mer project
The return of the Mer project
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
The return of the Mer project
The return of the Mer project
The return of the Mer project
sadly, OE(read Yocto/Intel) is also rpm-by-default nowadays.
The return of the Mer project
Maemo was based on .deb and GTK+
Maemo was based on .deb and GTK+
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+