[MeeGo-dev] Community infra resources funds (was RE: MeeGo...)
Discussing resources funds is not as much fun as discussing brands or toolkits, but let me bring your attention to this point since it is probably important or plain critical for any plans forward discussed here. My assumption is that the current community doesn't have enough muscle to afford the whole cost of infrastructure of a project with the size and complexity of MeeGo. The options are either reuse free-as-in-beer infra from other projects or assure corporate sponsorship from different sources (I would trust less this one, but it is also a possibility). Imad Sousou wrote: I will be working even harder to make sure that developers of MeeGo can also transition to Tizen. 1. Can we get any details about the availability of the current meego.com infrastructure under Intel's funding? End of this year? July 2012? End of 2012? Later? The answer to this question helps figuring out the urgency for a move. 2. What is the scope we can expect for tizen.org in terms of community infrastructure? Will a fortizen.org like site be needed as well or the core tizen.org (plus AppUp?) will be inclusive enough to satisfy community initiative with a link to the Tizen project, even if it's indirect? The answer to this question helps figuring out the need to find/fund own infra for all the non-official development infra. Thank you. -- Quim ___ 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] Who will keep pushing MeeGo?
Dave wrote: and at best an improvement (HTML5 vs QML). Fwiw QML doesn't stop any HTML5 improvement. In fact it plays perfectly well with HTML Javascript next to its neighbor QtWebKit, and bridges web development with native development (if you need it) down to core C/C++. If you need additional features not covered that web engine/framework X provides, you can add such engine/framework or you can improve/add to the Qt web engine/framework. The strategic reasoning behind HTML5 is understandable: it is a general trend. The WAC part makes sense if you have a customer requiring it. Looking forward to the announcement of a native SDK and the reasoning behind it. And of course looking forward to see the work of the new Tizen stakeholders working on the Qt integration. The Qt Project will provide tools for them to make Tizen a first class Qt platform if they wish. -- Quim ___ 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] Who will keep pushing MeeGo?
Fernando wrote: On Fri, Sep 30, 2011 at 14:40, quim@nokia.com wrote: The strategic reasoning behind HTML5 is understandable: it is a general trend. And I personally think that trend sucks. It means throwing away all existing apps and reconverting them. The trend of using web technologies to cover the apps space is clear and pushed by many factors e.g. something simple to develop simple features and compatibility across the jungle of platforms. I actually agree with it. The questionable trend, that is not even a clear trend, is to put all the weight in web technologies dismissing the good and powerful native environment. Apart from few and very bold exceptions, even the platforms that started putting the bets on web ended up opening the door for native, and some of them even to very native. Surely the Tizen architects know this and I'm confident (but I don't have more info than you) that they will come up with a sensible web/native approach, regardless of the specific technologies used. -- Quim ___ 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] Announcing MeeGo 1.2 Developer Edition for N900
Arjan wrote: we've been bitten rather badly in MeeGo in the past in this respect (promising of features as part of architecture choices, but then never getting those open sourced) Anything documented to compare? What promised features are missing? We have lost something with this change of plans in the Nokia-Intel relationship in MeeGo, but we could gain real openness in the roadmapping and architecture processes now. At least I don't see any reason for Nokia to have non-public commitments with the MeeGo project, and this is why I'm asking the questions above. -- Quim ___ 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] Announcing MeeGo 1.2 Developer Edition for N900
Arjan wrote: (it'll run MeeGo and not Maemo I take it from the press releases)... It will run the release codenamed Harmattan, no news in that front. But this is a discussion off-topic in meego-dev and well discussed at http://forum.meego.com/showthread.php?t=2719 - feel free following there. -- Quim ___ 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 1.2 Roadmap?
Hi there, Carsten wrote: So, we're in 2011, we have a release 1.2 in about 4-5 months - and I wondered, what do we intend on delivering? See, comment, vote: Bug 9908 - Open roadmapping process defined but no implemented http://bugs.meego.com/show_bug.cgi?id=9908 I also think this is an important topic and I also expected more information or at least feedback from the roadmap owners at this point. I went to http://wiki.meego.com/Roadmap and looked, finding that we have a release plan (always good..) and plans related to the build infrastructure.. But no Core/Handset/IVI/SDK roadmaps. Nor on meego.com anywhere. The question is - and I think it's a fairly reasonable one: Where is our Core, Handset, Netbook, IVI and SDK roadmaps for 1.2? It's not on meego.com anywhere - how does our future platform 'customers' know what we plan to have coming for MeeGo 1.2? And second: What is the current status of them - where can I see the work in progress? Is there some featurezilla searches? Gavin, Sami, Rudolf, Ville and the rest of you guys responsible for MeeGo roadmaps - could I ask you to spend some few minutes elaborating to the rest of the project what's going on in Program Office regarding the roadmaps for 1.2 for your areas? It'll help people understand why these roadmaps may be missing and set up expectations to when we'll see them :) -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Using meego or similar in packages and distro names
Hi, let's see if we can move into specific details to find and fix whatever is problematic in this discussion about using anything close to meego in packages and distro names. About using meego or something similar to name a distro using MeeGo related components, the opinion of The Linux Foundation is clear. My simple interpretation of it is: thanks, but no thanks. Call it something completely different and off you go. About package names, since they are open source (LGPL, Apache...) there shouldn't be any problems redistributing them with the same name, isn't it. If there is a problem with the name or license of a specific package please let's file a bug and let's discuss and solve it in the context of that specific problem. I just took some time to compile the list of packages using meego currently in 1.1 trunk: http://wiki.meego.com/MeeGo_in_package_names What is really the problem? Apart from the fact that it is not good practice to carry the names of distros in package names of generic apps and libraries, it is not evident (at least to me) where the problems really rely. Packages using the meego string in the MeeGo releases seem to fall in these categories: * Applications developed by the MeeGo project within the UX categories. In general it is not a good practice to tie an open source app with the name of a distro. Also the MeeGo word doesn't appear in the UX of these apps. Should we consider the renaming of those packages, removing meego from them? * Packages related with the MeeGo Touch Framework. The branding of this framework was discussed and agreed, causing the actual renaming of the components (previously libdui). There is no problem in other distros willing to use the MeeGo Touch Framework. Is it clear the situation of branding and icons, though? Are they in isolated packages? * Upstream packages with specific MeeGo version/configuration. Not a big deal, between not useful or not problematic for other distros. * Packages intrinsically related to the MeeGo distro (configuration, branding, devtools). Not useful in the context of other distros. Progress in this discussion is measured in improvements to the current documentation and bugs filed/solved. If you file any bugs about this please CC me. Thanks! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Ryan Abel wrote: Why do we go back a few steps and figure out what goals we want to achieve with this and then we can find the best way to go about it. Simply put, we want to make it possible for an application developer to write a MeeGo compliant application once and run it on any MeeGo compliant device. http://wiki.meego.com/Quality/Compliance The Qt / Qt Mobility / Web Runtime game combined with the different UXs is already more complex than the setup offered by Android and iOS. We should find there all what it takes to build a great commercial developer offering under the compliance flag. http://lists.meego.com/pipermail/meego-dev/2010-September/005772.html MeeGo needs to offer a simple and crystal clear story for commercial developers. No matter how many additional options are also available in this Linux based open platform. the keys of app developer success must be contained in the MeeGo Core, MeeGo UX, MeeGo API and MeeGo SDK, based on Qt / Qt Mobility / Web Runtime. If MeeGo doesn't have commercial success with these elements then we can save the discussions about all the rest. These limitations and rigidness needed to succed in the commercial side shouldn't bother developers willing to play with the rest of combinations in a context of free software innovation and pure fun. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Website suggestion
Hi, I have one suggestion regarding MeeGo Website. Thank you for your ideas. We ask contributors to propose website features or improvements via http://bugs.meego.com . The more specific the easier is to discuss, agree and implement. For the rest, the meego-community list is the right place to discuss about meego.com. meego-dev is about platform development. Thank you! -- Quim Gil We can put some Flash Plugins for better User Experience Other than Static web pages we can put some Dynamic Webpage. I think it will improve the accessibility, Interaction, navigation factors Best Regards Hari. Attachment ATT1..txt ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Why game using as example box2d physics library should not called MeeGo compliant ? And it is just example of dozens similar helper libraries used by game and graphics developers. Because box2d is not included in MeeGo and a user of a MeeGo device with no access to e.g. extras has a high chance of getting confused. Multiply this for toolkits, devices, apps and users and you will see the MeeGo: what a mess! headlines coming to Engadget and the likes. Having Extras repository with some kind of peer quality control is much better than mesh with every application including these libraries legal or not so legal way. Not all devices will have access to Extras. not all users with access will be willing to have anything to do there. compliant is a commercial label and it's easy to tie it strictly to the commercial side: the vendor stores. Extras can still do whatever without the label compliant. Love that freedom! -- Quim Kate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Let's recap: MeeGo's promise is vertebrated basically through the MeeGo API. If we don't assure a MeeGo compliant app runs across MeeGo devices within a range of releases then the success of the project is at stage. This is already complex. You can see the problems you might get looking at the Android fragmentation, and the reactions it gets. The Qt / Qt Mobility / Web Runtime game combined with the different UXs is already more complex than the setup offered by Android and iOS. We should find there all what it takes to build a great commercial developer offering under the compliance flag. Then you have MeeGo Extras, hosted at meego.com and handled by the MeeGo community, containing compliant apps and also compatible apps departing from the MeeGo official API. The MeeGo commercial offering doesn't *require* Extras but can benefit from a successful Extras anyway. Letting Extras out of the Compliance program makes sense, especialy now that the comercial part still needs to be created and consolidated. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] Meego works great on Asus eee 701 with non Atom CPU
Hi, Valent Turkovic wrote: I tested Asus eee 701 that has plain Intel Celeron CPU with both Meego 1.0 image and Fedora 13 with Moblin, both versions work 100% and blazingly fast even on that small and underpowered device to Please help improving http://wiki.meego.com/Devices - thank you! There are actually several forum threads about this device model i.e. http://forum.meego.com/showthread.php?t=230 http://forum.meego.com/showthread.php?t=284 http://forum.meego.com/showthread.php?t=599 Also please avoid cross-posting to several mailing lists. meego-dev is not really a list for these topics. Please do not reply-all to this email now. -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Is there Meego SDK for Handset version?
Hi, Andrew Flegg wrote: What's the development environment of those working on the Handset UX; how are they managing to do development; and how do they get new employees up to speed quickly? Even if you might be targeting the Handset UX, the idea is that you can and will want to recycle as much work as possible for other UXs. For this reason the default starting point is Qt and the corresponding Qt SDK. Regular unstable MeeGo SDK builds are on its way, just not ready yet. In the meantime, those willing to get familiar with the environment can try the Nokia Qt SDK and have a look at the Qt 4.7 novelties. The architecture and the components are the same, it's only the targets that differ. If you want to speed up quickly then Qt Quick is a good choice. See http://qt.nokia.com/developer/qt-qtcreator-prerelease/ Note though that all these pieces are being integrated and polished as we speak. MeeGo 1.1 is not yet ready for application developers just looking for a stable and reliable environment. -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Opening MeeGo requirements
Hello, The process for handling MeeGo requirements is now open. Sami explains the details at http://meego.com/community/blogs/samipienimaki/2010/opening-meego-requirements Basically, http://bugs.meego.com is used as the tool for proposing features and manage requirements. There is now a new classification MeeGo Features where new proposals must be filed. There are already more that 240 features submitted, most of them targetting the MeeGo 1.1 release. http://bit.ly/d8lBCL The requirements process is managed in combination with the roadmapping process: http://meego.com/developers/meego-roadmap Please watch, vote and comment in the feature requests that matters you most. You are also invited to submit new proposals. -- Quim Gil MeeGo Community Office co-coordinator ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] presentation from MeeGo workgroup?
On Fri, Apr 16, 2010 at 11:35:22AM -0400, Dengyi Wang wrote: On 04/16/2010 11:14 AM, Greg KH wrote: On Fri, Apr 16, 2010 at 09:46:30AM -0400, Dengyi Wang wrote: Hi If you present on the MeeGo workgroup from Linux Foundation Collaboration Summit yesterday, is it possible for you to upload your presentation/moive/demo/... to http://meego.com/community/events/presentations Sorry, I had no slides, I just talked and then played a video that is on engadget :( Any lucky audience capture it in a video? There was someone in the audience videoing all of the talks, hopefully they will put them online soon. I didn't have slides either, only a flipchart to improvise basic organzation draft diagrams. There is a forum threrad where some of us added some comments. Maybe the participants in the workgroup and others with questions or answers can help squeezing that saucy day? http://forum.meego.com/showthread.php?t=52 Overall I think it was good, useful and interesting. A day full of questions and discussions followed by a little gathering with drinks and food that Amy organized so well (and she couldn't enjoy since she had to leave earlier...) Thanks Amy and thanks Dawn, who chaired the whole day (except the 20 mins she took for lunch). -- Quim Gil + N900 open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] how to start developing on MeeGo?
Hi, There is little info for a newbie to startup working on MeeGo from the meego.com website. Where can I find more info doc to instruct me to steup the enviroment, compile the kernel, test in kernel/service/app? Please help, thx We are still preparing the developer documentation for the first MeeGo release. The information currently available can be found at http://wiki.meego.com/Documentation_backlog Note that meego-dev focuses in the development of MeeGo itself. Support for application developers is offered in these channels where you might get more answers: Application developer support forum http://forum.meego.com/forumdisplay.php?f=3 meego-sdk mailing list http://lists.meego.com/listinfo/meego-sdk -- Quim Gil + N900 open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] how to start developing on MeeGo?
USA Linux UAE said: I am interested in Platform development, porting and packaging , waiting for OBS to open and core code to be available Then you might be interested watching Bug 615 - Open the access of MeeGo OBS http://bugzilla.meego.com/show_bug.cgi?id=615 -- Quim Gil + N900 open source advocate MeeGo Devices @ Nokia On Thu, Apr 15, 2010 at 7:37 PM, lucas azevedo lucasazeve...@gmail.com wrote: There is little info for a newbie to startup working on MeeGo from the meego.com website. Where can I find more info doc to instruct me to steup the enviroment, compile the kernel, test in kernel/service/app? Please help, thx We are still preparing the developer documentation for the first MeeGo release. The information currently available can be found at http://wiki.meego.com/Documentation_backlog Note that meego-dev focuses in the development of MeeGo itself. Support for application developers is offered in these channels where you might get more answers: Application developer support forum http://forum.meego.com/forumdisplay.php?f=3 meego-sdk mailing list http://lists.meego.com/listinfo/meego-sdk -- Quim Gil + N900 open source advocate MeeGo Devices @ Nokia Actually, I'm interested in both developing MeeGo applications and MeeGo itself. Thanks for the info :) Kind Regards, Lucas Azevedo ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev Attachment ATT1..txt ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Instructions for ARM / N900 (was Re: Day 1 is here ...)
Hi, I would prefer to buy a nokia n 900 with meego operating system. Therefore of course is a releasedate for the gui OS needed and a releasedate for the nokia n900. can anyone make the pojectplan open? You are mixing 2 things and only one of them is on-topic in meego-dev: - MeeGo project plans. They will come. Here is the right place to ask and request. - Nokia N900 product plans. Up to Nokia. The MeeGo project has nothing to say and here is not a place to ask or request. Even if the MeeGo project keeps releasing images for the N900 they will not have the content average Nokia users expect to find pre-installed in a Nokia device (mostly proprietary in the application layer and therefore not suitable for MeeGo project releases). -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Proposing topics to TSG meetings
Hi, We have put a light process in place to propose topics for the Technical Steering Group meetings: http://wiki.meego.com/TSG_meetings It is already valid for the next TSG meeting taking place next Wednesday (which looks like it will be a busy MeeGo day). :) -- Quim Gil + N900 open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] TSG meetings schedule (was Re: First TSG meeting...)
Hi, The suitable times for the TSG meeting are the times suitable for those having to take part in there. Obvious? :) The question is: who *must* attend the TSG meetings? Now we have 2 TSG members, no official working groups, no MeeGo roles officially apointed and a relatively large amount of individuals interested in whatever the TSG says in an IRC meeting. But this is only a transitional situation. Think of the scenario (to start developing soon) where dozens of MeeGo roles have a person appointed, where several working groups have their regular work ongoing including periodical meetings, where 1-2 people of each working group is meant to attend the TSG meetings to take part in the topics related to their work, and where the TSG itself has more than 2 people. Probably that day most people now interested in TSG meetings will not be that interested not to miss a single one. That day the agenda of an average TSG meeting can be perfectly a combination of formal decisions pushed by working groups, unsurprising appointments and other non-hot topics that can be perfectly followed through the instant meeting minutes published at meego.com. Also most of the questions you would like to address now to the TSG will be better addressd to the specific working group or the specific channel where the maintainers and specialists can be found. -- Quim Gil + N900 open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
