[prev in list] [next in list] [prev in thread] [next in thread] 

List:       meego-dev
Subject:    Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and
From:       Carsten Munk <carsten () maemo ! org>
Date:       2011-10-04 12:24:36
Message-ID: CAK=iLrmgoCv+2myFEbmc2qGKX7YdncxcceVOVw5xkofa1G+1Hg () mail ! gmail ! com
[Download RAW message or body]

2011/10/4 karoliina.t.salminen@gmail.com <karoliina.t.salminen@gmail.com>:
> Hello,
> I think one of the things with the MeeGo was that it was a downgrade in
> development environment, CI systems and everything from our
> Maemo.
So, for good measure - those CI systems were never open source or
published outside the Maemo organisation. And couldn't be reused
properly for non-Debian based targets. New ones had to be developed.

> All that has been made for debian based distro and the change to the
> rpm does not make slightest sense. The debian based distro and everything
> that surrounds it has much longer history on this context and it is that
> simple. I joined the team that became later Maemo already in 2004. Back then
> scratchbox was new invention, but still today it has no replacement which
> would be better or equal. Before scratchbox we were compiling with ext hard
> drive connected to Nokia 770 proto (and ran the gcc on the arm). After
> scratchbox came, there was a great convenience improvement. Killing
> scratchbox without a replacement (OBS is not a replacement!) is not very
> good choice.

I will agree that there was a gap in development tools. It's easy to
start pointing fingers at where things went wrong and who was
responsible, but I won't. But the sad truth is that even with Maemo,
the full stack was uncompliable without internal access to Maemo
sources - it wasn't something to build a platform from.

As Kulve suggested, it is actually pretty easy to get a scratchbox
like chroot. One of the mistakes that MeeGo had was that, well, it
required Atom processors/SSSE3 to run simple development emulation
environments - which honestly, in big organisations was difficult to
find. This meant that practically, people couldn't run MeeGo in a VM
and develop straight on their typical development machine.

I stated my thoughts on build vs emulation in an old blog post of
mine: http://mer-project.blogspot.com/2009/08/debconf-thoughts-part-two-on-cross.html

In our original Mer project, it was possible to simply install the
entire development chain within a Mer for X86 virtual machine - and
develop directly on your PC for a system that works exactly as on
device and well-performing too. That was the piece of the puzzle that
didn't work with MeeGo.

Deep down, the packaging format doesn't matter. What matters is what
perspective things has been built with - a traditional desktop will
try to enable the kitchen sink of features. A mobile one enables those
it needs. Think of the Maemo process as cleaning out weeds in the
garden to make it fit in mobile settings.  Moblin and MeeGo was built
from scratch up for a specific mobile purpose - and even then they
managed to get crazy dependancies into the system.  And that's why I
like Moblin/MeeGo and their way of doing things - it's a lean and mean
Qt core.

> This is just my 0.02 cents. I would think it should be done like this:
> - Take the debian based distro and development environment (that works) as a
> basis. It works. Look at Harmattan and all previous Nokia Maemo devices.
I know it works and I also know how much difficulty (and years upon
years of manhours) people have gone through to mangle and modify the
Debian stack to the point it is in those mobile OS'es. I've even tried
to build things myself and realized pretty quickly why Maemo is
patched in head and tail where it is. But the fact is - that system
does not exist in open source. When inside a product organisation you
tend to loose perspective of what's open and what's not.

> - Number 2 key to the success is a blazingly superb UI. <snip> I think QML is a key to developing
> any UI concept fast whatever the Mer wants to be.
> - Number 3: Thou shalt not restrict it to one single technology. I think
> restricting to HTML5 only or QML only would be a bad idea. Instead a support
> of choices which work for different purposes is a key to success. Things
> which do not need to be replaced should not be replaced, they can be
> substituted, but not replaced.
And that's why it's a Core that seeks to perform well with
HTML5/QML/JS - anyone can do brilliant things with it. Want to run a
great UI on top? Be my guest!

BR
Carsten Munk

>
> On Mon, Oct 3, 2011 at 9:01 AM, Carsten Munk <carsten@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


[prev in list] [next in list] [prev in thread] [next in thread]