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. 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.
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. And there is scratchbox, which is open source, and even if it would not be perfect, it works and is great for developing and cross compiling anything on your machine, not needing some OBS build service to build your package when you can compile on your computer. So forget RPM, is number 1 key to the success. And even if the intended hardware would be something else than ARM, it does not matter. This is my recommendation. Do whatever you want, but I think this would be the right thing to do at this point. - Number 2 key to the success is a blazingly superb UI. And this is not even very hard one but takes some work. Community MeeGo has not had a meaningful UI, has always had poor graphics (or missing graphics on Nokia's code drops, e.g. seeing our duicontrolpanel on MeeGo-MeeGo installation instead of Harmattan is a whole different experience than seeing it on Harmattan device), poor or missing icons and does not really shine in any way when compared to iOS, Android or Harmattan. But good news, there is a easy technology to make a superb UI framework rapidly, QML. It needs some work, needs to be consistent UI concept, excellent graphics (which have a meaning, if you look closely icons on Harmattan and the colors of applications, they are different from app to app because the apps are "color coded" - this kind of attention does matter). But QML is really awesome for creating things fast and the QML based swipe tutorial on Harmattan (when you boot your N9 first time) shows that it can be done with QML (as the swipe tutorial simulates the Harmattan UI framework). 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. - Many of the lower layers have been already open sourced by companies and it is just about utilizing them and doing the top of the cake right. There are some missing pieces, but filling the gaps should not be impossible. It is some work to do, but it may not be overwhelmingly big work. With some gaps filled on UI, and then lower layers, this distro could be easily superior to e.g. Android. It is another question if someone wants to use it, but at least would be a fun thing. Best Regards, Karoliina On Mon, Oct 3, 2011 at 9: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
