[MeeGo-dev] MeeGo OBS shutdown - huge thanks and moving on
Hi everyone As we knew the MeeGo infrastructure is closing down. The MeeGo OBS is scheduled for shutdown at the end of next week ~ 29 May. I should have announced this earlier but I've been busy; sorry. Please ensure you've taken backups of anything you need - once it's gone it really will be gone! I'd like to take this opportunity to thank everyone at Intel for continuing to support the MeeGo community for this long with a HUGE special mention to Adam Gretzinger who has helped look after the infrastructure in an efficient and reliable way - if you ever have him as a sysadmin for your project then I'm jealous! Thanks also go of course, to Neils Breet and Islam Amer who have worn MeeGo sysadmin hats and continue to do so in our new home at the Mer Project. So with that segue we can look forward to where we've built on the open elements of MeeGo - and hopefully improved them - in the Mer Project. See https://wiki.merproject.org/ and http://www.merproject.org/ for more info If you do (or would like to) build opensource projects against Mer, Nemo or PlasmaActive - or plan to build for Jolla's SailfishOS (https://www.sailfishos.org/) - and want to use the Mer Community OBS at https://build.merproject.org/ you're welcome. Register on our bugzilla https://bugs.merproject.org/ for an account and talk to us on irc in #mer on freenode or on the mailing lists. Due to resource limitations we will only be able to support builds against Mer based distros (with some special cases for our infrastructure tools like OBS, BOSS, IMG etc) - but do talk to us if you have any questions. I'll continue to act as a volunteer sysadmin until the lights go out; it's been an experience and a pleasure working with the MeeGo community. David Greaves / lbt Soon to be ex-MeeGo.com sysadmin but now Mer Co-Founder and Vendor-relations Guy -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] [Meego-SDK]https relevant
HI: I am a student of Software Institute of Chinese Academy. Now I program in MeeGo System. I have some questions: The same Code when running in (1)device: QWebView can not load https page but the browser contained in MeeGo System can load https pages. (2)QtCreator-Simulator: QWebView can not load https pages; (3)QtCreator-Emulator:QWebView can load https pages successfully; I know that it is about openssl, but i don know how to configure it! Can anyone help about this problem? Thank you very much. wenla___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] MeeGo Gitorious Service after March 21, 2013 and git.meego.com setup
Hi folks: The contract the MeeGo project has with Gitorious ends on March 21, 2013. Gitorious provided source coding hosting services for MeeGo. While its not expected that they will remove existing git repos it is expected there will be changes in the meego.gitorious.org website which may make it hard to find the repos for some who relied on the web interface. To keep the code available https://git.meego.com has been setup. It has a copy of the official git repos, anyone can substitute a Gitorious URL for a git.meego.com URL (again for official repos) if necessary. This is a precaution to preserve an official copy of the GIT repos and the list of all repos where a gitweb instance is provided on git.meego.com. Adam Gretzinger Intel Open Source Technology Center -MeeGo Gitorious Contract Ending Announcement Email 3/18/2013 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] MeeGo mailing list shutdown
Dear participants As part of the MeeGo infrastructure ramp down, we will begin to shut down most mailing lists. In the coming days, all mailing lists at lists.meego.com will be shut down, except for the following: NameReason meego-dev general discussions meego-commits automated emails from builds still being sent there meego-security security concerns The mailing list archives will be frozen too, but not deleted until the main infrastructure shuts down completely. Some mailing lists have been archived publicly by other services, such as: http://gmane.org/find.php?list=meego http://www.mail-archive.com/find.php?q=meego In addition, we'd like to ask everyone still using MeeGo services, like OBS, to begin finding other solutions. We will shut down all but essential services in May 2013. If you have questions about this, please contact me or adam.r.gretzin...@intel.com. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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-announce] MeeGo mailing list shutdown
Thanks for all your work, Best George George Ingram http://www.georgeingram.com/ 815 1st Avenue, Ste 156 Seattle, Washington 98104 Direct Line 804-464-7267 Fax Line 804-414-7746 -Original Message- From: meego-announce-boun...@meego.com [mailto:meego-announce-boun...@meego.com] On Behalf Of Thiago Macieira Sent: Friday, January 25, 2013 3:17 PM To: meego-annou...@lists.meego.com Subject: [MeeGo-announce] MeeGo mailing list shutdown Dear participants As part of the MeeGo infrastructure ramp down, we will begin to shut down most mailing lists. In the coming days, all mailing lists at lists.meego.com will be shut down, except for the following: NameReason meego-dev general discussions meego-commits automated emails from builds still being sent there meego-security security concerns The mailing list archives will be frozen too, but not deleted until the main infrastructure shuts down completely. Some mailing lists have been archived publicly by other services, such as: http://gmane.org/find.php?list=meego http://www.mail-archive.com/find.php?q=meego In addition, we'd like to ask everyone still using MeeGo services, like OBS, to begin finding other solutions. We will shut down all but essential services in May 2013. If you have questions about this, please contact me or adam.r.gretzin...@intel.com. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ MeeGo-announce mailing list meego-annou...@meego.com http://lists.meego.com/listinfo/meego-announce ___ 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-tv-irinterface
On 19 September 2012 09:52, MacBook Pro valentin.cu...@gmail.com wrote: Hello I work on Cocom Tatcher 4200 and the board can't recognize the Ir-receiver i launch the command ir-interface /usr/share/ir_interface/cocom_nec.map Got the SoC information Waiting for the PIC events… when i list the input device at /proc/bus/input/devices i have the receiver but no Physique adress like for a keyboard or a mouse I: Bus=0006 Vendor=8765 Product=4321 Version=0001 N: Name=meego-tv-ir P: Phys= S: Sysfs=/devices/virtual/input/input5 U: Uniq= H: Handlers=kbd event3 B: PROP=0 B: EV=13 B: KEY=40 0 0 0 0 18000 4180 4801 1e1680 0 0 1ffe B: MSC=10 When i list the input device by id (/dev/input/by-id/), the ir receiver isn't recognized lrwxrwxrwx 1 root root 9 Jan 1 00:00 usb-0461_USB_Optical_Mouse-event-mouse - ../event2 lrwxrwxrwx 1 root root 9 Jan 1 00:00 usb-0461_USB_Optical_Mouse-mouse - ../mouse0 lrwxrwxrwx 1 root root 9 Jan 1 00:00 usb-_USB_Keyboard-event-if01 - ../event1 lrwxrwxrwx 1 root root 9 Jan 1 00:00 usb-_USB_Keyboard-event-kbd - ../event0 please, i wish know what is the problem and how to resolve it. =) thx ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines Hi, Meego-tv-ir uses uinput have a look in /dev/input/uinput. Have a look at the code if you want to understand in detail how to handle the ir-remote. https://github.com/arfoll/meego-tv-IRinterface Cheers, Brendan -- Brendan Le Foll http://www.madeo.co.uk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Meego-tv-irinterface
Hello I work on Cocom Tatcher 4200 and the board can't recognize the Ir-receiver i launch the command ir-interface /usr/share/ir_interface/cocom_nec.map Got the SoC information Waiting for the PIC events… when i list the input device at /proc/bus/input/devices i have the receiver but no Physique adress like for a keyboard or a mouse I: Bus=0006 Vendor=8765 Product=4321 Version=0001 N: Name=meego-tv-ir P: Phys= S: Sysfs=/devices/virtual/input/input5 U: Uniq= H: Handlers=kbd event3 B: PROP=0 B: EV=13 B: KEY=40 0 0 0 0 18000 4180 4801 1e1680 0 0 1ffe B: MSC=10 When i list the input device by id (/dev/input/by-id/), the ir receiver isn't recognized lrwxrwxrwx 1 root root 9 Jan 1 00:00 usb-0461_USB_Optical_Mouse-event-mouse - ../event2 lrwxrwxrwx 1 root root 9 Jan 1 00:00 usb-0461_USB_Optical_Mouse-mouse - ../mouse0 lrwxrwxrwx 1 root root 9 Jan 1 00:00 usb-_USB_Keyboard-event-if01 - ../event1 lrwxrwxrwx 1 root root 9 Jan 1 00:00 usb-_USB_Keyboard-event-kbd - ../event0 please, i wish know what is the problem and how to resolve it. =) thx ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] MeeGo Outages for Patching 10/29/2011, 10/30/2011
The MeeGo IT team has a number of items to take care of as part of regular maintenance, we'll be having 3 separate change windows this coming weekend as listed below. 1) October 29, 2011 03:00 GMT - 05:00 GMT Outage Reason: OS Patching, Firmware Upgrades Impacted: Core OBS, download and repo 2) October 29, 2011 18:00 GMT - 22:00 GMT Outage Reason: OBS Updates Impacted: Community OBS 2) October 30, 2011 03:00 GMT - 06:00 GMT Outage Reason: OS Patching, Firmware Upgrades Impacted: Community OBS, MeeGo websites (almost all of them), MeeGo public infrastructure. Thanks for your patience. Adam Gretzinger Intel Open Source Technology Center ___ 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 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
[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 support these as well as easier contribution methods. As part of our customer oriented goal we're improving delivery methods from Mer. We are designing simpler and more resilient update mechanisms to support smaller and more distributed organisations (think outsourcing too!). We want to encourage easy upstream contribution and
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
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-community] invitation... and a second one
(cc:ing to meego-dev as well since Jos originally wanted to post there, too) to, 2011-09-29 kello 21:40 +0200, Jos Poortvliet kirjoitti: Dear MeeGo friends! Many people in your community wonder where to go since the Tizen announcement. At a MeeGo meet in Tampere, many expressed concerns: can we contribute to Tizen? How long will it last *this time*? How will Samsung behave? I know many of you are concerned about loosing the great community you've build. Thanks Jos for the invitation! I have now written another invitation from Debian perspective and an overview of the situation from my point of view at: http://losca.blogspot.com/2011/10/from-meego-to-tizen-debian.html In brief: do not fall in agony, there is a wide range of communities out there. Just answer the Aaron Seigo's question about thinking about evaluating own motives in contributing to for example MeeGo. Then choose the communities (plural) you want to work in! Obviously it could be the future Tizen community as well. But it could be openSUSE, Debian, Qt project, KDE project, Mer, or any number of other possibilities. All of them have some similarities with what MeeGo was. -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-community] MeeGo as a vehicle for Qt-based products?
On Oct 1, 2011, at 11:28 AM, Kok, Auke-jan H wrote: Snip I've been asking the same questions as everyone else. If I get answers back that I can share, I most certainly will. For now, I'd like to ask everyone to submit questions to Dawn Foster, and keep asking. Answers will come - be patient. Please no :) I really do read all of the mailing list posts here, so continue to use this is as the place for questions and discussion. Sending it to me individually makes it less likely that you will get an answer, not more likely. Right now, there are still many unanswered questions because we just don't have answers to many of the technical questions yet. People are very focused on getting the code out into the repos so that we can start having productive discussions about the project based on the code. Right now, we'd be guessing along with everyone else on many of the questions. Dawn ___ 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
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
Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?
On Sat, 2011-10-01 at 21:29 +, Jarmo Kuronen wrote: I feel as if you over-estimate Intel's software development efforts for MeeGo. Lets be realistic, what there is left, really, after N+I has left the building? Freedom. ___ 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-community] MeeGo as a vehicle for Qt-based products?
On 09/29/2011 10:20 AM, Nasa wrote:
1) Concentrate on the handset and *ONLY* on it from now onward. Do
one thing and do it best (tm).
Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...
Fine... pick IVI. Pick *something*.
MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently
too much to bear even with corporate sponsorship. If you continue as a
community project, it's important to narrow this down in order to succeed.
-gabriel
___
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-community] MeeGo as a vehicle for Qt-based products?
On 10/01/2011 06:58 AM, Gabriel Beddingfield wrote:
On 09/29/2011 10:20 AM, Nasa wrote:
1) Concentrate on the handset and *ONLY* on it from now onward. Do
one thing and do it best (tm).
Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...
Fine... pick IVI. Pick *something*.
MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently
too much to bear even with corporate sponsorship. If you continue as
a community project, it's important to narrow this down in order to
succeed.
-gabriel
I think this is pretty much up to the people/groups interested in the
different verticals.
Now, I think most of the current volunteers interests are focused on
handsets and some part in tablets too, but that is different and there
is no need to set in stone a decision about excluding anything; let
people volunteering for what they want.
What could be a change and improvement, in my opinion, is to find a
better way of communication through the different verticals, probably in
a more modular way.
--- Luis
___
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-community] MeeGo as a vehicle for Qt-based products?
On Sat, Oct 1, 2011 at 2:28 PM, Gabriel Beddingfield gabrb...@gmail.com wrote:
On 09/29/2011 10:20 AM, Nasa wrote:
1) Concentrate on the handset and *ONLY* on it from now onward. Do
one thing and do it best (tm).
Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...
Fine... pick IVI. Pick *something*.
MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
much to bear even with corporate sponsorship. If you continue as a
community project, it's important to narrow this down in order to succeed.
++1 That is why I said so the first place. Trying to do everything and
in the same time proved us very wrong.
-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-community] MeeGo as a vehicle for Qt-based products?
On Oct 1, 2011, at 2:28 PM, ext Gabriel Beddingfield wrote:
On 09/29/2011 10:20 AM, Nasa wrote:
1) Concentrate on the handset and *ONLY* on it from now onward. Do
one thing and do it best (tm).
Why would you exclude 4/5 of the people involved in the meego project?
Handsets weren't even the largest part of the project...
Fine... pick IVI. Pick *something*.
MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
much to bear even with corporate sponsorship. If you continue as a community
project, it's important to narrow this down in order to succeed.
Just as my personal opinion as OSS hacker that has nothing to do with my
employer.
Let's first divide MeeGo as horizontal layers.
1- Mobile Qt / QtQuick /QtQuick based applications
2- Mobile UX
3- Foundation layers ( Linux kernel and most of middleware)
1, Mobile Qt apps, there will be big future and Intel decision did not change
anything, there is community that would like to develop these apps and there
are many platforms able to run them,MeeGo from MeeGo project , MeeGo
Harmattan/N9, Symbian, Android, Tizen and Nokia's Next Billion project.
having community for mobile Qt development together is good reason to be
existing.
2. MeeGo offers only full Open Source Mobile UX. Tizen don't need it but
OpenSuse proposal was interesting. using MeeGo UX, we could make mobile
distros based on OpenSuse, Ubuntu and others. I don't see any reason continue
Netbook, there are already Ubuntu etc and MeeGo has very little to offer. IVI
is car manufacturer driven, if they are interested and continues sponsor MeeGo,
it is OK. Handsets, full open handsets that allow installing your own OS are
rare, so it is relatively small field. Tablets I see best target for MeeGo.
Intel abandoned MeeGo and they were driving tablet, we can make better tablet
UX based on MeeGo handset UX. Combining forces with other Linux distros we can
make competitive alternative distro for tablets.
3- In this area, I don't see any reason duplicate work that ids already done
with other distros.
We can think that 1, Mobile Qt apps will be there and there will be lot of
developers doing it. MeeGo and Maemo were already Mobile app developers
community so that we can still be. Good question is even closer relation with
KDE community.
As my personal opinion we should have OSS distro for tablets as alternative. In
case I would have x86 tablet, I won't even consider Windows7 or even Windows8.
In this area we have clear common interest with desktop linux distros. They
have everything else but they are lacking mobile UX and MeeGo is only one that
can offer it. When MeeGo was corporate driven and building full distro, it did
not need them but as OSS project there are common interests.
Kate
___
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...
El 29/09/11 02:39, Leonardo Luiz Padovani da Mata escribió: Burned me once, that's ok, burned me twice, fine, but the third time (after speaking about Meego in some other engagements)? You've got to have a pretty good reason why I'm gonna trust this new development. +one with the same feeling. Oh my God! Also the same feeling!. But I'm sure I will continue with Qt. (A developer encouraged to swicth to Android, but happy using Maemo's 5 N900). ___ 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-community] MeeGo as a vehicle for Qt-based products?
On Sat, Oct 1, 2011 at 7:56 AM, Dayo roneywo...@googlemail.com wrote:
Fine... pick IVI. Pick *something*.
MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
much to bear even with corporate sponsorship. If you continue as a
community project, it's important to narrow this down in order to
succeed.
++1 That is why I said so the first place. Trying to do everything and
in the same time proved us very wrong.
I don't see a problem with keeping the various implementations of MeeGo
alive, if there are people interested in contributing to them. Naturally, if
a project receives no active contributions it goes stale and dies, but why
kill it preemptively?
Many of us believe that supporting all the verticals and profiles
failed because it fragmented developers... and there were not enough
developers to support it all. I honestly believe that it is a large
reason why MeeGo has been more or less floundering.
With Intel removing the lion's share of those developer resources...
it would be foolish to continue that failed approach. It sets
everyone up for failure.
By re-focusing the goals to ONE THING... the hard-to-rely-on community
development model (*cough*Debian*cough*) has a reasonable chance of
accomplishing those goals. Once achieved, you may find room to re-add
those other verticals on top of a stable foundation.
-gabriel
___
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-community] MeeGo as a vehicle for Qt-based products?
On Sat, 2011-10-01 at 10:13 -0500, Gabriel Beddingfield wrote: With Intel removing the lion's share of those developer resources... it would be foolish to continue that failed approach. It sets everyone up for failure. I feel as if you over-estimate Intel's software development efforts for MeeGo. regards, Michael ___ 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-community] MeeGo as a vehicle for Qt-based products?
On 10/01/2011 04:13 PM, Gabriel Beddingfield wrote:
On Sat, Oct 1, 2011 at 7:56 AM, Dayoroneywo...@googlemail.com wrote:
Fine... pick IVI. Pick *something*.
MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was apparently too
much to bear even with corporate sponsorship. If you continue as a
community project, it's important to narrow this down in order to
succeed.
++1 That is why I said so the first place. Trying to do everything and
in the same time proved us very wrong.
I don't see a problem with keeping the various implementations of MeeGo
alive, if there are people interested in contributing to them. Naturally, if
a project receives no active contributions it goes stale and dies, but why
kill it preemptively?
Many of us believe that supporting all the verticals and profiles
failed because it fragmented developers... and there were not enough
developers to support it all. I honestly believe that it is a large
reason why MeeGo has been more or less floundering.
With Intel removing the lion's share of those developer resources...
it would be foolish to continue that failed approach. It sets
everyone up for failure.
By re-focusing the goals to ONE THING... the hard-to-rely-on community
development model (*cough*Debian*cough*) has a reasonable chance of
accomplishing those goals. Once achieved, you may find room to re-add
those other verticals on top of a stable foundation.
-gabriel
I don't understand what you mean by fragmented developers. There are
developers working on various MeeGo implementations, due to their
interests in the respective implementations. I don't see how that can be
called fragmentation. Fragmentation would be, e.g. if you had several
developers working on different variations of the same GSM modules.
If there are developers currently working on handset, and they wish to
continue this work, then let them. If there are developers currently
working on tablet or IVI, and they want to keep developing for these,
then why stop them? Closing off access to various portions of what is
supposed to be an open-source project is counterintuitive, especially at
a time when MeeGo has been abandonned by Nokia/Intel.
What we need now more than ever is to *attract* active development, not
stifle it.
Dayo
___
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-community] MeeGo as a vehicle for Qt-based products?
On Sat, Oct 1, 2011 at 10:20 AM, Michael Hasselmann micha...@openismus.com wrote: On Sat, 2011-10-01 at 10:13 -0500, Gabriel Beddingfield wrote: With Intel removing the lion's share of those developer resources... it would be foolish to continue that failed approach. It sets everyone up for failure. I feel as if you over-estimate Intel's software development efforts for MeeGo. Well... MeeGo loses Auke... and that's pretty darn big IMHO. :-) I'm not going to bicker over head count or even quality. You wanna support 5 verticals, go ahead. Make us all proud. I think it's a plan for failure. full_disclosure I'm all talk. At this moment, and for the past few months, I can't commit any time to MeeGo (or even Tizen). But I really dig MeeGo for several reasons... mostly the native/Qt API's... so I hope(d) to see it succeed as a main-stream mobile OS. /full_disclosure -gabriel ___ 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-community] MeeGo as a vehicle for Qt-based products?
Code is Code is code, move your repos into a different eco-system that runs on top of the open linix kernel, and beam yourself up dude dudettes, Best George George Ingram Computer Scientist Winner Intel Coders Challenge 2010 http://www.linkedin.com/in/georgeingramcom/ 503 East Nifong Blvd I Suite 167 Columbia Missouri 65201-3792 Voice 804-464-7257 -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Angel Perles Sent: Saturday, October 01, 2011 10:15 AM To: meego-dev@meego.com Subject: Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products? I consider that a kind of reference UI experience and demo is fundamental for Meego. Probably a good starting point could be the incorporation of KDE + Wayland in this area. Also, it could be interesting to talk to guys at projects like Openmoko, GPE, etc to join efforts and to avoid fragmentation of efforts. An important issue is the lack of drivers from modern pieces of hardware, for example TIs OMAP 3xxx has not public drivers (open or closed) for hardfp's ARM Meego 1.2. Hardware manufactures (TI, Qualcom, Samsung, ...) must deal with the requisites of its customers (Nokia, Microsoft, Google, Samsung-2, ...) and not provide drivers for this kind of projects. As we all assume, Microsoft has blocked Meego project with its alliance with Nokia. Well done, Microsoft. Its is not necesary to continue with the name of Meego, it could be something similar to OpenOffice-FreeOffice. If trademark problems. Regards, Àngel El 29/09/11 17:37, Robin Burchell escribió: Hi, On Thu, Sep 29, 2011 at 5:20 PM, Nasanas...@comcast.net wrote: So I'll shed some light on how I see this and how we should proceed: 1) Concentrate on the handset and *ONLY* on it from now onward. Do one thing and do it best (tm). Why would you exclude 4/5 of the people involved in the meego project? Handsets weren't even the largest part of the project... Personal area of interest, perhaps. Anyway, we don't need to exclude anyone here - anyone can come and play ball. In my view of the ideal MeeGo universe, UX is entirely seperate projects from MeeGo itself - MeeGo Core is just the basics needed to boot and get to a display, hardware adaptations and user interfaces are outside of scope there. All the best, Robin ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- * Angel F. Perles Ivars Departament d'Informàtica de Sistemes i Computadors - DISCA Universitat Politècnica de València - E.U.Informàtica Cami de Vera s/n. 46022-Valencia Edifici 1G Despatx 2S-13 e-mail: aper...@disca.upv.es Telf.+34 963877007 Ext. 75775 Fax.+34 963877579 http://www.disca.upv.es/aperles ___ 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-community] MeeGo as a vehicle for Qt-based products?
All your missing is the free food and conferences, and the advocates that
did very little anyway other than make interesting comments anyway...
George Ingram Computer Scientist
Winner Intel Coders Challenge 2010
http://www.linkedin.com/in/georgeingramcom/
503 East Nifong Blvd I Suite 167
Columbia Missouri 65201-3792
Voice 804-464-7257
-Original Message-
From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On
Behalf Of Gabriel Beddingfield
Sent: Saturday, October 01, 2011 10:13 AM
To: Dayo
Cc: meego-dev@meego.com
Subject: Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based
products?
On Sat, Oct 1, 2011 at 7:56 AM, Dayo roneywo...@googlemail.com wrote:
Fine... pick IVI. Pick *something*.
MeeGo's complexity ({Netbook,Handset,IVI,Tablet} x {i586,armv7} x
{MeeGoCompliance,PlatformCompliance,DeviceCompliance}) was
apparently too much to bear even with corporate sponsorship. If you
continue as a community project, it's important to narrow this down
in order to succeed.
++1 That is why I said so the first place. Trying to do everything
++and
in the same time proved us very wrong.
I don't see a problem with keeping the various implementations of
MeeGo alive, if there are people interested in contributing to them.
Naturally, if a project receives no active contributions it goes stale
and dies, but why kill it preemptively?
Many of us believe that supporting all the verticals and profiles failed
because it fragmented developers... and there were not enough developers to
support it all. I honestly believe that it is a large reason why MeeGo has
been more or less floundering.
With Intel removing the lion's share of those developer resources...
it would be foolish to continue that failed approach. It sets everyone up
for failure.
By re-focusing the goals to ONE THING... the hard-to-rely-on community
development model (*cough*Debian*cough*) has a reasonable chance of
accomplishing those goals. Once achieved, you may find room to re-add those
other verticals on top of a stable foundation.
-gabriel
___
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-community] MeeGo as a vehicle for Qt-based products?
On 10/01/2011 11:19 AM, Gabriel Beddingfield wrote: On Sat, Oct 1, 2011 at 10:20 AM, Michael Hasselmann micha...@openismus.com wrote: On Sat, 2011-10-01 at 10:13 -0500, Gabriel Beddingfield wrote: With Intel removing the lion's share of those developer resources... it would be foolish to continue that failed approach. It sets everyone up for failure. I feel as if you over-estimate Intel's software development efforts for MeeGo. Well... MeeGo loses Auke... and that's pretty darn big IMHO. :-) I'm not going to bicker over head count or even quality. You wanna support 5 verticals, go ahead. Make us all proud. I think it's a plan for failure. Why so much fuss about the different verticals? This is up to the interest of the different volunteers, if someone wants to work in a specific area, let it be; as long as there exist certain coordination and a modular way of communication between the groups (as I earlier proposed), everything should be fine, there is no need to set in stone the exclusion of any of the verticals, or exclusively narrow down MeeGo to a single one. --- Luis ___ 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-community] MeeGo as a vehicle for Qt-based products?
I feel as if you over-estimate Intel's software development efforts for MeeGo. Lets be realistic, what there is left, really, after N+I has left the building? - Jarmo ___ 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-community] MeeGo as a vehicle for Qt-based products?
On 10/01/2011 10:29 PM, Jarmo Kuronen wrote: I feel as if you over-estimate Intel's software development efforts for MeeGo. Lets be realistic, what there is left, really, after N+I has left the building? - Jarmo ___ How about the MeeGo community? ___ 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 as a vehicle for Qt-based products?
On 09/29/2011 09:33 AM, Robin Burchell wrote: So Intel has upped and gone Tizen. What I wonder is: does this have to actually spell the end of MeeGo? Definitely not. MeeGo has been intended as an open source project since the very beginning, and that means: let's keep the ball rolling. In the past few days, we have seen that there is definitely a community of individuals wanting to continue building products using Qt (or simply writing apps using Qt on mobile), and MeeGo Core was a good vehicle to enable making that happen. I wonder what the wider community thinks about continuing work on MeeGo, if necessary, without Intel - perhaps theoretically aligning with Tizen to minimise workload ( share apps) if possible. I think the community is really interested on continuing this work, and as we most of all clearly know, MeeGo being an open source platform, then why not? ... this shouldn't stop _anyone_ interested on MeeGo to continue its development, deployment or even evangelization ;) In this thread, we have already seen how some users have pointed out interest for that to happen, and also the interest that certain companies and even external projects have towards MeeGo, so my opinion is just welcome all that support and invitations, and let the symbiosis begin. About Tizen, well, I guess we need to wait until they release further information about it (according to its website front page, within the upcoming weeks), and that way we can know better how MeeGo could cooperate and benefit from Tizen, we then would define the kind of symbiosis we want with such a project. they also promise an easy transition for MeeGo developers and users, so this is a very good sign, if it is like it sounds , I think both projects could really gain a lot. Obviously, we'd probably need to rethink some things like project governance, infrastructure, etc - but provided these can be solved, what do you all think? Can it be business as usual? Of course, the current situation does change the scenario, we would need to re-think many things now, but hey, this isn't necessarily a bad thing, this could even be a great and good thing to do, in my opinion, this is the time to discuss more openly the road the community wants MeeGo to take this might also be the perfect time to address any issue we have wanted to change or improve for some time .. This is the Time :) One thing I really would like to see it is some kind of announcement about the current project in the general technical level, code, packages, OBS, infra, docs, translations, wiki pages what will happen with all this?, for how long the infra machines will be available?, how about OBS access to Core repos?, Do we still need it or we can do fine mirroring everything in a community server and working from there?, what about the web pages? ... and so on and so on ... , MeeGo lifespan has been small, compared with other open source community projects, but in my opinion its contribution has been really big for the community itself in many aspects, and we should try to include all we can during this transition (if possible, and as long as someone is interested to do that work). --- Luis ___ 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...
On Thu, Sep 29, 2011 at 7:07 AM, Peter Jespersen flywh...@illogical.dkwrote: Den 29-09-2011 00:46, Clint Christopher Cañada skrev: It's kinda disappointing though with what's happening. Burned me once, that's ok, burned me twice, fine, but the third time (after speaking about Meego in some other engagements)? You've got to have a pretty good reason why I'm gonna trust this new development. Got the same feeling here In short why ? Is this a way to make further distance from Nokia (Qt) via a rebranding ? Is it because you feel that MeeGo is getting nowehere (even though real units has seen the light of day) and that LiMo has a better chance (better support from hardware manufacturers) ? Is it Intel ? What does the Genivi Alliance have to say ? I don't speak for the GENIVI Alliance. But from where I sit I see GENIVI is a set of automotive middleware that runs on a number of operating systems in a number of configurations. MeeGo is only one of those operating systems, there are a number of others. A quick search for GENIVI compliance will likely turn up some press releases about who else has a GENIVI compliant distro. Regards, Jeremiah And why this secrecy ? Also it does sound a bit like Tizen will be LiMo-based Live long and prosper... __**_ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/**listinfo/meego-devhttp://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_**list_guidelineshttp://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
[MeeGo-dev] MeeGo as a vehicle for Qt-based products?
So Intel has upped and gone Tizen. What I wonder is: does this have to actually spell the end of MeeGo? In the past few days, we have seen that there is definitely a community of individuals wanting to continue building products using Qt (or simply writing apps using Qt on mobile), and MeeGo Core was a good vehicle to enable making that happen. I wonder what the wider community thinks about continuing work on MeeGo, if necessary, without Intel - perhaps theoretically aligning with Tizen to minimise workload ( share apps) if possible. Obviously, we'd probably need to rethink some things like project governance, infrastructure, etc - but provided these can be solved, what do you all think? Can it be business as usual? (I'm cross-posting to make sure the best audience sees this, but please, let's keep discussion on meego-community@) Best regards, 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-community] MeeGo as a vehicle for Qt-based products?
On Thu, Sep 29, 2011 at 15:03, Robin Burchell robin+me...@viroteck.net wrote: So Intel has upped and gone Tizen. What I wonder is: does this have to actually spell the end of MeeGo? No, but as you address - infrastructure is one of the biggest things. How long until LF/Intel turn off *.meego.com? Obviously, we'd probably need to rethink some things like project governance, infrastructure, etc - but provided these can be solved, what do you all think? Can it be business as usual? My governance proposal: http://wiki.meego.com/Blueprint Of course, that assumed that there were developers working on Core outside of this governance proposal. We'd also want something around trademarks... Comments welcome. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ 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-community] MeeGo as a vehicle for Qt-based products?
On Thu, Sep 29, 2011 at 5:03 PM, Robin Burchell robin+me...@viroteck.net wrote: Obviously, we'd probably need to rethink some things like project governance, infrastructure, etc - but provided these can be solved, what do you all think? Can it be business as usual? I believe so. In fact I think this could actually enable us to create a true open base truly governed by community perhaps similar to the Qt Open Governance project. I think we should align with Qt releases as much as we can as our *core* app dev technology. Through concentrating on rocking Qt support, we earn a lot of great technologies (including HTML5 if I read right the Qt5 direction) not to mention great SDK and documentation to engage and attract veteran and new developers. (I get people asking me all the time how to use Qt on Android, as the native tools for them more often then not do not provide the experience they know or heard of about Qt) So I'll shed some light on how I see this and how we should proceed: 1) Concentrate on the handset and *ONLY* on it from now onward. Do one thing and do it best (tm). 2) Invite contacts from any handset mfct. interested to tell us their requirements and what would make it attractive for them to use as a base and try to respond to these. Nokia seems the first natural company I would like to talk to. (Admittedly as a passionate Nokia fan, I would love to try and do something that would help Nokia to produce the next Linux phone if they ever want to do this again. People who are fans of other vendors could do the same) 3) Vendor involvement is only through having contacts but they do not steer the project, unless getting into steering based by merit and proving skills. Community steers it. They can make suggestion and help in implementation but through the normal community channels, as a community contributor. No precedence or short-lanes to vendors and participation rights are based *only* on merit. Related to (2) I talked with Qualcomm people back then before SF2011 (we were supposed to meet in SF) about MeeGo but there was some concerns back then due to the heavy vendor steering, perhaps now we could invite them aboard, presenting a pure community project. These are some steps I think we could take, I would propose to see how we can align as best with Qt Open Gov now and follow their governance structure. -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-community] MeeGo as a vehicle for Qt-based products?
- Original Message - On Thu, Sep 29, 2011 at 5:03 PM, Robin Burchell robin+me...@viroteck.net wrote: Obviously, we'd probably need to rethink some things like project governance, infrastructure, etc - but provided these can be solved, what do you all think? Can it be business as usual? I believe so. In fact I think this could actually enable us to create a true open base truly governed by community perhaps similar to the Qt Open Governance project. I think we should align with Qt releases as much as we can as our *core* app dev technology. Through concentrating on rocking Qt support, we earn a lot of great technologies (including HTML5 if I read right the Qt5 direction) not to mention great SDK and documentation to engage and attract veteran and new developers. (I get people asking me all the time how to use Qt on Android, as the native tools for them more often then not do not provide the experience they know or heard of about Qt) So I'll shed some light on how I see this and how we should proceed: 1) Concentrate on the handset and *ONLY* on it from now onward. Do one thing and do it best (tm). Why would you exclude 4/5 of the people involved in the meego project? Handsets weren't even the largest part of the project... Because Meego netbooks are fairly well-established, Intel will add APIs (application programming interfaces) to ensure applications written for them will work in Tizen, said Imad Sousou, director of the Intel Open Source Technology Center. Asus, Dell, Acer, Lenovo, HP and Toshiba have made Meego devices, but they have only a minimal presence in the market. On mobile, obviously, the situation is different in terms of deployment, Sousou said. Since there are few Meego phones in use, Intel has decided not to encumber Tizen with legacy APIs, he said. Nasa 2) Invite contacts from any handset mfct. interested to tell us their requirements and what would make it attractive for them to use as a base and try to respond to these. Nokia seems the first natural company I would like to talk to. (Admittedly as a passionate Nokia fan, I would love to try and do something that would help Nokia to produce the next Linux phone if they ever want to do this again. People who are fans of other vendors could do the same) 3) Vendor involvement is only through having contacts but they do not steer the project, unless getting into steering based by merit and proving skills. Community steers it. They can make suggestion and help in implementation but through the normal community channels, as a community contributor. No precedence or short-lanes to vendors and participation rights are based *only* on merit. Related to (2) I talked with Qualcomm people back then before SF2011 (we were supposed to meet in SF) about MeeGo but there was some concerns back then due to the heavy vendor steering, perhaps now we could invite them aboard, presenting a pure community project. These are some steps I think we could take, I would propose to see how we can align as best with Qt Open Gov now and follow their governance structure. -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 mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [MeeGo-community] MeeGo as a vehicle for Qt-based products?
Hi, On Thu, Sep 29, 2011 at 5:20 PM, Nasa nas...@comcast.net wrote: So I'll shed some light on how I see this and how we should proceed: 1) Concentrate on the handset and *ONLY* on it from now onward. Do one thing and do it best (tm). Why would you exclude 4/5 of the people involved in the meego project? Handsets weren't even the largest part of the project... Personal area of interest, perhaps. Anyway, we don't need to exclude anyone here - anyone can come and play ball. In my view of the ideal MeeGo universe, UX is entirely seperate projects from MeeGo itself - MeeGo Core is just the basics needed to boot and get to a display, hardware adaptations and user interfaces are outside of scope there. All the best, 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-community] MeeGo as a vehicle for Qt-based products?
On Thu, Sep 29, 2011 at 16:37, Robin Burchell robin+me...@viroteck.net wrote: Personal area of interest, perhaps. Anyway, we don't need to exclude anyone here - anyone can come and play ball. In my view of the ideal MeeGo universe, UX is entirely seperate projects from MeeGo itself - MeeGo Core is just the basics needed to boot and get to a display, hardware adaptations and user interfaces are outside of scope there. Agreed entirely; and this is why Blueprint wasn't a blog post - but instead the foundation of a living document. IMHO, one of the problems MeeGo suffered from was a lack of clarity on team responsibilities. Address that, the Governance and the direction, and we should be able to make something attractive to vendors (and contributors). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ 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-community] MeeGo as a vehicle for Qt-based products?
On Thu, Sep 29, 2011 at 6:37 PM, Robin Burchell robin+me...@viroteck.net wrote: Hi, On Thu, Sep 29, 2011 at 5:20 PM, Nasa nas...@comcast.net wrote: So I'll shed some light on how I see this and how we should proceed: 1) Concentrate on the handset and *ONLY* on it from now onward. Do one thing and do it best (tm). Why would you exclude 4/5 of the people involved in the meego project? Handsets weren't even the largest part of the project... Personal area of interest, perhaps. Anyway, we don't need to exclude anyone here - anyone can come and play ball. In my view of the ideal MeeGo universe, UX is entirely seperate projects from MeeGo itself - MeeGo Core is just the basics needed to boot and get to a display, hardware adaptations and user interfaces are outside of scope there. Personal area of interest, nobody should be excluded but I think we should consider managing the verticals team in a way that would enable each of them to progress without being delayed for parts they don't really need to use on the core, so for instance, tablet should not be delayed for GSM modem code and vice versa for handset if they do not need it for operation. -- -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] MeeGo...
By now, you may have read that The Linux Foundation, with the support of several other companies, announced a new project, Tizenhttps://tizen.org/, to build a new operating system for devices. This new project is first and foremost open source, and based on Linux. So it begs the question: why not just evolve MeeGo? We believe the future belongs to HTML5-based applications, outside of a relatively small percentage of apps, and we are firmly convinced that our investment needs to shift toward HTML5. Shifting to HTML5 doesn't just mean slapping a web runtime on an existing Linux, even one aimed at mobile, as MeeGo has been. Emphasizing HTML5 means that APIs not visible to HTML5 programmers need not be as rigid, and can evolve with platform technology and can vary by market segment. Granted, this is a judgment on our part on which reasonable people could disagree, but that's the conclusion I came to. But in the new project, a lot of things will be the same as they were in the MeeGo project. The Tizen project will reside within the Linux Foundation, will be governed by a Technical Steering Group, and will be developed openly with familiar and improved infrastructure. Much like MeeGo, the Tizen project will support multiple device categories, including Tablets, Netbooks, Handsets, Smart TV, and In-Vehicle Infotainment systems. Over the next couple of months, we will be working very hard to make sure that users of MeeGo can easily transition to Tizen, and I will be working even harder to make sure that developers of MeeGo can also transition to Tizen. I want to personally thank everyone who has participated in MeeGo over the past year and a half, and I encourage you to join us at Tizen.orghttp://Tizen.org. We hope to use what we learned from the MeeGo project to make Tizen successful, and I hope to see you participating in Tizen! Imad ___ 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...
On Wed, Sep 28, 2011 at 07:30, Sousou, Imad imad.sou...@intel.com wrote: Granted, this is a judgment on our part on which reasonable people could disagree, but that's the conclusion I came to. I disagree. The need of native apps will never go away. Tell me how an HTML5 app will interface to a camera or gps device, for instance. Tell me how it will do crypto certificates (in Javascript?). Java also won't go away. The OS I want is one that can leverage all existing apps, Java ME, native linux, or yes, even HTML5, but does not engage in religious evangelism of one API over another. FC -- Nunca te pelees con alguien que ya no tiene nada que perder -anónimo ___ 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...
On Wed, 2011-09-28 at 07:57 -0300, Fernando Cassia wrote: Tell me how an HTML5 app will interface to a camera or gps device, for instance Something like this I guess: http://www.w3.org/TR/html-media-capture/ http://www.w3.org/TR/geolocation-API/ Ross ___ 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...
On Wed, Sep 28, 2011 at 08:03, Ross Burton r...@linux.intel.com wrote: Something like this I guess: http://www.w3.org/TR/html-media-capture/ http://www.w3.org/TR/geolocation-API/ Ross Let's re-do everything Java ME has done, with ugly interpreted Javascript... Yay... FC ___ 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...
Hi, I disagree. The need of native apps will never go away. Tell me how an HTML5 app will interface to a camera or gps device, for instance. This can also be done using something like PhoneGap (http://docs.phonegap.com/) which exposes native mobile device apis and data to JavaScript. It builds for Android, iOS, Blackberry, Symbian, WebOS and Bada through an automated build system (https://build.phonegap.com/) which is currently in Beta but which seems to be stable enough to at least get get you started on building cross platform mobile apps Regards -- http://ianlawrence.info ___ 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...
On Wed, Sep 28, 2011 at 1:03 PM, Ross Burton r...@linux.intel.com wrote: On Wed, 2011-09-28 at 07:57 -0300, Fernando Cassia wrote: Tell me how an HTML5 app will interface to a camera or gps device, for instance Something like this I guess: http://www.w3.org/TR/html-media-capture/ http://www.w3.org/TR/geolocation-API/ Those documents only show how you pass audio, media, and other streams into HTML. It doesn't describe how you actually drive the hardware or how you connect the hardware to the operating system. While this answers the question how will an HTML5 app interface with a camera it doesn't obviate the need for native drivers and modules to talk to the hardware, which was partly the OP's point. Regards, Jeremiah Ross ___ 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...
I'm very sad about Meego, when I start to read I thought that Meego will be a different distribution, different of default(Android, iOs, or WP7), but let's see this Tizen, I hope that Tizen be better and more comercial than Meego 2011/9/28 Jeremiah Foster jeremiah.fos...@pelagicore.com On Wed, Sep 28, 2011 at 1:03 PM, Ross Burton r...@linux.intel.com wrote: On Wed, 2011-09-28 at 07:57 -0300, Fernando Cassia wrote: Tell me how an HTML5 app will interface to a camera or gps device, for instance Something like this I guess: http://www.w3.org/TR/html-media-capture/ http://www.w3.org/TR/geolocation-API/ Those documents only show how you pass audio, media, and other streams into HTML. It doesn't describe how you actually drive the hardware or how you connect the hardware to the operating system. While this answers the question how will an HTML5 app interface with a camera it doesn't obviate the need for native drivers and modules to talk to the hardware, which was partly the OP's point. Regards, Jeremiah Ross ___ 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 ___ 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...
On Wed, Sep 28, 2011 at 15:31, Jeremiah Foster jeremiah.fos...@pelagicore.com wrote: On Wed, Sep 28, 2011 at 1:03 PM, Ross Burton r...@linux.intel.com wrote: On Wed, 2011-09-28 at 07:57 -0300, Fernando Cassia wrote: Tell me how an HTML5 app will interface to a camera or gps device, for instance Something like this I guess: http://www.w3.org/TR/html-media-capture/ http://www.w3.org/TR/geolocation-API/ Those documents only show how you pass audio, media, and other streams into HTML. It doesn't describe how you actually drive the hardware or how you connect the hardware to the operating system. While this answers the question how will an HTML5 app interface with a camera it doesn't obviate the need for native drivers and modules to talk to the hardware, which was partly the OP's point. It also doesn't answer what would you be able to do with the content you get from camera and audio samples. There are some examples on how you could achieve computational photography and audio processing tasks in Javascript but that is still in early infant stages. One will need to make native modules (to what? to JS engine?) to be able to process those using all power of the device in question. -- / Alexander Bokovoy ___ 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...
The APIs only show media streams being parsed through HTML. Interpreted languages are still developing and can sill be surpassed by compiled languages such as C/Python. On 28/09/2011 13:31, Jeremiah Foster wrote: On Wed, Sep 28, 2011 at 1:03 PM, Ross Burton r...@linux.intel.com mailto:r...@linux.intel.com wrote: On Wed, 2011-09-28 tel:2011-09-28 at 07:57 -0300, Fernando Cassia wrote: Tell me how an HTML5 app will interface to a camera or gps device, for instance Something like this I guess: http://www.w3.org/TR/html-media-capture/ http://www.w3.org/TR/geolocation-API/ Those documents only show how you pass audio, media, and other streams into HTML. It doesn't describe how you actually drive the hardware or how you connect the hardware to the operating system. While this answers the question how will an HTML5 app interface with a camera it doesn't obviate the need for native drivers and modules to talk to the hardware, which was partly the OP's point. Regards, Jeremiah Ross ___ MeeGo-dev mailing list MeeGo-dev@meego.com mailto: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 mailto: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 ___ 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...
On Wed, Sep 28, 2011 at 10:42 PM, S. Howard howa...@gmx.co.uk wrote: The APIs only show media streams being parsed through HTML. Interpreted languages are still developing and can sill be surpassed by compiled languages such as C/Python. Eh? Python is not compiled, it is interpreted. 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...
My bad, I meant C/C++. Cheers, Si. On 28/09/2011 22:11, Jeremiah Foster wrote: On Wed, Sep 28, 2011 at 10:42 PM, S. Howardhowa...@gmx.co.uk wrote: The APIs only show media streams being parsed through HTML. Interpreted languages are still developing and can sill be surpassed by compiled languages such as C/Python. Eh? Python is not compiled, it is interpreted. 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...
I do agree with the sentiment though. I've personally done some programming apps in android using an open framework that uses html and javascript but, although it does provide access to hardware, like gps, the camera and media, for more advanced functionality, you'd have to go back to adding that functionality through java. HTML/js is good for rapid deployment, however, nothing beats C and other compiled languages. It's kinda disappointing though with what's happening. Burned me once, that's ok, burned me twice, fine, but the third time (after speaking about Meego in some other engagements)? You've got to have a pretty good reason why I'm gonna trust this new development. Cheers, Clint On 9/29/2011 6:30 AM, Si Howard wrote: My bad, I meant C/C++. Cheers, Si. On 28/09/2011 22:11, Jeremiah Foster wrote: On Wed, Sep 28, 2011 at 10:42 PM, S. Howardhowa...@gmx.co.uk wrote: The APIs only show media streams being parsed through HTML. Interpreted languages are still developing and can sill be surpassed by compiled languages such as C/Python. Eh? Python is not compiled, it is interpreted. 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...
Burned me once, that's ok, burned me twice, fine, but the third time (after speaking about Meego in some other engagements)? You've got to have a pretty good reason why I'm gonna trust this new development. +one with the same feeling. 2011/9/28 Clint Christopher Cañada clint...@ostalks.com: I do agree with the sentiment though. I've personally done some programming apps in android using an open framework that uses html and javascript but, although it does provide access to hardware, like gps, the camera and media, for more advanced functionality, you'd have to go back to adding that functionality through java. HTML/js is good for rapid deployment, however, nothing beats C and other compiled languages. It's kinda disappointing though with what's happening. Burned me once, that's ok, burned me twice, fine, but the third time (after speaking about Meego in some other engagements)? You've got to have a pretty good reason why I'm gonna trust this new development. Cheers, Clint On 9/29/2011 6:30 AM, Si Howard wrote: My bad, I meant C/C++. Cheers, Si. On 28/09/2011 22:11, Jeremiah Foster wrote: On Wed, Sep 28, 2011 at 10:42 PM, S. Howard howa...@gmx.co.uk wrote: The APIs only show media streams being parsed through HTML. Interpreted languages are still developing and can sill be surpassed by compiled languages such as C/Python. Eh? Python is not compiled, it is interpreted. 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 -- Leonardo Luiz Padovani da Mata International Syst S/A Metasys Tecnologia Software Engineer Metasys MeeGo Team leonar...@metasys.com.br +55-31-3503-9040 May the force be with you, always Nerd Pride... eu tenho. Voce tem? ___ 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...
On 09/28/2011 08:14 PM, Ian Lawrence wrote: Hi, I disagree. The need of native apps will never go away. Tell me how an HTML5 app will interface to a camera or gps device, for instance. This can also be done using something like PhoneGap (http://docs.phonegap.com/) which exposes native mobile device apis and data to JavaScript. It builds for Android, iOS, Blackberry, Symbian, WebOS and Bada through an automated build system (https://build.phonegap.com/) which is currently in Beta but which seems to be stable enough to at least get get you started on building cross platform mobile apps Regards why we using something like this, for example, phonegap in bada system, just start a new bada app which then running HTML app on this, we still using this tech? I am sad about this approach. Thanks Steven Liu --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --- ___ 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...
Den 29-09-2011 00:46, Clint Christopher Cañada skrev: It's kinda disappointing though with what's happening. Burned me once, that's ok, burned me twice, fine, but the third time (after speaking about Meego in some other engagements)? You've got to have a pretty good reason why I'm gonna trust this new development. Got the same feeling here In short why ? Is this a way to make further distance from Nokia (Qt) via a rebranding ? Is it because you feel that MeeGo is getting nowehere (even though real units has seen the light of day) and that LiMo has a better chance (better support from hardware manufacturers) ? Is it Intel ? What does the Genivi Alliance have to say ? And why this secrecy ? Also it does sound a bit like Tizen will be LiMo-based Live long and prosper... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] MeeGo Website Maintenance on Sept. 10th, 2011
There will be a brief period of inactivity on the meego.com site on Saturday Sept. 10th between 10:00AM PST and 12:00PM PST. You may not be able to access the site during this time as we upgrade to using the Bakery single sign-on module for our sites. It's likely you'll also need to re-login to these sites after this upgrade. Thanks for your patients. MeeGo IT Team ___ 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-qa] MeeGo Distribution Packages - product in the Bugzilla
Hi, Thanks Luis for your activity. You have been marked as a default assignee for the components you listed below. Br, Iekku From: ext Luis Araujo [mailto:luis.ara...@collabora.co.uk] Sent: 01 September, 2011 21:08 To: Pylkka Iekku (EXT-Ixonos/Tampere) Cc: meego-hand...@lists.meego.com; meego...@lists.meego.com; meego-dev@meego.com Subject: Re: [Meego-qa] MeeGo Distribution Packages - product in the Bugzilla On 09/01/2011 01:14 AM, ext-iekku.pyl...@nokia.commailto:ext-iekku.pyl...@nokia.com wrote: Hi, Here's quote from the mail about the changes in the Bugzilla's Hanset UX. On Wed, 2011-08-31 at 07:06 -0700, Arjan van de Ven wrote: I'm ignoring meego bugzilla as useless unless it has a 1:1 mapping between packages and components That mapping has been in place for a while. Check Classification = MeeGo Platform Product = MeeGo Distribution Packages. Andre I started to wonder how many knows about the Bugzilla Product for MeeGo Distribution Packages. The product is not in so wide use as I was expecting, maybe because it's meant for the MeeGo 1.3. I hope it's going to be in use later on. I notices also that none of the components have QA-contact. This needs to be fixed. I found out also that all components doesn't have default assignee. That needs to be fixed also. Following component are having default assignee 'need-maintainer @meego.bugs'. Sorry, I know this list is very long, but the components are in the alphabetical order with short description: meegotouch-feedback MeeGo Touch feedback infrastructure meegotouch-feedbackreactionmaps MeeGo Touch Feedback ReactionMaps Plugin meegotouch-inputmethodbridgesMeego Input Method Client IMContext for GTK and CLUTTER meegotouch-inputmethodengine Meego UI Input Method Engine meegotouch-inputmethodframework MeeGo UI Input Method Framework meegotouch-inputmethodkeyboard MeeGo Virtual Keyboard Not sure what it is the procedure to request assignee for these packages, but I let you know here that you can make me default assignee for these meegotouch-* packages. Regards, ___ 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-qa] MeeGo Distribution Packages - product in the Bugzilla
On 09/01/2011 01:14 AM, ext-iekku.pyl...@nokia.com wrote: Hi, Here's quote from the mail about the changes in the Bugzilla's Hanset UX. On Wed, 2011-08-31 at 07:06 -0700, Arjan van de Ven wrote: I'm ignoring meego bugzilla as useless unless it has a 1:1 mapping between packages and components That mapping has been in place for a while. Check Classification = MeeGo Platform Product = MeeGo Distribution Packages. Andre I started to wonder how many knows about the Bugzilla Product for MeeGo Distribution Packages. The product is not in so wide use as I was expecting, maybe because it's meant for the MeeGo 1.3. I hope it's going to be in use later on. I notices also that none of the components have QA-contact. This needs to be fixed. I found out also that all components doesn't have default assignee. That needs to be fixed also. Following component are having default assignee 'need-maintainer @meego.bugs'. Sorry, I know this list is very long, but the components are in the alphabetical order with short description: meegotouch-feedback MeeGo Touch feedback infrastructure meegotouch-feedbackreactionmaps MeeGo Touch Feedback ReactionMaps Plugin meegotouch-inputmethodbridgesMeego Input Method Client IMContext for GTK and CLUTTER meegotouch-inputmethodengine Meego UI Input Method Engine meegotouch-inputmethodframework MeeGo UI Input Method Framework meegotouch-inputmethodkeyboard MeeGo Virtual Keyboard Not sure what it is the procedure to request assignee for these packages, but I let you know here that you can make me default assignee for these meegotouch-* packages. Regards, ___ 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-handset] Changes in the MeeGo Bugzilla for Handset User Experience
Hi all, Want to remind about the changes. I haven't received any comments about the adding other UX stuff to Handset UX. See all the conversation from: http://lists.meego.com/pipermail/meego-handset/2011-July/thread.html Shane Bryan replied for the original proposal and libseaside is staying as it is. Any other comments? Br, Iekku From: meego-handset-boun...@lists.meego.com [mailto:meego-handset-boun...@lists.meego.com] On Behalf Of ext ext-iekku.huttu...@nokia.com Sent: 12 July, 2011 12:08 To: meego...@lists.meego.com; meego-hand...@lists.meego.com; meego-relea...@lists.meego.com; meego-dev@meego.com Subject: [Meego-handset] Changes in the MeeGo Bugzilla for Handset User Experience Hi all, There's going to be some changes in the MeeGo Bugzilla Handset User Experience. Back ground for the changes: Handset UX isn't fully maintained and currently there's no activities for 1.3. N900 CE project is only who is maintaining / developing anything to Handset UX and when bugs are fixed in CE the fixes are also available to add to the MeeGo release. For more information about the N900CE, please visit: http://wiki.meego.com/ARM/N900 Since N900 CE is maintaining it makes sense to change the default assignee and QA contact for a people who are actually working with the maintenance/development. And since some parts aren't currently maintained, the bugs are going to be closed as wontfix. By that we don't lose any information and if someone is willing to make patches/fixes, they can do that, even if bug is marked as a wontfix. Please, feel free to take a look :) There's still components without default assignee (question marks in the name or instead of the name), if you are willing to take the action, contact me. I'm going to wait 2 workdays to get the feedback before doing the changes, any comments and ideas are welcome. Bugzilla components, and the coming changes: Applets: Doesn't exist in the Handset, all bugs going to be closed as a wontfix. After that requesting to delete the component. Audio Player: Is in use at CE, most critical bugs are fixed. Default assignee: ??, QA contact: iekku? Calendar: CE is using the Tablet UX calendar -- all bugs are going to be closed as wontfix Camera Application: in active development, new default assignee: Joonas Taskinen, new QA contact: Srikanth Connectivity UI: component itself is useless, since the whole Connectivity UI is part of Settings (or part of System UI), current bugs are going to be moved under correct component and after the moving requesting to delete the component. Contacts: in use and under maintenance Default assignee: tswindell?, QA contact: Srikanth Dialer: stays as it is DuiHome: Name will be changes to MeegoTouchHome. Default assignee mirek, QA contact: Srikanth Email client: not in use, every bug is going to be closed as wontfix. Generic: default assignee will be changed to Marko Saukko Instant Messaging: Not in use at CE -- all bugs are going to be closed as wontfix libseaside: is in use. Default assignee: ??, QA contact: ?? Package Manager UI: stays as it is Photo Viewer: is in use and maintaining is ongoing. Default assignee: alexandr.ivanov/ daniil.chuiko?? and Default QA contact Srikanth Settings: is in use and maintaining is ongoing. Default assignee will be gabor and Default QA contact Srikanth SMS: stays as it is Social Networking: Not in use at CE -- all bugs are going to be closed as wontfix Status menu: bugs are going to move to System UI and after that requesting to delete the component. Sync UI: Not in use at CE -- all bugs are going to be closed as wontfix System UI: Is in use, Default QA contact will be changed to Srikanth Theme: Is in use and Default assignee will be mirek and Default QA Srikanth UI infrastructure: all bugs are moved to OS Base - libmeegotouch, after that requesting to delete the component. UX stability: all bugs are moved to OS Base - libmeegotouch, after that requesting to delete the component. Video Player: in use and under maintenance Default assignee: ??, QA contact: iekku? Web Browser: stays as it is Window Management: Default assignee is changed to mirek About the current bugs: * All NOT ARM related bugs are going to be directly WONTFIX, cause no official support / maintenance currently for IA. Br, Iekku Huttunen MeeGo Computers Core System Testing / Error manager +358 40 749 0894 ___ 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-handset] Changes in the MeeGo Bugzilla for Handset User Experience
On 8/31/2011 12:16 AM, ext-iekku.pyl...@nokia.com wrote: Hi all, Want to remind about the changes. I haven’t received any comments about the adding other UX stuff to Handset UX. See all the conversation from: http://lists.meego.com/pipermail/meego-handset/2011-July/thread.html Shane Bryan replied for the original proposal and libseaside is staying as it is. Any other comments? I'm ignoring meego bugzilla as useless unless it has a 1:1 mapping between packages and components so go ahead, change what you want, I won't notice ;-) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
