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
[MeeGo-dev] an open invitation to discuss a community based future
Hi all :) Executive summary: you are all invited to a meeting on irc to discuss how we can create a meego-next system with which we can deliver amazing user experiences. We hope to host an open, collaborative and focussed set of discussions on how we can define what that means and move forward together. When: Wednesday (the 5th) at 13:00 UTC and Thursday (the 6th) at 18:00 UTC Where: irc.freenode.net in #mer Who: Everyone interested in an open, thriving future for a compelling device OS that embodies that goals (and beyond) that MeeGo originally espoused. The meeting hosting will be provided by the Plasma Active team. Basic Agenda: * _Quick_ introductions * What a 'core OS' looks like to us in terms of key attributes (not looking to deep-dive into technical details here quite yet) * How we can enable great UX efforts * How to shape an engaging community structure around this .. and now the longer description with a bit more detail: The Plasma Active community has been working on innovative UX on top of MeeGo, making things like this: http://blip.tv/aseigo-on-kde/plasma-active-tablet-09-2011-5518099 We were drawn to the concepts of openness that MeeGo was to embody along with the choices in technology it was making. We feel the ideas are too good to let die and we would like to be a meaningful part of the community effort to realize those goals. We would like to help build up and support the collaborative, open, community- driven processes that are starting to emerge organically, and we feel that begins with us engaging directly with the broader MeeGo community, enthusiast and company alike, to find out together what are our common goals are and how we can realistically work to achieve them. Note that this is not a competing effort with Mer, etc .. in fact, we feel that such efforts are very much in the spirit of what is needed and we wish to work with and not in competition to such efforts. We also feel that purposeful vision, clear goals, community growth and interfaces for interested companies (including a definition of what that means for us the community) are all needed and won't just happen on their own. This, along with our UX community and expertise, is something the people within the Plasma Active community feel we can bring to the broader community. These IRC meetings are, for us, the beginning of this engagement ... I hope to see you all there. To openness .. and beyond! :) .. and if you have any questions or comments before-hand, please share them with us as we're keenly interested in feedback and discussion on these topics. Also, apologies for the cross-posting; I was simply at a bit of a loss as to how to most effectively reach out to the community at large. I hope in this case that the end will indeed justify the means ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ 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
