Carsten Hi, Your aims are why I was draw to MeeGo in the first place and its good to see you aiming even higher.
'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.' That's me so count me in. vgrade PS thanks for adding the Pi video link On Mon, Oct 3, 2011 at 7:01 AM, Carsten Munk <cars...@maemo.org> wrote: > 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-installments.html > [2] > http://monster.tspre.org:2080/project/packages?project=Mer%3ATrunk%3ABase > , http://monster.tspre.org/~prjfetcher/mer/README.txt , > http://monster.tspre.org/~prjfetcher/mer/releases/0.20110920.1/kickstarts/ > [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-example.html > [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@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines >
_______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
