[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?
Fernando wrote: > On Fri, Sep 30, 2011 at 14:40, 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] 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] MeeGo as a vehicle for Qt-based products?
About the original point in the subject of this thread: a Tizen architecture draft would be useful in order to know what to do. Even a markitecture diagram would help. Without that it's difficult to discuss the best approach for Qt in relation to Tizen releases and/or future MeeGo. Apart from the scarce official information, the only interesting Qt related detail is Nomovok saying that they can offer Qt integrated to Tizen. From there I understand that there is somewhere enough technical information available to make such a decision. That is exactly the same information Robin and other developers and stakeholders would need in order to make the right decisions. Qt is cutting edge technology and for the Qt Project mobile Linux is an essential platform. If Tizen becomes a cutting edge mobile Linux platform and if Qt can technically run there, then it makes sense to think that someone will work on Qt support for Tizen releases. However, I enjoy speculation as little as you do and with the current lack of information this assumption is probably as far as we can go. -- 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] 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
[MeeGo-dev] Web interface for MeeGo packages
Hi, would your work benefit from a searchable web interface of MeeGo packages, à la http://packages.debian.org , http://packages.opensuse-community.org/ etc? If so, your feedback and votes are welcome at Provide a searchable web interface / package index for MeeGo (like packages.debian.org) https://bugs.meego.com/show_bug.cgi?id=7072 Thanks! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
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
Re: [MeeGo-dev] Using "meego" or similar in packages and distro names
Gabriel wrote: >> 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. > Right now, it *appears* that the LF's position is that you > must rename the package if you (a) make major changes and/or > (b) repackage it for another distro. I can't speak for > other licenses, but this isn't consistent with the (L)GPL. This is why I took the time to list the potentially conflictive packages at http://wiki.meego.com/MeeGo_in_package_names Looking at Ibrahim's email there are two interesting points in relation to this discussion: > the goal is to avoid any confusion around what is and what is not MeeGo What are the packages on that list that could lead to that confusion? If there is any (I doubt) then the license of such packages needs to address this goal. If they don't then let's file the corresponding bugs. > when you append MeeGo to a package name, it would be very reasonable to > conclude > that this is an official MeeGo package coming from MeeGo.com When a distro uses any of the packages listed in the wiki page above without significant modifications, two remarkable things happen: 1. The "meego" string is already appended in the package name. The distro is not making any new attribution, it just keeps the current status. If the MeeGo project sees a problem in this, then either the naming or the licensing must be changed. 2. The "meego" string effectively explains that such package is an official MeeGo package coming from MeeGo.com - just being used in the context of another distribution. Again, if the MeeGo project finds that this is problematic then the solution is to change either the name or the licensing of the package. If these interpretations are correct, where is the problem then? -- 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. > ATT1..txt ___ 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 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
[MeeGo-dev] MeeGo Conference and *you*
Hi, remember that the call for session proposals for the MeeGo Conference ends on August 23. http://conference2010.meego.com/program MeeGo teams are expected to be involved in a session related to their MeeGo work, being a presentation, workshop, team meeting or BoF, etc. Probably many of you are leaving the submission of the proposal for tomorrow (that is actually my case!). Please don't forget about it. -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo for IVI v1.0.1 Released Today
Hi, Robin wrote: > Question: where is the IVI UX being developed? > > http://meego.gitorious.org/meego-ivi-ux looks very ..spartan.. :) Please file bugs about any issues you find related to MeeGo open development and project transparency, and make them blockers of MeeGo openness meta-bug http://bugs.meego.com/show_bug.cgi?id=4898 Thank you! -- Quim Gil ___ 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
Re: [MeeGo-dev] multimedia architecture
Hi, Narendranath Ghosh wrote: > I am looking for detailed meego multimedia architecture. is it > available some where. Have you checked http://meego.com/developers/meego-architecture/media-services ? > is it same as moblin? -- 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
[MeeGo-dev] Forum / mail integration (was MeeGo Summit - Structured brainstorming...)
> GET THE BLOODY THING FIXED! Reggie said that Forum/Mail integration would require more server power and proposed to wait until the meego.com infra is hosted at OSU OSL. forum.meego.com is not in OSU OSL yet and this is the main reason why we are stuck in this forum/mail integration. PS: yes, you are busy. No, you are not the only one. Yes, it's a good idea to have some respect for tho work others are doing. Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Repository Working Group - next steps
Hi, I think we have a mismatch between the name and the content. "Repository Working Group" is a problematic denomination, while most if not all your points are clear and probably easy to agree upon. "Repository" is a too broad concept: the whole MeeGo release sits in a repository and it's easy to get confused thinking that the scope is the whole repo = the whole release. The scope proposed is the repository/ies hosted at meego.com containing packages not officially supported in a MeeGo release. - The repos containing the MeeGo official release are out of scope. - The MeeGo compatible app stores managed by vendors or other third parties are out of scope BUT the tools and guidelines for those frontends would be within the scope of this team. Is this right? This is the first thing to agree upon. How to call this? Names carried from maemo.org or moblin.org would be "Downloads", "Extras" or "Garage". "Apps", "Addons", "Catalog" are also used in similar contexts. None of them is perfectly accurate but calling it "Universe/Multiverse" is probably not the best solution either. :) So what about "Downloads" as a compromise between clarity and accuracy? David Greaves wrote: > I think two main issues were raised: [2] > * Is a WG needed? At this point it is clear that "Working Groups" are being defined as teams primarily in charge of vision, strategy and roadmapping. The TSG plans to set up some of those for the different UX categories, and probably that's it. However, this doesn't affect the purpose, scope and "power" of this team if it gets up and running. Let's leave behing the "WG" and let's continuw with the definition work? "Downloads team". How does this sound necxt to the "Program Office"? (this is how the "Core team" could be called) > * Isn't this covered in the MeeGo 'Core' project structure? At least I don't see it. The Program Office has a clear mission which consists on shipping great MeeGo releases every 6 months. The proliferation of a great offering of additional software is a different mission that deserves its own focus. Can we discuss and agree first on all these general terms? Once they are clear and agreed it will be easier to agree on more specific details. Arjan said something in the MeeGo work group last week that got stuck in my little brain: any topic that ends up in the TSG is a failure in the system. :) There is no officially nominated responsible for this area but a key person is Bob Spencer from Intel. We discussed few weeks ago at Portland about how to approach the Downloads repository and how to introduce a reliable and community friendly QA process. All in all the maemo.org Extras process was seen as good source for inspiration - http://wiki.maemo.org/Extras For practical reasons, I would say that getting Bob on board and syncing with whatever are his ideas and plans is a first step in the right direction. If Bob is not in the loop or disagrees with the proposal then is quite pointless to jump to the TSG again. > [1]http://wiki.meego.com/Proposal_for_a_Repository_working_group > [2]http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-03-31-19.58.log.html#l-100 -- 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] 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?
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 > 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 > > > ATT1..txt ___ 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] 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] Instructions for ARM / N900 (was Re: Day 1 is here ...)
> I've a N900 and I'd like to test MeeGo, but I don't know which file to > download from here: http://repo.meego.com/MeeGo/devel/n900/images/ > and how to flash it into my device. Could you please give us some > instructions? Thanks. http://wiki.meego.com/ARM -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Organization of MeeGo team
Hi, > > what is the organization of the MeeGo team ? > > OK the project is led by Imad Sousou and Valtteri Halla, but how many > employees are on the project ? (and how many from nokia, compared to > intel ?) > > It's not clear on the website... > > Thanks > > I very much doubt that information like that is, or will be, > publically available. The organization will be publicly available. We are having the code dump release this week and with it more roles will be officially appointed. At some point all the key roles will be publicly available just like in a regular Linux distribution. The interesting number though, key for the success of the project, is not the comparison between Intel and Nokia contributors but the involvement of contributors with all kinds of affiliations, including competitors of Nokia or Intel and independents. -- Quim Gil + N900 open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [Meego-community] ANNOUNCE: Proposal for a Repository working group
Hi, > ANNOUNCE: http://wiki.meego.com/Proposal_for_a_Repository_working_group ... > Mission > > The Repository Working Group (RWG) would define and oversee > implementation of > the strategy for publishing community created software with the MeeGo > project. > > The goal of the RWG would be to unite the various community > contributions > interested in applications & libraries, packaging, policy, QA processes, > building, etc. It sounds like a good description of the goals of the "Extras / Downloads team" (final name to be defined) proposed at http://wiki.meego.com/Community_working_group#Web_infrastructure Is there any reason why this team couldn't be part of the Community WG? It's all about community software. -- 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] 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
[MeeGo-dev] TSG meeting moved to Wednesday 24
Hi, The Technical Steering Group just told us that the meeting needs to be moved to Wednesday 24 at 20h UTC. http://meego.com/community/events/2010/meego-technical-steering-group-meeting Anyway, this is a better time for the regular TSG bi-weekly meetings. -- Quim Gil + N900 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
