Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, On 10/04/2011 03:08 PM, ext Tom Swindell wrote: OBS is built with packaging in mind, so it builds packages locally and on servers in a sanitized environment. Scratchbox may be polluted by whatever packages a developer has installed and makes dependency tracking a bit harder IMO. OBS and Scratchbox aren't competitors or replacements for each other. OBS is a package building tool, Scratchbox is a cross-building tool for distros. I.e. their main focus is completely different. As to cross-building in OBS, I would recommend it to adopt SB2 as what I've understood of its current cross-compilation solution looks like an incomplete re-implementation of SB1 i.e. either much slower or causing much more issues with builds. Btw. Despite name, scratchbox v1 and v2 don't have about anything else in common except the problem they solve, distro cross-building. SB1 problem is that its host tools are basically a hard to maintain distro in itself and therefore typically out of sync with the target packages, which sometimes cases issues. Whereas SB2 is designed just to use x86 version of the packages to speed up build of non-x86 packages, and have fine-grained control on how all this works. - Eero Here's some more info on SB2: https://maemo.gitorious.org/scratchbox2 http://packages.debian.org/wheezy/scratchbox2 http://lists.scratchbox.org/pipermail/scratchbox-users/ ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, On 10/04/2011 12:06 PM, ext Jon Nordby wrote: Yes, one would want Scratchbox or similar in addition to what OBS provides. However, there is nothing that prevents Scratchbox from being used together with RPM and an RPM based distro is there? You need some support for RPM tools in SB and OBS would need to prefix commands with sbox or sb2 depending on which SB version is used. Don't go around trying to changing everything if what you're missing is just Scratchbox. I wouldn't say just, distro cross-building is surprisingly hairy problem, it can sprout warts years after you thought it was nailed down. Anyway, SB is package build system agnostic. I would recommend using SB v2. With that you just need to select suitable packages from the distro to accelerate and adding path mapping rules for binaries in them, whereas with SB v1 you need to support SB specific host tools distro in addition to package management devkit. - Eero ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi to all, I'm only a lurker of Meego mailing lists and I have never contributed to the project, but this time I would like to write some words about. * That primary customers of the platform are device vendors - not end-users. I think that this point in Mer Project or in any other branch/fork of Meego is to be corrected. Vendors come and vendors go, they don't care about Community as long as they can use it for their purposes and for me this was the main problem with Maemo, Moblin, Meego and if their strategies change they drop their products and their Communities. This approach didn't work. We have to reach a critical mass of users as soon as we can, then vendors will return to Community using Community work for their projects. I think we have to focus on end-users, we have to get users as fast as we can, and then they will be new testers and other developers come to help these users, Community is not a vendor that fears to burn its new brand with an early release. We have to learn from other successful opensource projects. Firstly we have to hack the most common devices on the market, users unsatisfied with their platform would like to try a different one without buying a new device. Then we have to get their feedbacks and trying to improve. We have to define specific requirements an user would search on this new platform, we have to define our target users and build a solution for the most of them. When we will have users, vendors will come to produce using our work for their new devices. These are my 2 cents, sorry for bothering. Best Regards, d4lamar ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
2011/10/6 d4lamar d4la...@gmail.com: * That primary customers of the platform are device vendors - not end-users. I think that this point in Mer Project or in any other branch/fork of Meego is to be corrected. Vendors come and vendors go, they don't care about Community as long as they can use it for their purposes and for me this was the main problem with Maemo, Moblin, Meego and if their strategies change they drop their products and their Communities. So, let me describe a bit what I mean with vendor. What we're trying to establish is a common, streamlined Linux/Qt core for others to build on top of. For end users, this is horribly boring - the code on it's own would just show a blinking cursor/a xterm/a qml demo A vendor, in our view, is someone who takes the core, mixes it with their own bits, makes it into some kind of a product. As an example, this could be Plasma Active user experience, taking the core, some hardware adaptations and their own UX. It could be a small business that makes bus displays. It could be a hobbyist at home who doesn't want to bother making his own distribution and just want to show a clock on his LCD. But we're not the people who deliver the final experience. In their work, they'll come up with improvements to the core and proposed requirements for the core. With a proper, openly governed and discussed requirements/roadmap process, we move ahead while maintaining quality and focus. I'll expect those handling the requirements management to be objective in their work. My primary motivation about the not end users is the fact that this practically ruined MeeGo, the personality split between just a core and look, shiny netbook ui - the core was actually fantastic for building things with, but the reference UX'es and end user's reviews caused it to be perceived badly. Instead, I'd like to see the amazing things people can build on top. So many possibilities, really (just go look at the videos of what people did with the MeeGo + Nokia N900 hardware adaptations) We have chosen to move out the hardware adaptations and UX'es out of the core, into the community surrounding it, to get rid of a lot of politics - to concentrate on what's technically good and benefits us all - not having to maintain our own mobile distribution ourselves. These are my 2 cents, sorry for bothering. An opinion isn't bothering :) BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Thursday 06 October 2011 07:33:24 Carsten Munk wrote: We have chosen to move out the hardware adaptations and UX'es out of the core, into the community surrounding it, to get rid of a lot of politics - to concentrate on what's technically good and benefits us all - not having to maintain our own mobile distribution ourselves. I think I understand your point but there is a big danger there. My day job is marketing. And there is a lot of marketing involved in building an open- source community. In order to get contributors, or to get vendors to use you, you need to be seen as viable and successful. And a lot of that is tied up with end-users: the blogs and web sites will be talking about you if users are talking about you. Your strategy is going to require that you have a successful and visible vendor project and, even then, you need to make sure that people are mentioning your core when talking about the associated project. My personal view (which is partly based on my marketing job) is that you have to start off focused on a very visible end user experience in order to get the project the necessary publicity. For your own governance reasons you will probably want to make sure the split between core and vendor is clear, but from the outside world they have to look like one to start with. The bottom line is that many potential community members will be doubtful that your project can be successful, unless you can show them a working (preferably great) end user experience (including hardware). Many projects have been and gone, either sponsored by big companies (we are all familiar with those!) or purely hobbyist (e.g. Cordia now that the Cordia Tab seems dead). If the Cordia Tab was going to happen then Cordia might have been the viable end user project to get you the publicity but without hardware it seems to be going nowhere as well. Graham ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Thu, Oct 6, 2011 at 12:40 PM, Graham Cobb g+me...@cobb.uk.net wrote: My personal view (which is partly based on my marketing job) is that you have to start off focused on a very visible end user experience in order to get the project the necessary publicity. For your own governance reasons you will Yeah, people need something cool on their devices to bother trying Mer in the first place, provide feedback and maybe even join the project. I'm sort of hoping Plasma Active could play a big part in this. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, sorry for re-sending this Jeremiah, but I've missed that this mail was not sent to the list, my bad. 2011/10/4 Jeremiah Foster jeremiah.fos...@pelagicore.com: ... Can a mobile segment distro like MeeGo be really compared with a desktop segment distro like e.g. embedded Ubuntu? (This is not relative to your message but a general rhetorical question.) I don't understand what you mean by segment here. And I also don't understand what you're referring to with embedded Ubuntu. What I meant is that a embedded desktop OS targets another audience than the embedded mobile OS (or in other terms a different market segment). Well I'm sorry for using the term embedded Ubuntu, I've assumed that others refer to projects like Linaro-Ubuntu [1], the TI-OMAP Ubuntu [2] and in general ARM Ubuntu as embedded Ubuntu too. Well I didn't use embedded Debian as example because Emdebian mailing lilsts seem to be pretty dead [2]. Embedian is very much alive. More here: http://www.debian.org/News/weekly/2011/12/#emdebian Oh I see, I just wondered because the mailing lists seems to endure a recession. Before it was just big companies that could create their own Linux distros (before that everyone had their bespoke UNIX distro) nowadays fragmentation is brought to you by every Tom, Dick and Harry with an OBS login. I've been down the fragmentation road before. It always ends with retracing your path back to the main highway. There seems to be much standardization work going on in the Yocto Project / OpenEmbedded Core (see [3], also Carsten already mentioned the Yocto Project in context of governance), anyone evaluated it? Yocto is very interesting indeed, as is OpenEmbedded, though the claim is that Yocto is open embedded done right. But for the purposes of a distro I don't think Yocto is the silver bullet people are looking for. Firstly, it seems focused on Intel Atom BSPs and overall seems designed to help in board bring-up. Yes you can create a complete distro, but like a misused OBS repository, creating your own complete distro is not a good idea. Unless of course yours is THE ONE. Your statement about Yocto is right, but OpenEmbedded isn't OpenEmbedded anymore, alot has changed since this statement was true. OpenEmbedded Core (the new OpenEmbedded) and the Yocto Project merged their efforts and created an unified code base (see [3] and [4]), also OpenEmbedded Core + Yocto supports a larger audience (see [5] for the approved list of BSP layers). In OSS systems there should not be a THE ONE distribution, for end users this is out of the question, they might not want to create their own distro, but (IMHO) developers should not be restricted in this direction. The Yocto Project / OpenEmbedded was discussed before in the IVI mailing list (see [4]), but it lacks any technical explanations and arguments why it cannot be used / or get adapted, also OpenEmbedded progressed into the new OpenEmbedded Core Project (the next release is just one step away). https://wiki.yoctoproject.org/wiki/FAQ OpenEmbedded is widely used in commercial embedded systems. Those systems tend to not be open source systems and end up costing lots of money. Regards, Jeremiah Sorry I don't get your point here, no offense but if I would say: Debian is widely used in commercial desktop systems. Would your statement be the same? If you care about the patches, i see quite an amount of users sending patches back to OpenEmbedded Core and Yocto. [1] https://launchpad.net/linaro-ubuntu/+milestone/11.09 [2] https://launchpad.net/ubuntu/+source/linux-ti-omap [3] http://www.linuxfoundation.org/news-media/announcements/2011/03/yocto-project-aligns-technology-openembedded-and-gains-corporate-co [4] http://www.yoctoproject.org/projects/openembedded-core [5] http://www.openembedded.org/wiki/LayerIndex -- Regards Samuel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Wed, Oct 5, 2011 at 10:09 AM, Stefan Werden stefan.wer...@open-slx.dewrote: Jeremiah Foster jeremiah.fos...@pelagicore.com hat am 4. Oktober 2011 um 20:42 geschrieben: On Tue, Oct 4, 2011 at 6:48 PM, Stefan Werden stefan.wer...@open-slx.dewrote: Hi, switching to debian would mean making a complete new projekt. Nope, it would merely mean adding software to the Debian project, it wouldn't require a new project at all. Debian would host the infrastructure (it has its own IRC, build farm, hosting, project software, email lists, funding, non-profit status, social contract, shell accounts, git server, svn server, well, you get the picture.) You could turn Mer into a Debian blend for example: http://wiki.debian.org/DebianPureBlends or you could become a Debian derivative: http://wiki.debian.org/Derivatives/Census Debian derivatives currently dominate the Linux landscape. Of the top four distros on Distro Watch, three of them are deb based. This means you get a huge development ecosystem when you use debs, as well as a lot of users. Distrowatch are server and dektop disties. The special thing in MeeGo was that the focus was on emerging devices. And how exactly did it do that? By using Connman? By using an embedded Linux kernel? Btrfs? By being small? What exactly makes MeeGo different from other desktop distros? Or was it just a little bit of marketing? So this makes it special, because it does not need to care about the old stuff. So bcoming a debian flavour feels not really like an option to me. That's fine. It doesn't have to be an option for you. It should be described as a potential option for others on this list however since they may not have made up their minds yet and the FUD that is being thrown about here is misleading. Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Wed, Oct 5, 2011 at 9:39 AM, Samuel Stirtzel s.stirt...@googlemail.com wrote: 2011/10/4 Jeremiah Foster jeremiah.fos...@pelagicore.com: Can a mobile segment distro like MeeGo be really compared with a desktop segment distro like e.g. embedded Ubuntu? (This is not relative to your message but a general rhetorical question.) I don't understand what you mean by segment here. And I also don't understand what you're referring to with embedded Ubuntu. What I meant is that a embedded desktop OS targets another audience than the embedded mobile OS (or in other terms a different market segment). Well I'm sorry for using the term embedded Ubuntu, I've assumed that others refer to projects like Linaro-Ubuntu [1], the TI-OMAP Ubuntu [2] and in general ARM Ubuntu as embedded Ubuntu too. No reason to apologize! I was just not certain what you were referring to. :) Before it was just big companies that could create their own Linux distros (before that everyone had their bespoke UNIX distro) nowadays fragmentation is brought to you by every Tom, Dick and Harry with an OBS login. I've been down the fragmentation road before. It always ends with retracing your path back to the main highway. There seems to be much standardization work going on in the Yocto Project / OpenEmbedded Core (see [3], also Carsten already mentioned the Yocto Project in context of governance), anyone evaluated it? Yocto is very interesting indeed, as is OpenEmbedded, though the claim is that Yocto is open embedded done right. But for the purposes of a distro I don't think Yocto is the silver bullet people are looking for. Firstly, it seems focused on Intel Atom BSPs and overall seems designed to help in board bring-up. Yes you can create a complete distro, but like a misused OBS repository, creating your own complete distro is not a good idea. Unless of course yours is THE ONE. Your statement about Yocto is right, but OpenEmbedded isn't OpenEmbedded anymore, alot has changed since this statement was true. OpenEmbedded Core (the new OpenEmbedded) and the Yocto Project merged their efforts and created an unified code base I tried to point that out by saying Yocto is 'open embedded done right.' But I guess I was unclear. From what I understand bitbake is still at the heart of both these projects and that is a pretty interesting piece of technology. (see [3] and [4]), also OpenEmbedded Core + Yocto supports a larger audience (see [5] for the approved list of BSP layers). In OSS systems there should not be a THE ONE distribution, for end users this is out of the question, they might not want to create their own distro, but (IMHO) developers should not be restricted in this direction. But that is precisely the point. To serve end users you need a consistent, easy to use platform, with a large ecosystem of developers to create new applications. This is one of the reasons why Debian is useful: its foundation is that it puts users first. From the Debian Social Contract; We will be guided by the needs of our users and the free software community. Yocto puts developers first which is great - but it doesn't make for a consistent, easy to use platform, with a large ecosystem. It creates different chunks which are little Linux stacks which one places over the layers which seem to be like Linaro Hardware Packs, i.e. BSPs and drivers. These chunks function as a Linux distro, you can add packages and UIs and all kinds of amazing stuff, but you have no community. You have no ecosystem, you don't scale. The Yocto Project / OpenEmbedded was discussed before in the IVI mailing list (see [4]), but it lacks any technical explanations and arguments why it cannot be used / or get adapted, also OpenEmbedded progressed into the new OpenEmbedded Core Project (the next release is just one step away). https://wiki.yoctoproject.org/wiki/FAQ OpenEmbedded is widely used in commercial embedded systems. Those systems tend to not be open source systems and end up costing lots of money. Regards, Jeremiah Sorry I don't get your point here, no offense but if I would say: Debian is widely used in commercial desktop systems. Would your statement be the same? No offense taken. I was purposely vague because I don't want to publicly deride commercial Linux companies and other hardware companies that use OE and Yocto. The difference for me is that commercial Linux companies see Linux as a technology. In my mind, that is a misunderstanding. Linux is a kernel, combined with a userland (Android, GNU, etc.) and a license group. This combination is where the magic occurs because it enforces useful changes back into GNU/Linux distros and encourages a thriving ecosystem. This thriving ecosystem is what makes Linux run on everything from MIPS, to Xeon, to ARM M5, to A11, from old desktops to the world's fastest computers, from phones to satellites. If you care about the
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Again, I agree with the project, if Mer can resurrect Maemo/MeeGo then I am all for it! On 04/10/2011 08:57, Timo Jyrinki wrote: ma, 2011-10-03 kello 19:09 +0100, Si Howard kirjoitti: I'm for that! Wasn't the Mer project part of the Maemo 5.0 porting to the Nokia N8X0 platform? That's one way of putting it, but it was indeed about reconstructing Maemo so that it worked as a whole distribution. That then made possible to try to get newer Maemo components working on older tablets purely as a community effort. So more like Maemo 5.0 porting to the Nokia N8X0 platform was a part of the Mer project, not the other way around :) -Timo ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
2011/10/5 Jeremiah Foster jeremiah.fos...@pelagicore.com: Distrowatch are server and dektop disties. The special thing in MeeGo was that the focus was on emerging devices. And how exactly did it do that? By using Connman? By using an embedded Linux kernel? Btrfs? By being small? What exactly makes MeeGo different from other desktop distros? Or was it just a little bit of marketing? I agree with Jeremiah here. MeeGo really was a lot more pain to get slimmed down with its actually desktop distro legacy and for example package dependencies than with Debian. Maemo was the actual embedded OS, but MeeGo never got to reach it. That said, I do believe there is a lot of room and need for Mer, and potentially Tizen (hopefully fully usable by Mer and others) when it actually materializes, simply because it tries to continue MeeGo as is but fixing the problems mostly everyone agrees with - MeeGo was not lean core at any point, and the community, decision and communication aspects sucked in many ways. Doing so gets the existing MeeGo community people to continue, while any other one choice like Debian (advertised by me among else), openSUSE (advertised by Jon among else), Yocto or other would not get all the same people on-board. With individuals it can be about simple things like familiriaty with tools, and OBS does rock. The important thing is to do something that matters (to you), and if possible do it in a way that everyone can benefit. The lesson with MeeGo here should be not to put all eggs into one basket. I'm a multi-distro person myself, and see strong value in distro-previously-called-MeeGo, Ubuntu, Yocto etc. in addition to Debian which I think rules the most broadly in its operation and scope. -Timo ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Carsten, David and Robin, Thank you very much for this proposal and work already done and started. This single post alone convinces me that we have not wasted any work on MeeGo (ce), and that it in fact will have bright future ahead, no matter of the name of the project , the products based on it or possible companies involved in it. This very clearly is the best part of OSS promise, when one (business) model changes, the projects and the best people continue with the code and their learning of the old model. I sincerely hope that people understand that your Mer project is not against anything or anyone. If companies don't understand the value of your proposal in this round, for sure they will in next one. Have a happy hacking, and see you around. Br, //Harri -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Carsten Munk Sent: 3. lokakuuta 2011 9:01 To: meego-dev; meego-comm...@meego.com Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo 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
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
ma, 2011-10-03 kello 19:09 +0100, Si Howard kirjoitti: I'm for that! Wasn't the Mer project part of the Maemo 5.0 porting to the Nokia N8X0 platform? That's one way of putting it, but it was indeed about reconstructing Maemo so that it worked as a whole distribution. That then made possible to try to get newer Maemo components working on older tablets purely as a community effort. So more like Maemo 5.0 porting to the Nokia N8X0 platform was a part of the Mer project, not the other way around :) -Timo ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
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
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
I just think it would have been better if we (The Nokia linux organization and the fans) did not have to go through the MeeGo hurdle, and as you say in detail, look at harmattan and how slick and beautiful is as a product. (I use it in N950 as my everyday phone and no *other* OS/ device even comes close to the experience I get. However, I understand from Carsten that all of our code is already in RPM and hence this is why Mer is going to use it, I am wondering what would it take to just use Harmattan as the basis for Mer now and keep the tradition and the rocking dev tools (Scratchbox is indeed, a cross compilation environment OOTB that as an embedded OS maker, I've yet come to see in its simplicity and support to the developer from any other platform / distro and/or vendor). If you ask me, Harmattan is the way to go , asking to yet open closed parts or replace them with open parts , put a UX on top following the Swipe style if we have a UX team (because Mer is supposed to be a thin base layer nothing more). And just do it. Then Nokia (In my deepest hopes) could re-use it when perhaps Linux will find its way back there as a smartphone platform. On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com karoliina.t.salmi...@gmail.com wrote: 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. +1 . 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. +1 - 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, 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. ++1 - 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. +++1 . Problem is that how do you make all of the technologies appear integrative to the platform, as Rich Green once noted about apps and WP7 that an app there does not feel different to the core OS UX. I could argue that we should support GTK , Vala, Mono stuff and the list goes on...but how to make it look organic? - 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. I have no idea about this - can anybody really estimate the amount of work needed? -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi Karoliina, On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com karoliina.t.salmi...@gmail.com wrote: Killing scratchbox without a replacement (OBS is not a replacement!) is not very good choice. MeeGo was theoretically usable in qemu, unfortunately, I don't think a lot of effort was put into that direction. There is also MADDE, although as you probably know, that isn't very useful unless you're a simple application developer - a more complex beast like the settings application wouldn't really be easy to use there unless you did some hacking around in the rootfs, injecting your own needed libs, etc. This is definitely something that I imagine will be looked into around the context of Mer - Mer of old had images that could easily be shoved into virtualbox, etc, and they made life a lot easier. OBS is a very useful tool, just not for the purposes you were apparently forced to use it for. I've used it for the commit, push package, wait for build failure type development cycle as well, and I agree, it's far from optimal - but for easily making heavily customised distributions, OBS is great. e.g. seeing our duicontrolpanel on MeeGo-MeeGo installation instead of Harmattan is a whole different experience than seeing it on Harmattan device), snip 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, The technology is, at the end of the day, not that important (though I agree that QML makes life a lot easier) - at the end of the day, you can have the best written UI in the world, and it will still look like complete and utter crap without decent theming. Hopefully we can poke some of the awesome graphical people around like wazd to give us a hand with some of this. - 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. One of the missing gaps, at least on Handset CE, is the settings application. As you point out, it is not visually pleasing, it has flickering text (!! Wifi before changing to the actual text), and other issues which make it a bit pailful to use. Given your experience with it, would you like to dedicate some time to making it more usable, perhaps even doing some thinking on how to approach it from the QML world? BR, Robin ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On 10/04/11 11:07, Sivan Greenberg wrote: I just think it would have been better if we (The Nokia linux organization and the fans) did not have to go through the MeeGo hurdle, and as you say in detail, look at harmattan and how slick and beautiful is as a product. (I use it in N950 as my everyday phone and no *other* OS/ device even comes close to the experience I get. The slick parts are sadly not very open. However, I understand from Carsten that all of our code is already in RPM and hence this is why Mer is going to use it, I am wondering what would it take to just use Harmattan as the basis for Mer now and keep the tradition and the rocking dev tools (Scratchbox is indeed, a cross compilation environment OOTB that as an embedded OS maker, I've yet come to see in its simplicity and support to the developer from any other platform / distro and/or vendor). Yes, one would want Scratchbox or similar in addition to what OBS provides. However, there is nothing that prevents Scratchbox from being used together with RPM and an RPM based distro is there? Don't go around trying to changing everything if what you're missing is just Scratchbox. -- Jon Nordby - www.jonnor.com Software Developer, Openismus GmbH - www.openismus.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi Sivan ( others), On Tue, Oct 4, 2011 at 11:13 AM, Sivan Greenberg si...@omniqueue.com wrote: Again, why don't we forget reinventing the infrastructure in the price of using debs (which is a known a loved format for embedded computing everywhere, and since RPM and DEBs are just a way of packaging and not really an issue if we chose one or another, just use Launchpad like Linaro does?) Talk is cheap; actions talk much more loudly. If you (or others) think this is a good approach, then by all means, go for it, do some work and get a proof of concept showing how ( why) it is better without losing the ability to easily seperate core/UI/hardware adaptations and other key parts of the proposal, and it can be looked at. We've chosen the approach of minimal change because it means we have a working system with less effort. BR, Robin ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 11:14 AM, Robin Burchell robin+me...@viroteck.net wrote: OBS is a very useful tool, just not for the purposes you were apparently forced to use it for. I've used it for the commit, push package, wait for build failure type development cycle as well, and I agree, it's far from optimal - but for easily making heavily customised distributions, OBS is great. Robin, why is OBS different and better than the original buildd's we used for Maemo and/or nowdays open sourced Launchpad ? I was one of those who felt the whole lot of changes we've been going through to adopt to Moblin were time consuming and just presented yet another hurdle to the community that was already experienced in Debian packaging and the debian build servers. I think, if we're reconstructing we should perhaps re think the decisions that were laid upon us by the corporate governance before we repeat them. Important note: this is not trolling, I'm sincerely trying to understand where and how we are going to from now on. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
2011/10/4 Sivan Greenberg si...@omniqueue.com: On Tue, Oct 4, 2011 at 11:14 AM, Robin Burchell robin+me...@viroteck.net wrote: OBS is a very useful tool, just not for the purposes you were apparently forced to use it for. I've used it for the commit, push package, wait for build failure type development cycle as well, and I agree, it's far from optimal - but for easily making heavily customised distributions, OBS is great. Robin, why is OBS different and better than the original buildd's we used for Maemo and/or nowdays open sourced Launchpad ? I was one of those who felt the whole lot of changes we've been going through to adopt to Moblin were time consuming and just presented yet another hurdle to the community that was already experienced in Debian packaging and the debian build servers. I think, if we're reconstructing we should perhaps re think the decisions that were laid upon us by the corporate governance before we repeat them. Important note: this is not trolling, I'm sincerely trying to understand where and how we are going to from now on. Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. The choice has been made to go for OBS and RPM in Mer - we'll be in a even longer cycle if we were to revert to Debian based things and it's not obvious there'll be any benefit - I personally got bitten badly by basing on Debian/Ubuntu in the first iteration of Mer. We're here now and we have something that works and expertise in these areas. That's the direction we're going in. (I swear, if we are going to have the RPM vs DEB talk, I'll propose we switch to rot13 encrypted zip files and actually go ahead with it!) BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 11:20 AM, Robin Burchell robin+me...@viroteck.net wrote: it can be looked at. We've chosen the approach of minimal change because it means we have a working system with less effort. I realize this, does this mean that once we find someone to sponsor the servers we just deploy OBS on it and we are done? (trying ot understand where this saves effort) Again - I hope that's okay I'm asking all of this, and this does not look like being ungrateful for the proposal :-) (With how MeeGo mailing lists looked the last couple of months, one be better sure than sorry ;)) -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On 10/04/2011 12:06 PM, Jon Nordby wrote: Don't go around trying to changing everything if what you're missing is just Scratchbox. I also liked the Scratchbox, despite the problems. For MeeGo stuff I use this (ARM chroot created from the osc local build): http://tuomas.kulve.fi/blog/2011/07/09/meego-1-2-armv7-chroot-beta/ The usage is similar to Scratchbox, chroot in and run make. I feel that the OBS is a bit overkill (i.e. slow) for a single component developer but maintaining a distro with it seemed convenient. It was especially nice to notice that a company's private OBS was able to link to the upstream OBS and only build the differencies. The rest (both source and binary) came from the upstream automatically. -- Tuomas ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote: Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. I see, thanks for enlightening me. We should then look to add the missing features like Feature Planning (blueprint) and others from Launchpad, although we could just use the wiki for everything not build / commit stuff. The choice has been made to go for OBS and RPM in Mer - we'll be in a even longer cycle if we were to revert to Debian based things and it's not obvious there'll be any benefit - I personally got bitten badly by basing on Debian/Ubuntu in the first iteration of Mer. We're here now and we have something that works and expertise in these areas. That's the direction we're going in. (I swear, if we are going to have the RPM vs DEB talk, I'll propose we switch to rot13 encrypted zip files and actually go ahead with it!) I've stopped it, I hope Qt Creator will learn to create RPM packages by when Mer is reading for playing with :-D -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg si...@omniqueue.comwrote: On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote: Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. Except it was built by Canonical for Ubuntu and is used by Linaro. But perhaps those two things are Debian too? OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. What does that even mean? I see, thanks for enlightening me. You're not enlightened, you've just gotten a perspective from one developer on why they like what they like. We should then look to add the missing features like Feature Planning (blueprint) and others from Launchpad, although we could just use the wiki for everything not build / commit stuff. NB - Not all of Launchpad is open source. The choice has been made to go for OBS and RPM in Mer - we'll be in a even longer cycle if we were to revert to Debian based things and it's not obvious there'll be any benefit - I personally got bitten badly by basing on Debian/Ubuntu in the first iteration of Mer. We're here now and we have something that works and expertise in these areas. That's the direction we're going in. (I swear, if we are going to have the RPM vs DEB talk, I'll propose we switch to rot13 encrypted zip files and actually go ahead with it!) Ignorance is bliss. Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com karoliina.t.salmi...@gmail.com wrote: Hello, 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. This makes way too much sense to be adopted. :-) Don't start your own project, join someone else's. - Dan Frye: Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 1:58 PM, Jeremiah Foster jeremiah.fos...@pelagicore.com wrote: On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg si...@omniqueue.com wrote: On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote: Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. Except it was built by Canonical for Ubuntu and is used by Linaro. But perhaps those two things are Debian too? OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. What does that even mean? I would also like to understand that, perhaps through the use of that layer on top of OBS which I had forgotten its name? Is there somewhere documentation to read about this? I see, thanks for enlightening me. You're not enlightened, you've just gotten a perspective from one developer on why they like what they like. To be frank, I just did not want to make Carsten angry and go with rot13 encrypted zip files so we actually have to use it ;-) We should then look to add the missing features like Feature Planning (blueprint) and others from Launchpad, although we could just use the wiki for everything not build / commit stuff. NB - Not all of Launchpad is open source. I stand corrected. The choice has been made to go for OBS and RPM in Mer - we'll be in a even longer cycle if we were to revert to Debian based things and it's not obvious there'll be any benefit - I personally got bitten badly by basing on Debian/Ubuntu in the first iteration of Mer. We're here now and we have something that works and expertise in these areas. That's the direction we're going in. (I swear, if we are going to have the RPM vs DEB talk, I'll propose we switch to rot13 encrypted zip files and actually go ahead with it!) Ignorance is bliss. Well, deb lovers could always try and have their own deb'd meego as Robin noted. But if Qt Creator does take care of all the packaging for RPM and the upload to OBS, then I should not care about the underlying packaging system. -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster wrote: On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg si...@omniqueue.com wrote: On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote: Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. Except it was built by Canonical for Ubuntu and is used by Linaro. But perhaps those two things are Debian too? OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. What does that even mean? OBS is built with packaging in mind, so it builds packages locally and on servers in a sanitized environment. Scratchbox may be polluted by whatever packages a developer has installed and makes dependency tracking a bit harder IMO. I think what Carsten means by growing an organisation organically is that OBS allows multiple users to create their own repositories, it allows us to separate different projects into different repositories for staging or logical separation and it's easy and intuitive to do all of this from the web interface and to tools provided. OBS may not offer anything more or less than Launchpad or buildd, but it is completely open source and it targets many more distributions than Launchpad or buildd do. I see, thanks for enlightening me. You're not enlightened, you've just gotten a perspective from one developer on why they like what they like. We should then look to add the missing features like Feature Planning (blueprint) and others from Launchpad, although we could just use the wiki for everything not build / commit stuff. NB - Not all of Launchpad is open source. The choice has been made to go for OBS and RPM in Mer - we'll be in a even longer cycle if we were to revert to Debian based things and it's not obvious there'll be any benefit - I personally got bitten badly by basing on Debian/Ubuntu in the first iteration of Mer. We're here now and we have something that works and expertise in these areas. That's the direction we're going in. (I swear, if we are going to have the RPM vs DEB talk, I'll propose we switch to rot13 encrypted zip files and actually go ahead with it!) Ignorance is bliss. Regards, Jeremiah ___ 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
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 2:08 PM, Tom Swindell t.swind...@rubyx.co.uk wrote: On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster wrote: On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg si...@omniqueue.com wrote: On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote: Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. Except it was built by Canonical for Ubuntu and is used by Linaro. But perhaps those two things are Debian too? OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. What does that even mean? OBS is built with packaging in mind, so it builds packages locally and on servers in a sanitized environment. Scratchbox may be polluted by whatever packages a developer has installed and makes dependency tracking a bit harder IMO. I agree that working in a dirty chroot is problematic. That is why there is pbuilder and cowdancer. I think what Carsten means by growing an organisation organically is that OBS allows multiple users to create their own repositories, it allows us to separate different projects into different repositories for staging or logical separation and it's easy and intuitive to do all of this from the web interface and to tools provided. This is likely what he's referring to. But as someone who is concerned with integration, this is bordering on a misfeature. What is happening is that each repository is a separate Linux distro. This makes integration a complete nightmare and unlikely to occur. Look a the ABI break that occurred in MeeGo for ARM. That effectively killed any release of that distro. Just because you can build your own Linux distro doesn't mean you should. OBS may not offer anything more or less than Launchpad or buildd, but it is completely open source and it targets many more distributions than Launchpad or buildd do. And more package formats, processor virtualization, per-package compiler flags, and a mock version control tool, etc. But all these things can mean that your package will not work with other distros and then we are back to everyone doing their own thing. How does that help move free software forward? It doesn't, it only encourages the silo effect and Not Invented Here. Before it was just big companies that could create their own Linux distros (before that everyone had their bespoke UNIX distro) nowadays fragmentation is brought to you by every Tom, Dick and Harry with an OBS login. I've been down the fragmentation road before. It always ends with retracing your path back to the main highway. Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
2011/10/4 karoliina.t.salmi...@gmail.com karoliina.t.salmi...@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 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
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Other reasons for keeping OBS include trying to change as little as possible from what MeeGo has done. So those vendors that are possibly already accustomed and are currently using MeeGo facilities, like OBS. Can easily migrate to Mer. There really isn't much point in debating this, Carsten has made his decision ... Thanks, Tom. On Tue, 2011-10-04 at 14:19 +0200, Jeremiah Foster wrote: On Tue, Oct 4, 2011 at 2:08 PM, Tom Swindell t.swind...@rubyx.co.uk wrote: On Tue, 2011-10-04 at 13:58 +0200, Jeremiah Foster wrote: On Tue, Oct 4, 2011 at 11:35 AM, Sivan Greenberg si...@omniqueue.com wrote: On Tue, Oct 4, 2011 at 11:28 AM, Carsten Munk cars...@maemo.org wrote: Long story short: buildd and launchpad is very useful but only when you're doing Debian and Debian only. Except it was built by Canonical for Ubuntu and is used by Linaro. But perhaps those two things are Debian too? OBS is different in many different ways and allows a proper productization environment as well as growing an organisation organically. What does that even mean? OBS is built with packaging in mind, so it builds packages locally and on servers in a sanitized environment. Scratchbox may be polluted by whatever packages a developer has installed and makes dependency tracking a bit harder IMO. I agree that working in a dirty chroot is problematic. That is why there is pbuilder and cowdancer. I think what Carsten means by growing an organisation organically is that OBS allows multiple users to create their own repositories, it allows us to separate different projects into different repositories for staging or logical separation and it's easy and intuitive to do all of this from the web interface and to tools provided. This is likely what he's referring to. But as someone who is concerned with integration, this is bordering on a misfeature. What is happening is that each repository is a separate Linux distro. This makes integration a complete nightmare and unlikely to occur. Look a the ABI break that occurred in MeeGo for ARM. That effectively killed any release of that distro. Just because you can build your own Linux distro doesn't mean you should. OBS may not offer anything more or less than Launchpad or buildd, but it is completely open source and it targets many more distributions than Launchpad or buildd do. And more package formats, processor virtualization, per-package compiler flags, and a mock version control tool, etc. But all these things can mean that your package will not work with other distros and then we are back to everyone doing their own thing. How does that help move free software forward? It doesn't, it only encourages the silo effect and Not Invented Here. Before it was just big companies that could create their own Linux distros (before that everyone had their bespoke UNIX distro) nowadays fragmentation is brought to you by every Tom, Dick and Harry with an OBS login. I've been down the fragmentation road before. It always ends with retracing your path back to the main highway. Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
OBS is a very useful tool, just not for the purposes you were apparently forced to use it for. I've used it for the commit, push package, wait for build failure type development cycle as well, and I agree, it's far from optimal - but for easily making heavily There are couple of ways to speed up the development also when working in the OBS environment, especially when really trying to solve real development problems. Here couple of tips. 1) offline option -o when doing osc build will speed up things a little when trying to do a multiple local builds in a row, as then the obs does not try to get the latest dependency list from the server. osc build -o armv8el as an example... 2)When doing a development, you can first create the chroot env with osc build command and then after the first build have started switch to chroot environment a) osc co Project:DE:Trunk/ohm b) cd Project:DE:Trunk/ohm c) osc build armv8el ... wait the build to complete or fail and then switch to chroot env d) cd /var/tmp/osc-build-root/ e) sudo su f) chroot . g) cd home/abuild/rpmbuild/BUILD/ohm-1.1.14 h) run commands like make/make install on chrooted bash shell i) edit the files by using your favourite editor from another shell from dir /var/tmp/osc-build-root/home/abuild/rpmbuild/BUILD/ohm-1.1.14 3) you can have multiple chrooted environments by editing build-root variable from the ~/.oscrc file. I for example prefer of having something like: build-root = /obs/buildroots/%(repo)s-%(arch)s 4) You can force that osc build command will always put certain packages to chroot env in addition of the direct dependencies of certain app by listing these extra packages is ~/.oscrc file. For example: extra-pkgs = gdb strace What I am also missing would be an easy way to configure the QT creator easily to use the qt, qml and gcc from the chrooted env. (So I could just do the qml editing with the qt-creator by using those components that happens to be installed in the chroot env that the osc build command has created.) So if somebody knows ways to do that, I would be very interested. Mika customised distributions, OBS is great. e.g. seeing our duicontrolpanel on MeeGo-MeeGo installation instead of Harmattan is a whole different experience than seeing it on Harmattan device), snip 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, The technology is, at the end of the day, not that important (though I agree that QML makes life a lot easier) - at the end of the day, you can have the best written UI in the world, and it will still look like complete and utter crap without decent theming. Hopefully we can poke some of the awesome graphical people around like wazd to give us a hand with some of this. - 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. One of the missing gaps, at least on Handset CE, is the settings application. As you point out, it is not visually pleasing, it has flickering text (!! Wifi before changing to the actual text), and other issues which make it a bit pailful to use. Given your experience with it, would you like to dedicate some time to making it more usable, perhaps even doing some thinking on how to approach it from the QML world? BR, Robin ___ 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
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 2:19 PM, Jeremiah Foster jeremiah.fos...@pelagicore.com wrote: I think what Carsten means by growing an organisation organically is that OBS allows multiple users to create their own repositories, it allows us to separate different projects into different repositories for staging or logical separation and it's easy and intuitive to do all of this from the web interface and to tools provided. This is likely what he's referring to. But as someone who is concerned with integration, this is bordering on a misfeature. What is happening is that each repository is a separate Linux distro. This makes integration a complete nightmare and unlikely to occur. Look a the ABI break that occurred in MeeGo for ARM. That effectively killed any release of that distro. Just because you can build your own Linux distro doesn't mean you should. Also, does not Launchpad support PPA at this point, as well as on the fly test builds out of version control? I know Linaro people are using it and are quite happy about it or perhaps I'm misinformed ? It might be ahead of time to be concerned by this, but the concern Quim Gill expressed about the ability of the community to fund the infrastructure might be realized if Mer is to be adopted on a large scale... My personal experience with Launchpad is that the sysadmin personnel is *VERY* responsive and cater for rapid and fruitful distro work. Again, those concerns are only for when Mer is in massive adoption which is where we want to reach anyway? How do we pitch prospective sponsors when they ask us about Harmattan and speak about Debian in the mobile field, I think it has some success compared to others. Linaro seems to be doing well and they so far manage to gather vendors interested. Again, no trolling, just asking questions :) -Sivan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, maybe I'm wrong but the Scratchbox mailing lists looks pretty dead right now (see [1]). Is there any community alive behind it, or should the new MeeGo project reanimate Scratchbox if it would be used? 2011/10/4 Jeremiah Foster jeremiah.fos...@pelagicore.com: OBS is built with packaging in mind, so it builds packages locally and on servers in a sanitized environment. Scratchbox may be polluted by whatever packages a developer has installed and makes dependency tracking a bit harder IMO. I agree that working in a dirty chroot is problematic. That is why there is pbuilder and cowdancer. Wouldn't it be better to use a decentral build system? Can a mobile segment distro like MeeGo be really compared with a desktop segment distro like e.g. embedded Ubuntu? (This is not relative to your message but a general rhetorical question.) Well I didn't use embedded Debian as example because Emdebian mailing lilsts seem to be pretty dead [2]. Before it was just big companies that could create their own Linux distros (before that everyone had their bespoke UNIX distro) nowadays fragmentation is brought to you by every Tom, Dick and Harry with an OBS login. I've been down the fragmentation road before. It always ends with retracing your path back to the main highway. There seems to be much standardization work going on in the Yocto Project / OpenEmbedded Core (see [3], also Carsten already mentioned the Yocto Project in context of governance), anyone evaluated it? The Yocto Project / OpenEmbedded was discussed before in the IVI mailing list (see [4]), but it lacks any technical explanations and arguments why it cannot be used / or get adapted, also OpenEmbedded progressed into the new OpenEmbedded Core Project (the next release is just one step away). On a technical point of view it is possible to port over to Yocto Project, and it would make sence to concentrate the development of embedded linux distributions to unify them into a single development base instead of fragmenting the communities. Well I just stated my opinion here. [1] http://lists.scratchbox.org/pipermail/scratchbox-devel/ [2] http://lists.debian.org/debian-embedded/2011/09/threads.html [3] http://www.yoctoproject.org/projects/openembedded-core [4] http://lists.meego.com/pipermail/meego-ivi/2011-February/000198.html Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Regards Samuel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
2011/10/4 Samuel Stirtzel s.stirt...@googlemail.com: Before it was just big companies that could create their own Linux distros (before that everyone had their bespoke UNIX distro) nowadays fragmentation is brought to you by every Tom, Dick and Harry with an OBS login. I've been down the fragmentation road before. It always ends with retracing your path back to the main highway. There seems to be much standardization work going on in the Yocto Project / OpenEmbedded Core (see [3], also Carsten already mentioned the Yocto Project in context of governance), anyone evaluated it? The Yocto Project / OpenEmbedded was discussed before in the IVI mailing list (see [4]), but it lacks any technical explanations and arguments why it cannot be used / or get adapted, also OpenEmbedded progressed into the new OpenEmbedded Core Project (the next release is just one step away). On a technical point of view it is possible to port over to Yocto Project, and it would make sence to concentrate the development of embedded linux distributions to unify them into a single development base instead of fragmenting the communities. Well, I think that would make sense if the Mer project didn't want to stay close to Tizen if possible, integrating Tizen features. Mer as a standalone project can take these directions unilaterally, where it would be more difficult to make it happen in another project. That doesn't mean that efforts on some parts cannot be shared (the same way like with Tizen), but IMO, the direction, philosophy and basis of Mer as I undestand it justify that it stays independent. Regards, Arnaud ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 4:19 PM, Samuel Stirtzel s.stirt...@googlemail.comwrote: [snip] 2011/10/4 Jeremiah Foster jeremiah.fos...@pelagicore.com: OBS is built with packaging in mind, so it builds packages locally and on servers in a sanitized environment. Scratchbox may be polluted by whatever packages a developer has installed and makes dependency tracking a bit harder IMO. I agree that working in a dirty chroot is problematic. That is why there is pbuilder and cowdancer. Wouldn't it be better to use a decentral build system? Sometimes embedded developers only have the target and their laptop. So often having your complete toolchain on your laptop while you work on site at a customer for example can be part of a developer's work flow. This means a decentralized system can be a necessity. But you have to make sure you send back your patches. Can a mobile segment distro like MeeGo be really compared with a desktop segment distro like e.g. embedded Ubuntu? (This is not relative to your message but a general rhetorical question.) I don't understand what you mean by segment here. And I also don't understand what you're referring to with embedded Ubuntu. Well I didn't use embedded Debian as example because Emdebian mailing lilsts seem to be pretty dead [2]. Embedian is very much alive. More here: http://www.debian.org/News/weekly/2011/12/#emdebian Before it was just big companies that could create their own Linux distros (before that everyone had their bespoke UNIX distro) nowadays fragmentation is brought to you by every Tom, Dick and Harry with an OBS login. I've been down the fragmentation road before. It always ends with retracing your path back to the main highway. There seems to be much standardization work going on in the Yocto Project / OpenEmbedded Core (see [3], also Carsten already mentioned the Yocto Project in context of governance), anyone evaluated it? Yocto is very interesting indeed, as is OpenEmbedded, though the claim is that Yocto is open embedded done right. But for the purposes of a distro I don't think Yocto is the silver bullet people are looking for. Firstly, it seems focused on Intel Atom BSPs and overall seems designed to help in board bring-up. Yes you can create a complete distro, but like a misused OBS repository, creating your own complete distro is not a good idea. Unless of course yours is THE ONE. The Yocto Project / OpenEmbedded was discussed before in the IVI mailing list (see [4]), but it lacks any technical explanations and arguments why it cannot be used / or get adapted, also OpenEmbedded progressed into the new OpenEmbedded Core Project (the next release is just one step away). https://wiki.yoctoproject.org/wiki/FAQ OpenEmbedded is widely used in commercial embedded systems. Those systems tend to not be open source systems and end up costing lots of money. Regards, Jeremiah On a technical point of view it is possible to port over to Yocto Project, and it would make sence to concentrate the development of embedded linux distributions to unify them into a single development base instead of fragmenting the communities. Well I just stated my opinion here. [1] http://lists.scratchbox.org/pipermail/scratchbox-devel/ [2] http://lists.debian.org/debian-embedded/2011/09/threads.html [3] http://www.yoctoproject.org/projects/openembedded-core [4] http://lists.meego.com/pipermail/meego-ivi/2011-February/000198.html Regards, Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Regards Samuel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- = Jeremiah C. Foster Open Source Technologist Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46 (0)730 93 0506 E-Mail: jeremiah.fos...@pelagicore.com = === NOTE === The information contained in this E-mail message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. = ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
On Tue, Oct 4, 2011 at 6:48 PM, Stefan Werden stefan.wer...@open-slx.dewrote: Hi, switching to debian would mean making a complete new projekt. Nope, it would merely mean adding software to the Debian project, it wouldn't require a new project at all. Debian would host the infrastructure (it has its own IRC, build farm, hosting, project software, email lists, funding, non-profit status, social contract, shell accounts, git server, svn server, well, you get the picture.) You could turn Mer into a Debian blend for example: http://wiki.debian.org/DebianPureBlends or you could become a Debian derivative: http://wiki.debian.org/Derivatives/Census Debian derivatives currently dominate the Linux landscape. Of the top four distros on Distro Watch, three of them are deb based. This means you get a huge development ecosystem when you use debs, as well as a lot of users. I would prefer to just continure the current running stack. It saves time and people know how to handle it. *sigh* regards, Stefan Jeremiah Foster jeremiah.fos...@pelagicore.com hat am 4. Oktober 2011 um 14:03 geschrieben: On Tue, Oct 4, 2011 at 10:53 AM, karoliina.t.salmi...@gmail.com karoliina.t.salmi...@gmail.com wrote: Hello, 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. This makes way too much sense to be adopted. :-) Don't start your own project, join someone else's. - Dan Frye: Regards, Jeremiah -- Dr. Stefan Werden Managing Director open-slx gmbh, HRB 25876, Einsteinring 7, 90453 Nürnberg, Germany -- = Jeremiah C. Foster Open Source Technologist Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46 (0)730 93 0506 E-Mail: jeremiah.fos...@pelagicore.com = === NOTE === The information contained in this E-mail message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. = ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
2011/10/3 Carsten Munk cars...@maemo.org Hi all, Our solution is the Mer Project: Excellent! count me in. A few questions about the project's communication channels? Do we use these MeeGo mailing list, the meego-* IRC channels or are we moving somewhere? (IMO moving to mer-specific channels would make sense) -Timo ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
2011/10/3 Timo Härkönen timop.harko...@gmail.com: 2011/10/3 Carsten Munk cars...@maemo.org Hi all, Our solution is the Mer Project: Excellent! count me in. A few questions about the project's communication channels? Do we use these MeeGo mailing list, the meego-* IRC channels or are we moving somewhere? (IMO moving to mer-specific channels would make sense) I think for now, we use mer specific channels. Ideally we'd like to stay within MeeGo community, but for reasons such as trademark usage and uncertain future, we'd like to earn ability to use MeeGo as a name through actual effort and merit. Also, I seem to have learnt that cross posting is bad, seems like I posted to meego-commits@ as well instead of meego-community. BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
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
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
From: Carsten Munk cars...@maemo.org To: meego-dev meego-dev@meego.com; meego-comm...@meego.com Sent: Monday, October 3, 2011 1:01 AM Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo 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. ... Our solution is the Mer Project: Count me in, Carsten, David and Robin, even if I get involved with other projects. Randall (Randy) Arnold http://texrat.net ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, -Original Message- From: Randall Arnold From: Carsten Munk cars...@maemo.org To: meego-dev meego-dev@meego.com; meego-comm...@meego.com Sent: Monday, October 3, 2011 1:01 AM Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo 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. ... Our solution is the Mer Project: Count me in, Carsten, David and Robin, even if I get involved with other projects. +1 from me I didn't manage for openMind, but I promise to look into Mer on Archos gen6/7/8/9, BeagleBoard, PandaBoard and SnowBall as soon as I recover from this head cold and find some spare time. (help welcome!) Cheers Thomas ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, Sounds great! Count me in. -- Iekku -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev- boun...@meego.com] On Behalf Of ext Carsten Munk Sent: 03 October, 2011 09:01 To: meego-dev; meego-comm...@meego.com Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo 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
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Il 10/03/2011 09:01 AM, Carsten Munk ha scritto: 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: [...] That's fantastic! I can't make any promises, as free time is an obsolete concept for me, but I'll support the project as much as I can. Thanks guys for driving this! Ciao, Alberto ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Hi, +1 Nicola Da: meego-dev-boun...@meego.com A: meego-dev meego-dev@meego.com, meego-comm...@meego.com Cc: Data: Mon, 3 Oct 2011 08:01:17 +0200 Oggetto: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo 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
Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
I'm for that! Wasn't the Mer project part of the Maemo 5.0 porting to the Nokia N8X0 platform? On 03/10/2011 07:01, Carsten Munk 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
