Re: [MeeGo-dev] Where to post bug reports for MeeGo 1.2 Harmattan?
(((This topic goes beyond meego-dev - I'm answering you here but if you have further questions I encourage you to go to forum.meego.com - Handset or Application Developer Support. Thanks!))) As explained at http://forum.meego.com/showpost.php?p=22953postcount=77 http://forum.meego.com/showpost.php?p=22981postcount=87 http://developer.nokia.com/bugs This bug reporting tool focuses on *developer issues*: platform, SDK, documentation, etc (the open source components). However, we have added a component Device where the developers getting the devices can also file bugs they are finding as testers of the device. After all the discussions (I still remember 'Bug 630' by heart) I think the best is to offer the bugzilla setup in relation to open source platform components and the Nokia support setup for the 'user experience' part. OSS savvy people understand bug reporting, may have a grasp on whether a bug belongs more to downstream or upstream, might look at source code, think of building a patch, discussions on features can happen in the relative OSS channels... Motivated users willing to get their voice heard by Nokia can go to Nokia Support Discussions or Nokia Care directly. Their ideas or complaints can't be addressed openly in a bug tracker as we have seen. And actually an organization like Nokia Care does a good job at summarizing and reporting up the feedback received through different channels (I have seen the reports and I wouldn't have done them better after following 100s of posts and bugs in maemo.org). On 6/22/2011 7:40 AM, ext Carsten Munk wrote: Submit them to your vendor, ie, Nokia (you'd have to ask them for where, because I don't know). Then they will submit it further to any upstream projects they use. The reasoning for this (even when ignoring the complete Harmattan mess) is these steps: 1) A vendor might have modifications to the upstream packages/software or own packages/software he uses. Then he should handle it 2) If no modifications/directly from upstream, submit to the upstream project - it's a bug in that software then. 3) Upstream may handle the issue and fix may trickle down to the consumer through the vendor's path of upgrades If you can replicate an error in MeeGo.com images/components directly, you're of course welcome to submit to those bugtrackers. Example could be a Qt or Qt Mobility issue that happens on MeeGo.com images too. /Carsten 2011/6/22 Andrey Ponomarenkoaponomare...@ispras.ru: Hi, Could anybody explain me where to post bug reports for MeeGo 1.2 Harmattan [1]? To maemo.org Bugzilla [2] or to MeeGo Bugzilla [3]? Thanks! [1] MeeGo 1.2 Harmattan [2] maemo.org Bugzilla [3] MeeGo Bugzilla -- Andrey Ponomarenko Department for Operating Systems at ISPRAS web:http://www.LinuxTesting.org mail: aponomare...@ispras.ru ___ 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 ___ 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 Conferece: non-commercial proposals are also welcome!
CROSSPOSTING ON PURPOSE - please reply only to meego-events. Loud and clear: 100% community - non-profit - hobbyist submissions are also welcome at the MeeGo Conference http://sf2011.meego.com/program/call-session-proposals Just like in Dublin. Hurry up! I'm sending this because I just realized at #meego IRC channel that many people thought the San Francisco conference was *exclusively* for commercial parties and topics like e.g. apps.meego.com or the community OBS were not wanted. Good that I asked and we found the problem. I'm not part of the content committee but I believe everybody in the conference organization assumes that any relevant community activity related to the MeeGo project is worth a submission proposal. -- 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] Urgent: We need community ftp space or similar
On Wed, 2010-12-01 at 09:21 +0100, ext Till Harbaum / Lists wrote: Hi list, i would really like to release some ready-to-run beagleboard meego image. But unfortunately we are missing a place to store files in the gigabyte range for public download. Other meego projects and even the n900/n8x0 adaption teams are facing the same problem. Can we please have such a place? Can you please submit a request at http://bugs.meego.com ? It's ok to send an email to meego-dev pointing to that request so anybody interested can chime in and follow, but discussing this whole request here is a bit overkill (with thousand of subscribers). Even meego-community would be more on-topic since it's there where the community infrastructure is discussed. Thank you for your understanding. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Agenda of TSG meeting *today*
Here is the agenda for the Technical Steering Group meeting held today - actually in a bit more than one hour, at 20:00 UTC. * MeeGo Compliance discussion update (Mark Skarpness). http://wiki.meego.com/Quality/Compliance * Quality Team nominations (Veli-Pekka Vatula). http://wiki.meego.com/Quality/meetings/QANominations101201 * Toolchain Change Proposal for MeeGo Release 1.2 (Jarmo Kant). http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal * Next TSG Meeting * All other business (Open Items and General Questions) More information about Technical Steering Group meetings at http://wiki.meego.com/Technical_Steering_Group_meetings See you there! -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Packaging Guidelines group tag for end user applications
On Tue, 2010-11-30 at 11:26 +0200, ext Niels Breet wrote: Hi, It seems that the list of group tags are specified in the Packaging Guidelines: http://wiki.meego.com/Packaging/Guidelines#Group_Tag This list looks like it needs some attention as the options are very limited and some are not relevant for a mobile devices platform like MeeGo. Can we come up with a list of categories which can be used in application store like apps and websites to sort end-user applications? A definitive list in the packaging guidelines would prevent unrestricted growth of groups used by developers and would make it a lot easier to discover apps through category lists. Very good point. This was a topic of discussion in maemo.org some time ago: http://wiki.maemo.org/Task:Package_categories (I'm not sure if this is the most recent page) Input from AppUp and Ovi would be useful. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo vs. Platform API ambiguity
On Thu, 2010-11-11 at 14:45 -0700, ext Wichmann, Mats D wrote: meego-dev-boun...@meego.com wrote: On Thu, Nov 11, 2010 at 01:27:44PM -0800, Andy Ross wrote: The subject of how the MeeGo API is defined came up in the TSG yesterday, and against my better judgement I managed to inject myself into a discussion about standards. The way it's currently phrased, the MeeGo API is a very limited set of libraries (Qt, QtMobility and GLES, plus the web framework). Everything else is reserved for the Platform API, which carries no promise of future availability. I have just recently read the developer pages on this very subject, and I was surprised to find the distinction, that Meego Touch Framework and the Web Runtime are in a Platform API with warnings against using them. More clarification is indeed needed, as far as I am concerned. In the case of these two, it's a question of maturity. Since the current versions aren't fully mature, it can't be promised they won't change in the next version. There's nothing to prevent, and indeed it's the intent, to promote these to high-guarantee status once the right level of maturity is reached. Actually this is not accurate. The mid term future of MeeGo Touch Framework and Web Runtime is not clear next to Qt / Qt Quick and HTML5. The components are in MeeGo 1.1 and the APIs are there for developers, but a good advice for new projects is to check Qt Quick first. About deeper APIs in the platform, the reason to push a well controlled set of APIs around Qt and Qt Mobility is not only based by the fact the components will be there in the future. It's also related to the possibility to manage the MeeGo API properly, offer a compatibility promise towards future releases, simplify the developer story, documentation, training materials... For the big majority of application developers targeting MeeGo, the Qt / Qt Mobility APIs should suffice (plus OpenGL ES for the specific segment willing to use it). If any of these developers is not finding what he is looking for, then bugs against Qt Mobility are welcome (I asked the maintainers and this is the answer they gave). The MeeGo Compliance needs to sit on a clear principle, and the MeeGo API described at http://meego.com/developers/meego-architecture/meego-architecture-api-view is clear. If the implementation of the principle has some problems today (functionality not covered by APIs, or APIs not connected the MeeGo backend) then we need to know what is missing and work on the implementation and fixes. Bypassing a problem by hooking directly on a deeper API solves a problem today, but still the bug reports are needed to help the Qt Mobility team working on the right items. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Compiling MeeGo roadmaps, plans, backlogs...
Hi, public roadmaps easy to find are an essential part of an open project. If your MeeGo project team has some kind of plans please make sure they are publicly documented and listed at http://wiki.meego.com/Roadmap I'm chasing the owners of Core, SDK and the UXs but there are more plans around and I'm not sure if I've caught all of them. Note also that keeping your roadmaps updated is just as important. Some of the pages linked at the Roadmap page are already old. Thank you. -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Smartphone list supporting MeeGO
Answering the original question: On Thu, 2010-11-04 at 12:25 +0100, ext Bogdan Cristea wrote: On Thursday 04 November 2010 13:20:03 you wrote: Not to be a smart-ass, but define compliant, please By that I mean smartphones on which MeeGo has been successfully installed and the APIs with various sensors (GPS, video) are more or less working. A similar list exists for Linux distros, hardware from vendors known to work with some distro. Usually, these lists are made by users. We ask everybody to help keeping http://wiki.meego.com/Devices up to date. It includes a Handset category. You might find more experimentation at http://wiki.meego.com/ARM - a page that also welcomes all the editing love and lists the progress done with some hardware that might qualify as 'smartphone'. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo 1.1 Handset Calrendar name bug ?
On Thu, 2010-10-28 at 20:27 +0200, ext Pain Chung wrote: Calendar app shows wrong name. It shows 'meego-handset-calendar' instead of 'Calendar'. I found this wrong name below file. '/usr/share/applications/meego-handset-calendar.desktop' Name[en_US]=meego-handset-calendar.desktop Is it any reason ? Please check if there is a bug filed for this at http://bugs.meego.com and if not you are encouraged to file it yourself. The same goes for other localization issues and any bugs you find in the 1.1 release. This is a high traffic mailing list and actually Bugzilla is a much more efficient way to report the problems to the people that can actually fix them. Thank you! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
On Mon, 2010-10-25 at 23:52 +0200, ext Thiago Macieira wrote: This is why I was wondering why we're not using hardfp *now* for 1.1.0. We shouldn't be breaking binary compatibility. We shouldn't be softp either. Just reminding the obvious, but as for today there is no major MeeGo products in the market, no AppUp for MeeGo, no Ovi for MeeGo, no Extras for MeeGo. Even the MeeGo SDK itself is in its first iterations. I see Arjan's point made from an architecture consistency point of view - but from a marketing point of view 1.2 and following releases will be a lot more used and scrutinized than 1.1.x releases. If this soft-hard break is unavoidable then it seems that now it will create a lot less hassle than in 6 months or later. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Questions on N900
On Tue, 2010-10-19 at 21:49 +0200, ext jaume dominguez faus wrote: Hello list. This mail might seem a bit off-topic. But I don't know a better place to find the answers I need than from the people who is daily dealing with this. It is off-topic. :) If you need to know anything about Maemo and the N900 you should search and ask at http://talk.maemo.org . Similar questions have been made already there. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of N900 as a MeeGo platform?
Hi, On Tue, 2010-10-12 at 16:49 +0200, ext Dave Neary wrote: Hi, I just noticed in the agenda for the TSG meeting tomorrow (which I won't be able to attend) the following agenda item: * Nomination: Nokia N900 hardware platform maintainer: Carsten Munk. * Valtteri Halla/Nokia is proposing to nominate Carsten to replace Harri Hakulinen in this role. Carsten is a renowned developer and founding maintainer of the mer project. Nokia supports Carsten and development of MeeGo for N900 in various ways including allocating a team of developers led by Harri and providing technical support. What does this mean for the N900 as a reference platform for MeeGo development? Please feel free asking at the TSG tomorrow, but in the meantime: Nothing new? Does it mean that Nokia are basically moving on, and leaving Carsten in place as a life-buoy for the N900 version? No, it means that the guy that is doing a great job gets the corresponding role explicitly assigned. As a casual observer, it could look like Nokia are withdrawing official support for development maintenance of MeeGo on N900 and leaving it to be community supported. But casual observers were saying that the MeeGo meritocracy requires key roles being taken by non-Nokia and non-Intel contributors... Carsten is on top of these releases and he knows every single detail of them. Just check in bugzilla, mailing lists, IRC... It's a logical step and I'm willing to see more roles taken by non-Intel/Nokia people as they become the experts and drivers in their areas. Can those involved elaborate on what this would mean for N900 MeeGo users, please? For N900 users? Definitely nothing. The future of the N900 as official MeeGo hardware platform depends on the availability of more suitable ARM hardware to test. At the moment there is nothing in the horizon challenging the N900. This has nothing to do with Harri or Carsten being in charge of the releases for the N900. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] TSG meeting cancelled - sorry
Hi, There was a TSG meeting starting in few minutes but we must cancel it due to lack of quorum. Sorry about that. We will communicate the new date and agenda as soon as it's ready. For more information about TSG Meetings check http://wiki.meego.com/Technical_Steering_Group_meetings -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-touch-dev] libmeegotouch 0.20.44-1 has been tagged.
On Mon, 2010-09-27 at 14:58 +0200, Tamminen Eero (Nokia-MS/Helsinki) wrote: Do you have an escalation route for driving this issue? Who's responsible for MeeGo bugs QA in general? http://meego.com/about/governance/quality-assurance -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Fri, 2010-09-17 at 08:58 +0200, Kellomaki Pertti (Nokia-MS/Tampere) wrote: This may be completely left field, but from the discussion so far it seems that it could in fact be a lot easier to bless repositories (or sets therof) as MeeGo compliant, rather than single packages. Actually I think it's a very relevant comment. A lot of posts are describing a situation Commercial Stores vs Extras/Surrounds when the core question is to restrict application compliance to apps directly based on the official MeeGo API or not. MeeGo Extras/Surrounds would benefit from separate repos for apps depending directly on the official MeeGo API (Qt / WebRuntime) and all the rest. It might make a lot easier for MeeGo vendors to include the 'strict' meego.com repo in their products or marketing. On the other hand, what are the deep issues underneath this long discussion? Let me try: - The belief that the MeeGo official AOPI is not enough to satisfy developers. If this is true then it's a problem in itself and needs to be fixed by improving the API. - The belief that there will be a significant amount of apps using other APIs / toolkits. Which ones, though? PySide? KDE libs? Hildon? This discussion would be better grounded if sustained by real maintainers of these toolkits bindings. - The belief that having a Compliant flag will open the door of these apps not depending directly on Qt / WRT to make it to the AppUp, Ovi and etc. However, I doubt so. For these stores keeping a consistent catalog for Qt WRT across different UX, architectures, products and vendors is already a considerable headache. They will look at any options helping them to increase number and variety of apps, but probably not before those alternative APIs and toolkits have proven themselves. - Even the perception that the Compliance restrictions go somehow against free software development. I would accept this one if the MeeGo project would refuse the idea of hosting an own Extras/Surrounds repo. But if this exists then developers concerned about software freedom can use them, and users concerned about software freedom can buy devices open enough to run that software. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On Thu, 2010-09-16 at 12:13 +0200, ext Jeremiah Foster wrote: Forcing Extras out of compliance means you are disenfranchising your community. No. Hosting any kind of free software apps and libraries regardless of their official/unofficial , compliant/non-compliant and unstable/stable status means that everybody is welcome at meego.com. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Upstart in MeeGo?
On Fri, 2010-09-17 at 14:19 +0200, Kellomaki Pertti (Nokia-MS/Tampere) wrote: Are there any plans re upstart in MeeGo? I'm asking because we have test scripts that use initctl to control daemons, so the scripts need to be modified if there is no upstart. Now there is a meego-architecture list devoted to discuss topics like future technology selections. http://lists.meego.com/listinfo/meego-architecture Please continue this thread there. Thank you! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Don't mix app compliance with enabled repos (was Re: Meego spec - for comment)
if you really think that Nokia will enable Extras on operator subsidized phones... I think you underestimate how much operators will not like that. So why do we want to pander to that in meego.com? Isn't this about open source values, or did I misunderstand why helping the Maemo Community out with the OBS was such a huge issue? Please don't mix the discussion about application compliance with the discussion about enabling repositories. They are orthogonal. The MeeGo project will offer to MeeGo vendors a flexible approach starting with the Security Framework (allowing fully open and fully closed options) and ending to the gateways to Extras, AppUp, Ovi and whatever else comes. But it's up to the vendors to decide the openness ans the allowed sources for each product. There is nothing really to be discussed about this here at meego-dev. Let's keep the discussion in the MeeGo Compliance until we are all in the same page, please. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 09/13/2010 01:28 PM, ext Warren Baird wrote: On Mon, Sep 13, 2010 at 3:53 PM, Quim Gil quim@nokia.com wrote: - Should we have several grades of MeeGo compliance applications? And what is a purpose of the MeeGo compliant application concept? For clarity, I would restrict the word compliance to the official MeeGo compliance based on the official API. A MeeGo compliant app runs on any MeeGo compliant device. If we dilute this we are opening a Pandora's box. The MeeGo Extras stable repository would contain apps tested to work on top of official MeeGo releases. No compliance word needed: they are extras. Hmm. That does solve the problem --- but it seems to me that having Extras - which might well be the vast majority of MeeGo apps, at least initially - not have some kind of official 'stamp' is a weakness, at least on the PR side... If the 'commercial' apps can't capture the energy of a successful MeeGo Extras then we have a problem elsewhere, but still you are making a good point. Well, an app in MeeGo Extras passing the MeeGo compliance test *is* a MeeGo compliant app in its full right. Maybe there is a way to distinguish those? A Good Thing is that any commercial store know that these apps run on top of MeeGo without needing additional dependencies, and they also know these apps have gone through a transparent QA process. App developers might well view it as a slight that their apps aren't compliant, and users might well be less inclined to run apps that aren't officially compliant... Still, the apps in MeeGo Extras relying on unofficial toolkits and libraries would still work and even be stable but I still think the term MeeGo compliant should be avoided. Developers and end users interested in those should understand the implications. I think it's valuable to have a set of rules to define A well behaved app that should be safe for a user to install while not going as far as the current definition of 'MeeGo Compliance', and some kind of official recognition of such apps. I've seen other programs like this that have different levels of compliance... I could see something like: MeeGo Conforming App: depend only on things in Extras, compile successful on the build system and pass a series of automated tests, etc. MeeGo Compliant App: what's currently in the compliance spec. Apps on the app store would need to be compliant, apps on Extras need to be Conforming. Thoughts? I think we agree on the principles even if we still need to fine tune the words. :) -- Quim Gil MeeGo advocate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
On 09/13/2010 01:58 PM, ext Arjan van de Ven wrote: so here is a catch; if it is part of Extras and real apps depend on it, suddenly no security updates is absolutely not an option. If it's part of Extras then it's not part of the official MeeGo release and the MeeGo project is not committed to provide official security updates. The MeeGo Extras maintainers must commit to a QA process that would include a procedure to handle security issues, but that's all. if apps can depend on Extras being there, suddenly the OS size for the device becomes much bigger. Not the amount present at ship time, but the amount the OEM needs to reserve for the OS... because now that's no longer as well known or bounded. Valid concern. Not having MeeGo Extras will solve this problem, though? The pressure from users to install more stuff is a clear trend. In a perfect MeeGo world all app developers would be happy with the official API but at least today it's not the case. Technical solutions exist. If a vendor wants to have a well constrained device then he can simply restrict the repositories via Security Framework. Another solution is to run unsupported libraries on the extended memory à la Maemo /opt http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs More solutions? If we agree on the principle we probably will find more ways to tackle the specific problems. -- Quim Gil MeeGo advocate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego spec - for comment
Interesting discussion. Thank you! On 09/08/2010 09:28 PM, ext Arjan van de Ven wrote: I think there's a more general what is MeeGo thing behind this. Yes. Let's agree first in the concept and then sorting out the technical aspects will be easier. For some, MeeGo is *the* distribution, there is only one, and because of that, things that add to one will add to all of MeeGo For others, MeeGo is the reference, where the assumption is that many companies will make variants that they all want to call MeeGo, but that are all different in some ways. Here we are talking about libraries and apps. The backbone is the MeeGo official API, provided by the MeeGo Core. I guess we all agree that no matter how many variants companies and communities do around MeeGo that official API needs to be there as a minimum requirement. Well, this is a starting point. Let's look first at MeeGo Extras: If the developers targeting MeeGo Extras want to support libraries not present in the MeeGo architecture then they should be able to do so, as long as their packages work on top of MeeGo Core. And this should allow developers targeting MeeGo Extras to use those libraries. The MeeGo Community OBS and the MeeGo Extras QA process should help porting, developing and maintaining these libraries and apps not sitting directly on top of the official MeeGo API, but functional in a stock MeeGo OS. The open development of MeeGo allows the maintainers of this Extras components to test them against new releases and fix/negotiate in case of breakage. In practice, this Extras maintainers are some of the earliest and best testers of the unstable platform. Now, what about the MeeGo vendors? Those vendors sticking to the pure MeeGo stack with only some UX customization on top can benefit directly from MeeGo Extras - or their users can if they wish and their system is open enough to add the Extras repo. If they are not interested, no problem. Those vendors adding their own libraries on top of pure MeeGo can solve the problem of collisions with MeeGo Extras by assigning a top priority to their repos (I guess) or taking more drastic measures promoting their own packages and basta. Or just like the MeeGo maintainers, they can fix/negotiate with the Extras maintainers. Those vendors doing deeper changes in the fringe of MeeGo compatibility know anyway that they are playing with fire. If they want to get the benefit of Extras they will need to do some homework. If they just want a closed system without Extras input then there is no problem to solve. In any case if there is a conflict the guidance comes automatically from the MeeGo API and the MeeGo Core. The open development and the explicit willingness to sit on top of newest releases as soon as they are ready for production just makes the conflict resolution easier. The first model is what Maemo used to be, there was only one Maemo; the second model is what Moblin used to be, with many variants. I think there is a way to benefit from the beautiful aspects of both platforms. The versatile architecture of Moblin (compared to Maemo) was beautiful. The proliferation of application developers and community libraries (compared to Moblin) was beautiful too. Frankly, I see MeeGo only be able to follow the second model; there is more than one company doing products with MeeGo (heck, Novell already has a variant), and thus there will be variants. The moment you have variants, where you allow the variants to add their own stuff on top, you can't have an Extras repository that works for all of these variants anymore, only one that works for the reference. But we can't stop Extras because of the variants. On the contrary, a strong and useful Extras will only help those variants to differ from the MeeGo reference only when there is a good business reason to do so. Any step you do out of the MeeGo way might cost you hundreds of apps not available to your users. Lat but not least: since the MeeGo launch and even before open source innovation has been a driver of this 'joint platform developed under the auspices of the Linux Foundation'. Limiting the MeeGo umbrella to the official stack and API and limiting that innovation to companies able to create their own ecosystems is imho limiting the MeeGo potential too much. And for no good reason? And once that's the case. you really can't say oh but you can depend on anything that's in Extras. Or even you can depend on things that are not in the required set to be honest. I agree: the MeeGo project should put the emphasis on the official MeeGo API as the only reliable dependency. This doesn't mean that we must cut the Extras initiative pushing them out of the MeeGo umbrella. -- Quim Gil MeeGo advocate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] meego pad
Hi, are you asking me? On 08/27/2010 02:17 PM, ext Randolph Dohm wrote: quim, is it true, that nokia meego pad will be available for 11 ? http://www.heise.de/newsticker/meldung/1-1-laesst-SmartPad-auslaufen-1068272.html are there any strategic alliances besides automotive? First, my knowledge of German is good enough to see no relation between your question and that page. Second, your question is totally of topic in this busy mailing list about MeeGo platform development. Please stay on topic. If you want to have light discussion about MeeGo consumer topics http://forum.meego.com might be a better start. Thank you! -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Next TSG meeting on August 18
Hello, We don't have quorum for tomorrow's Technical Steering Group meeting. The participation of the key people is confirmed for next Webdnesday, August 18. Let's chat next week, then. More details at http://wiki.meego.com/Technical_Steering_Group_meetings -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Forum / mail integration (was MeeGo Summit - Structured brainstorming...)
((Cross-posting on purpose with meego-community since it is the topic of discussion)) Hi, On 06/04/2010 01:15 PM, ext Dave Neary wrote: Is there a good reason not to use Google Groups, aside from, you know, the whole Google thing? By Google Groups do you mean Usenet newsgroups? It's been a while I haven't used Usenet but isn't it that Usenet as great gateways for both web and email integration? If you have a Google account you can use the interface via Google Groups (but really, we cannot require to have a Google account to be involved in MeeGo discussions). An idea to consider. But let me go down to things we can fix right now. I agree with Dawn that the Forum/Mail thing is not resolved and we need to have one channel useful for the core purpose it needs to accomplish. I have personally no problems with mailing lists or forum (I start to have problems about Mail/Forum discussions though) ;) Concrete proposal by-passing the concerns about a forum is also important: - The maemo-community mailing list is the one and only channel for the Community Office coordination - http://wiki.meego.com/Community_Office coordination. Anything related to Community Office meetings and tasks is discussed and coordinated there. If you are responsible of a Community Office task you need to be there. If you want to push your agenda to the Community Office you have to do it there. - Every task committed chooses the best channel to get things done. The default is a report at http://bugs.meego.com, but meego-community, http://forum.meego.com or else can also be used when they make more sense. Up to the owner of the committed task. - Community Office decisions and meeting minutes are communicated to the rest of the project via meego.com blogs (details to be defined). - In addition to this, anybody can start any community related discussion in meego-community or forum.meego.com. For instance, someone not interested in the Community Office activity can stay in the forum and forget about the mailing list. Someone interested only in the Community Office activity can stay in the mailing list and forget about the forum. This guideline can be revised when we have a better technical setting, but they could be implemented right away with the current infrastructure. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Summit - Structured brainstorming format in the form of BOFs and Wiki Specs.
Hi, On 06/03/2010 01:03 PM, ext Thiago Macieira wrote: Em Quinta-feira 03 Junho 2010, às 10:42:31, Dirk Hohndel escreveu: So in your vision the MeeGo Conference would be where all the features for the next version of MeeGo are decided? Given that we are currently targeting two releases a year but just one conference a year... that seems mismatched. I also wonder if this process is actually the best use of time for the conference, but I'm open to discussion here. I think we should have this kind of gathering, to decide together on the main direction to take in the next 6/12/24 months. But it's *not* what we have planned for the MeeGo conference. One day there will be a public roadmapping process done at a MeeGo project level. On top of this specific projects may have their own planning activities. No mater how, ideally the plan for the release is public and fully committed by the time the release starts. The MeeGo Conference is indeed a good venue to discuss the direction of the MeeGo platform and related projects, but waiting for a MeeGo Conference to agree the roadmap of a next release sounds too risky. I don't think it's feasible to have it right now twice a year -- let's get up and running first. And it's a high cost to send the people who are relevant to these discussions, as opposed to presenters and only those who are interested in the event itself. On the other hand, it makes sense to attach this developer gathering to the conference, to save costs. So I propose that, for this year, we stick to the format we have planned and use the unconference day for this kind of work. I suggest that the people interested in this thread organise themselves: prepare a section of the wiki for registering the unconference sessions. The organisation can help you find out how many rooms there will be available. I won't be surprised if another MeeGo events emerges by the time the first 2011 release is out. There haven't been discussions about this but it makes sense. Probably smaller and more focused on the project maintainers and platform developers directly involved. Maybe in the future we even have it the other way around: the big massive conference happens in Spring when the Northern Hemisphere enjoys good weather and then in the dull Autumn we have the smaller one with basically full time employees closed in a big room during 3 days because anyway it's dark and raining outside. ;) Or find alternative Southern venues and meet every six months but always in Spring. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Is Meego aimed to defeat iphone?
Hi, On 05/31/2010 12:26 PM, ext Jianchun Zhou wrote: Is Meego aimed to defeat iphone? How long will it take? Please consider starting a new thread at http://forum.meego.com/forumdisplay.php?f=2 Thanks! This is a mailing list focusing on the development of the MeeGo platform. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Technical Steering Group Meeting 26 May 2010 at 19:00 UTC
Hi, ext Dave Neary wrote: To be clear: Maemo documentation is licenced under GNU FDL, which is incompatible with all Creative Commons licences (including the similar CC BY-SA). To allow reuse of existing Maemo documentation, we would need Nokia to relicence these docs to Creative Commons BY. I was contacted by Ibrahim about this question. I don't see the problem: - What existing documentation in maemo.org makes sense to re-publish in meego.com? - Any new documentation produced by Nokia to be published in meego.com will follow the licensing model agreed by the MeeGo project. - If there is a corner case let's look at it. If Nokia is the only contributor then let's just copypaste it to meego.com. If there are several contributors involved and we don't know where they are... maybe we'll finish before linking to that page or rewriting the content (extreme case). Are there more issues? -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of hildon?
Hi, ext Cornelius Hald wrote: I don't know it either, but I expect it to be basically non-existent and probably for a good reason. I don't think it makes sense to work at Harmattan's Hildon before we know how the Harmattan UI will look and (more important) work. That's probably not really a technical problem, but more a motivational problem. (...) What I think will happen is this: At some point people with big Maemo5/Hildon applications will get a Harmattan device or SDK and then they will try to get their applications running. Therefore they will compile a recent version of GTk, try to apply Hildon patches, etc. I see your point. However, your motivational path is simpler if you focus on the public MeeGo Handset UX and compatible devices (coming soon) instead of waiting for the mysterious Harmattan device from Nokia. At that point we will see whether or not it is feasible to bring Hildon to Harmattan. Well, at least if it is a _real_ community effort. If however Nokia did sponsor some Gtk developers and provided them with some Harmattan UI material it might look differently. At least from a theoretical point of view it made sense to work out the support for GTK+ and Hildon related activities with the GNOME Foundation, since it's an organization able to invoice that has the overall responsibility of the GNOME and GNOME Mobile projects. The fund given to them should be enough to kickstart the work and more. There has been some discussion about this at GNOME's mobile-devel-list but honestly I had expected a more concrete or articulated answer by now. See the whole What would you do to encourage application developers on GNOME Mobile? discussion starting at http://mail.gnome.org/archives/mobile-devel-list/2010-April/msg3.html and even my own post back in February that got basically no traction from anybody involved in GTK+ development - http://mail.gnome.org/archives/mobile-devel-list/2010-February/msg00010.html It would have been nice to inform people on the maemo-devel list about those posts. True, my fault. Maybe I was too optimistic at that time about Hildon/GTK+ maintainers taking the ball and moving forward, or at least showing interest and asking the right questions to proceed. There was also http://talk.maemo.org/showthread.php?t=36687 and this was discussed elsewhere in the Maemo community as well (can't remember now exactly where). But no post to maemo-developers, true. Then again, the GNOME project is where the GTK+/Hildon hackers are supposed to be found. I'm sure the maintainers and related developers that actually have the skills and potentially the interest of doing something like the topic discussed here were aware of these posts. That might now be the job of the Gnome Foundation and not of Nokia. But this is what I think should happen. 1.) Provide people with some time and/or money to bring all Gtk changes that are needed for Hildon upstream into the real Gtk. 2.) Let them make sure that the current Maemo5-Hildon compiles against that new Gtk. 3.) Give them insight into the Harmattan UI spec, to make it possible to adapt the look and feel. The bal is now in the GNOME Foundation's field. Our fund went there with a proposal/recommendation of the types of activities to do, but it is now their budget and their decision. Personally, I really really want to have Hildon on MeeGo. Not because I think it's the future or that it is superior to Qt. No, simply because it would be so frustrating to see my volunteering work of over a year go into oblivion. If I had the time (3-4 month full time), I would rewrite my application using Qt. Unfortunately this is completely unrealistic. Still hoping for Hildon on Meego! Having an evolutionary path for GTK+ Maemo 5 apps into MeeGo Handset (and touch friendly UXs in general) makes total sense, and this is why we are here (and in gnome.org) discussing in these terms. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of hildon?
Hi, ext Alberto Garcia wrote: On Sun, May 23, 2010 at 02:34:43PM -0700, Arjan van de Ven wrote: So is there some plan to include hildon into meego? there is no plan for this at this time. I would have said something great for the cummunity repo if it wasn't for hildon patching core GTK in an incompatible way ;-( Can you elaborate a bit more on this? Hildon is a library different from GTK. If you're talking about the Maemo branch of GTK: yes, it contains changes for features that were necessary but unavailable in upstream GTK. But the policy was not to touch GTK unless it was completely necessary in order to keep it as close as possible to the upstream version (something that btw received some criticism at the time). Porting those changes to the latest upstream version of GTK does indeed require some effort, but I don't think there's anything inherently incompatible, since that same task has already been done in the past (e.g. for Maemo 5). There are no plans to support Hildon officially in MeeGo, no matter what is the status of GTK+. This brings no changes compared to the Hildon status in Harmattan, announced as 'community supported' last year at the Desktop Summit. I also wonder what is the real status of this community support, and the willingness of the current Hildon and/or GTK+ maintainers and developers to bring Hildon and Hildon based applications to the MeeGo community repositories. There has been some discussion about this at GNOME's mobile-devel-list but honestly I had expected a more concrete or articulated answer by now. See the whole What would you do to encourage application developers on GNOME Mobile? discussion starting at http://mail.gnome.org/archives/mobile-devel-list/2010-April/msg3.html and even my own post back in February that got basically no traction from anybody involved in GTK+ development - http://mail.gnome.org/archives/mobile-devel-list/2010-February/msg00010.html Nokia gave a substantial fund to the GNOME Foundation with the main goal of promoting GTK+ based applications for Maemo 5 and also to help building a future path for them in future releases - now in practice MeeGo Handset UX releases. There is still not a concrete plan for that budget that I know, which is not, er, optimal considering how fast time passes both for Maemo 5 and MeeGo. Conclusion: if you think that we as Nokia still could to do something else to ease the transition of Hildon based applications to MeeGo please let me know. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
Hi, There is a thin line between CMS pages that only some editors can touch and protected wiki pages that only some editors can touch. Proposal: get first such page ready in the wiki and then we can discuss case by case where each one belongs to. In this case: ext Warren Baird wrote: Would it make sense to have something like meego.com/policies that hosts the *approved* versions of the policies, while the drafts are maintained on the wiki? Looks like food for http://meego.com/developers . Let's avoid the proliferation of subdomains and first level subdirectories, specially for stuff you really don't need in a primary navigation bar. Now please go back to the real discussion: the content of http://wiki.meego.com/Packaging/Policy :) -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Packaging Policy : A process proposal
Hi, ext David Greaves wrote: A conversation earlier today got me the action to submit a request for the TSG: http://wiki.meego.com/Technical_Steering_Group_meetings#Backlog_of_Proposed_Topics I really believe that it is useful to discuss all topics well in advance before throwing them to the TSG agenda. I keep repeating myself that mantra from Arjan: If a topic reaches the TSG it means that the rest of channels have failed. Can we please discuss first this packaging policy proposal here, involving the right people actually knowing all the technical aspects and process details? -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo compliance (was Re: Questions for TSG regarding big reveals...)
Hi, please keep the MeeGo compliance part in the subject of this spin off thread - thanks! Ibrahim from The Linux Foundation is driving the MeeGo compliance definition. Hopefully we can have a first version of the guidelines published soon, currently under private drafting and review to sync legal, technical, marketing and resourcing aspects. ext Cornelius Hald wrote: So how far may companies go if the differentiate the UI? What is allowed to still be called Meego or Meego-Compatible? Is it only theming or can they provide their own UI framework? The main objective behind the MeeGo compliance is to guarantee binary compatibility for applications across multiple MeeGo products. All the rest (definition of the official MeeGo API, architecture...) is a consequence of this basic goal. This gives a lot of freedom to whoever wants to deploy a MeeGo based product. The MeeGo project doesn't go after a single user experience common to all MeeGo based products. Then again, if we do things right the MeeGo reference user experience will be a good default candidate and any vendor having to rationalize resources will probably think it twice before departing from it at own cost and risk. It's a choice for platform developers. How will you manage that users always have a consistent look feel even with 3rd party applications? And how should a developer face this issue - it's surely not a solution to implement every 3rd party application for every vendor specific UI framework. Thinking out loud only, but we can see two basic trends in application UIs: the ones prioritizing platform lookfeel integration and the ones pushing their own lookfeel across different platforms. It's a choice for application developers. Going back to the original point, what really matters is that MeeGo users can enjoy the combination of MeeGo devices and applications of their choice no matter what choices have been made by the developers of those devices and applications. Too many questions, I know :) But good ones! :) -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Questions for TSG regarding big reveals and impact on open development
Hi, ext JD Zheng wrote: As far as I understand, UI/UX part is basically the most important component(s) that MeeGo is creating by itself, but now it sounds like MeeGo will NOT design UX by MeeGo community, at least not most, instead, it will incorporate UX components from upsteam like Intel UX or Nokia UX or others. You seem to be mixing streams. MeeGo is upstream and whatever implementation Nokia, Intel and others do based on MeeGo will be downstreams. I agree that currently, before the MeeGo UXs have been published, the waters are not clear but have no doubt about the role the MeeGo project will have maintaining and pushing its reference UX. Then MeeGo downstreams will probably customize their own UXs. Some of those customizations will be limited to preferences, themes, graphics and other details actually not contesting the upstream UX development. Some might be heavier customizations but still without having the vendor willing to challenge the upstream plans. But of course it is expected that the vendors bringing MeeGo based UXs to real users will have opinions and enhancement plans, and some of them will directly contribute or contest the upstream plans. As it usually happens. My question is whether MeeGo will have its own UX teams/projects to develop UX by itself or decide which UX will be chosen as MeeGo *official* UX. Each MeeGo platform and application component needs to have teams and collaboration channels publicly documented. Anybody should be able to go to the right place and convince the right people with words, mockups, code... Anybody should have a chance to become a maintainer or responsible of an area based on own merits. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Questions for TSG regarding big reveals and impact on open development
Hi, CCing TSG members just in case and sharing my personal take below. ext Carsten Munk wrote: So, this is primarily an e-mail to ask some questions to the two members of the TSG, that I think would not be sufficiently covered in a TSG meeting and answers might be better suited for the e-mail form. Now, there is currently in the MeeGo project what I've heard described as a 'big reveal mentality' by someone - regarding Handset, Netbook UX, etc. Now, I can understand why the project needs to do this - the press would tear you apart if not done right, so the UX'es are not what I'm here to discuss. What I'm here to discuss is what it does to the project. A big reveal obviously requires a great deal of secrecy for the parties involved. In this case, it's two or more big companies and well, maybe unintended, most of the MeeGo project structure (release management, OBS/repositories, bug tracking, testing, developer documentation, etc.). The secrecy seeps through almost every single aspect of MeeGo and it -is- hurting our idea of public RD. I have plenty of examples, but this is not important to the topic. We're not working in the open like we're supposed to - even though as has been said - Intel, Nokia and we all know how to do it! But when there's a big reveal mentality active, the mode of the people participating switches to internal/private development, even if you are only tangentially related to the object/UX being revealed. And I think that's the main source of all our so called 'openness' problems - not malice, conspiracy, laziness or whatever. For the near future until UX'es are out, the big reveal mentality will have to stay - and I respect that. I want a blazing start on a good future in this project with big fanfare. It's the future I'm worried about. Finally, my questions to the two members of the TSG are: Would you agree that the big reveal mentality has been hurting the MeeGo project extensively in terms of having public RD up to now? What will you actively do to prevent the same working patterns where people have not worked in the open due to the big reveal mentality, to continue after the UX reveals? In the future, in case you get another need to do a big reveal, how will you ensure that active, public development/work/process will not regress to not working in the open? Should the work for big reveals be done initially outside the MeeGo project framework? Thanks in advance for your answers. Actually I don't think big reveals around platform development are useful for the MeeGo project. Once the project is deployed with all working groups and related UXs and a public roadmap process in place, MeeGo should be build on simple and plain open development. Indeed, we are not yet there. But in a few weeks we will have the sensitive UXs out, the MeeGo project structure will hopefully be populated with names in the couple of layers below the TSG, the plan for the Q4 release will be out and also the official processes will be public. In such context, the news around software development will be hopefully more based on features implemented and testable rather than about big reveals. The MeeGo big reveals should come mainly from business centric announcements: devices launches, companies announcing MeeGo involvements, and so on. On the software development side, if there is a big reveal from specific vendors / projects it will be around items developed for a while on a private or public side and then offered or contributed to the MeeGo project. Since the MeeGo roadmap and plan for the next release will be public, nothing disruptive AND secret should be in the pipeline distorting the development of the ongoing unstable release. The success of MeeGo is build on top of openness and predictability. Big reveals are not very useful for vendors having to plan their products well in advance. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Projects Bug Jar 2010.19
ext Stephen Gadsby wrote: A Quick Look at MeeGo Projects in Bugzilla (http://bugs.meego.com/). 2010-05-03 through 2010-05-09 Great stuff! Thank you Stephen. Life in MeeGo was missing something without the weekly bug jars. 20 bugs were opened - ( https://bugs.maemo.org/buglist.cgi?bug_id=1614,1657,1658,1699,1710,1711,1718,1745,1765,1766,1770,1779,1798,1803,1804,1805,1807,1813,1847,1852 A bug in the script, that still creates URLs pointing to bugs.maemo.org instead of bugs.meego.com Looking forward now to the implementation of votes in bugs.maeego.com so we can also get weekly updates on the most popular bugs and enhancement requests. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] List of MeeGo compatible devices
Hi, erkanyilmaz start this useful wiki page http://wiki.meego.com/Compatible_devices_with_MeeGo Please help completing it. Is compatible with MeeGo? is one of the FAQ from people with a mobile device (mainly netbooks) or thinking of buying one. Thank you! -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Voting in bugs.maemo.org
Hi, we are considering the addition of Bugzilla's voting feature at http://bugs.maemo.org http://www.bugzilla.org/docs/2.22/html/voting.html This feature serves a very good purpose in http://bugs.maemo.org and other bug reporting tools out there. It is an indicator about interest that might be taken into account by development teams and contributors. All people involved in the discussion has agreed on the usefulness of the feature and we decided to ask here just to check with the developers. The enhancement request is filed at http://bugs.meego.com/show_bug.cgi?id=1080 . Since you can't vote in bugs.meego.com the OP created a thread with a poll at http://forum.meego.com/showthread.php?t=96 :) Please give your feedback in any of those channels. We will decide in a week, latest. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt application on Meego
ext Xu Cheng wrote: Hi, Tom: I have same question as Efan. What's MADDE? Is a IDE? http://wiki.maemo.org/MADDE Coming soon to MeeGo and its developer documentation. Good that MeeGo also starts with M so we don't need to rename anything. ;) -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt application on Meego
Hi Efan, You sent the same email at the same time to meego-sdk. Please avoid cross-posting. meego-sdk is the right list for application developers since meego-dev is for development of the platform itself. Alternatively you can also use the Application Developer Support forum http://forum.meego.com/forumdisplay.php?f=3 Thank you for your interest in MeeGo and I hope you get the right answers. -- Quim Gil ext Efan... wrote: Hi all Any one got any chance to build and run any Qt application on Nokia N900 having Meego??? I did installed Nokia mobile sdk but that does not seem to be helpful for Meego. I have installed Meego on Nokia N900 but really dont know How to build and run my Qt application on it. Nokia mobile sdk tutorial does not talk about Meggo at all, Highly appreciate any help in this. -- Efan Harris ___ 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, The meego-dev mailing list is for discussions about development of the MeeGo platform. Topics about application development on top of MeeGo have 2 better places: Application Developer Support forum http://forum.meego.com/forumdisplay.php?f=3 meego-sdk -- MeeGo SDK mailing list Discussion and coordination about the meeGo developer offering, but you can also ask your questions there if you wish. http://lists.meego.com/listinfo/meego-sdk Thank you! -- Quim Gil open source advocate MeeGo Devices @ Nokia ext An Yang wrote: Hi Glen, 在 2010-04-30五的 10:03 +0100，Glen Gray写道： On 30 Apr 2010, at 03:31, An Yang wrote: hi Gray, It's Glen I did install meego on my eeepc manually. Yes, manual installs are possible, but clearly wasn't going to be an adequate answer to the person asking about what to do with those image files. Somebody just want use hard disc, manual install is the only way to install meego image to hard disc, until meego release the installation scripts-:) maybe the scripts just do the same job with my manual install suggestion. -- Glen Gray sla...@slaine.org mailto:sla...@slaine.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com mailto:MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Beginer level Qt on meego.
Hi, The meego-dev mailing list is for discussions about development of the MeeGo platform. Topics about application development on top of MeeGo have 2 better places: Application Developer Support forum http://forum.meego.com/forumdisplay.php?f=3 meego-sdk -- MeeGo SDK mailing list Discussion and coordination about the meeGo developer offering, but you can also ask your questions there if you wish. http://lists.meego.com/listinfo/meego-sdk Thank you! -- Quim Gil open source advocate MeeGo Devices @ Nokia ext Efan... wrote: Thanx Tom, I got it. But this is talking about Maemo Not Meego. Will an application compiled for Maemo run On Maego on same device? I think yes, just wanted to check if you have had chance to run any application on Meego? Thanx for your help On Mon, May 3, 2010 at 11:34 AM, lists4pghanghas lists4pghang...@gmail.com mailto:lists4pghang...@gmail.com wrote: On Monday 03 May 2010 10:17 PM, Efan... wrote: Hi Tom, Thanx for your help, But unfortunately I dont see Mobile SDK 2.0 on there site. I Get other SDK but mobile one. http://qt.nokia.com/downloads Can you please point me to correct link. Thanx again for your help. BR Efan On Sat, May 1, 2010 at 5:57 AM, Tom Arnold g...@rocketmail.com mailto:g...@rocketmail.com wrote: Download Nokias Qt mobile SDK 2.0 beta. It has a emulator and device support (and stuff). Really neat. *From:* Efan... efanhar...@gmail.com mailto:efanhar...@gmail.com *To:* meego-dev meego-dev@meego.com mailto:meego-dev@meego.com *Sent:* Fri, April 30, 2010 11:53:02 PM *Subject:* [MeeGo-dev] Beginer level Qt on meego. Hi, I have installed meego on my N900. Now I want to run some of Qt example on this. Can some body please help how can I do this. Do I need to cross compile Qt for N900 and so is my example? I will really appreciate if some of you can help me with the steps I need to do to see my Hello world Qt application running on N900 with meego -- Efan Harris -- Efan Harris ___ MeeGo-dev mailing list MeeGo-dev@meego.com mailto:MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev Hi Efan, this links contains all that you need including a download link http://labs.trolltech.com/blogs/2010/04/27/nokia-qt-sdk-what-is-in-and-what-is-not-and%E2%80%A6-what-is-it/ I suggest you add this blog to your feed reader if you are interested in qt development. Really nice articles appear here. PSG -- Efan Harris ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Projected timelines for full openness
ext Glen Gray wrote: On 27 Apr 2010, at 10:16, Quim Gil wrote: The plan is to have in few weeks a first complete MeeGo release followed by a roadmap to work on the next release. Once this is out the MeeGo project shouldn't have any obstacle to have all the daily work and routines in the open. Thanks for the honest reply Quim. I think a LOT of misunderstandings and anxiety about what's happening could have been avoided if this had been clearly stated from the get go. We've been getting mixed messages as others have commented on today. Sure, but this assumes that we knew exactly how things would roll out. :) This is the first time we do a merge like this and there are actually not many precedents to look at. At any point we have said what we actually believed that would happen. Then some things happen when and how you expect and some others go in different ways. Even if this is sometimes uncomfortable, all in all is not a huge deal since the direction is clear, the will is there and we will go through this. Also, there seems to be a perception that Intel and Nokia now form a single united team sharing all the information and clear plans and hiding most of it to the community. I take this as a variant of the conspiracy theories around corporations. ;) But this merge also brings mixed messages and perceived lack of information to Joe Developer at Intel and Nokia. A natural part of the process: consolidates teams of people sharing common managers, company structures and knowledge of confidential corporate plans now are meant to collaborate fluently and in the open with developers from other companies and individual contributors. In practice this is easier for developers used to these dynamics in upstream projects (Kernel, BlueZ, etc) and less easy for others (future reference applications, system UIs still not shipping in any product, etc). - One that is quite unique now: two big teams having to sync on 1001 little things before going public common. I'm sure having discussions out in the open would have actually aided in that. There still seems to be a lot of misunderstanding between the teams from Intel and Nokia which is seeping through to the public level. Even from departments within Intel. That's my perception anyways. Yes, all in all open discussions do help. But some of them do not help if you need a well founded decision with a tight deadline. I mean, there have been some hot topics that now we have settled but a regular open project would still be discussing ad aeternum. Now they can still be discussed (ad aeternum if you wish), but the fact of knowing that Intel and Nokia as main current promoters have agreed on something does help moving forward. Again, after the first MeeGo release the backbone is in place and probably there will not be any technical discussion stopping the show for the rest of the project. We will also know each other better so the risk of personal damage in public discussion will be smaller. Then there is also an empty disco dance floor effect. Even if many people is willing to dance, the dance floor is mainly empty and you look left and right to see if any of your friends will jump first. (To make the analogy more complete, in such situations usually you see the first ones jumping to the floor with quite extrovert attitudes and questionable dancing skills - which doesn't help your motivation to do the step). ;) But every night the dance floor ends up full with plenty of fun, and at that point is plain easy for anybody to just get in and add to the mess. We are getting there, slowly. - One that will be around basically always: marketing factors making company X or even the MeeGo project itself to go for a sound release instead of an open development since the first line of code. This is something that is of great concern to me. We've seen this before plenty of times. Specifically, partner releases, which coincide with the main product release. Yes, we have seen this. But this is one point I really love about MeeGo: time based releases. Products have to align to the MeeGo timeline, not the other way around. It seems incredibly unfair and disrespectful to a community to deny them access to the product, many of whom would possibly like to further the use in a commercial setting. But at the same time to provide access to key partners in order to have a big reveal for launch day. Confidential projects from a company will always exist: one company is developing something and they decide the day when they want to start sharing publicly. But this is fair, isn't it. What would not be fair is that the MeeGo project is used as a curtain with two sides: one for the public community and one for some kind of corporate backstage where companies would share development before public releases. All the MeeGo work needs to be public and all the company confidential work needs to stay within the scope of the company NDAs. I hope
Re: [MeeGo-dev] Projected timelines for full openness
Hi, ext Graham Cobb wrote: On Tuesday 27 April 2010 10:16:07 Quim Gil wrote: The plan is to have in few weeks a first complete MeeGo release followed by a roadmap to work on the next release. Once this is out the MeeGo project shouldn't have any obstacle to have all the daily work and routines in the open. I am very disappointed in this. I really expect a project which is sponsored by the Linux Foundation to have **all** discussion on public mailing lists. No exceptions. That is my expectation too. However, there is a difference before and after a first release. I'm not defending the current situation of closed development prior to the first MeeGo release, but this is the reality. Before the first MeeGo release there is a lot of code being developed behind Intel or Nokia closed doors or in some public repo somewhere. Those pieces of software are being developed more or less by the same teams that were developing them before the MeeGo launch and without much changes. The release dates are around the corner and those teams from Intel or Nokia are not really in a condition to receive and process much feedback at this point, noting that such feedback might include prospective contacts from potential industry partners, media sensationalism, users asking when that piece of software will be available for their devices, etc. Then in few weeks a full MeeGo stack will be released, news and blog posts with screenshots will fly, deep and superficial feedback of happy and unhappy people will circulate, etc. All good! A roadmap for the next release will be published and the project will be finally in a situation to build a daily routine based on plain simple open development. Each MeeGo subsystem should have its own mailing list, visible for anyone who is interested. This is a comment aside but yes, we need to discuss how the daily routine of project discussion is held. The current approach is to concentrate on the current lists (-dev, -sdk and -l10n) and spin off new ones only when the traffic deserves that. In the Linux Collaboration Summit a speaker of IBM explained that at some point they forbid internal technical discussions about development of open source components, forcing their own engineers to go and have those discussion in the upstream projects channels. I find that is an excellent idea: after the MeeGo release discussions about OSS development through private emails should be a well justified exception and not the norm. It really helps nobody: not to the development of those OSS components and not even to the interests of Nokia/Intel. I have no problem with benevolent dictators -- I have a problem with calling MeeGo an open project if decisions being made behind closed doors, particularly technical decisions. If there is some concern over the amounts of traffic on public lists then you could require some sort of qualification or sponsorship for the privilege of sending to the lists: but the conversations must be visible for all! Improvising a bit here, the reasons for having private discussions prior to the first MeeGo release are: - Building common proposals first. Nokia and Intel don't aim to have everything polished before discussing every bit publicly, but having a common plan in place and going through the first rounds of discussion internally before makes some sense. - Having public roles first. The average Nokia or Intel employee working on something specific wants to know what is his/her official MeeGo role so they know when are they speaking for themselves, as upstream maintainers, as company employees... Having a full release out makes things easier for everybody. - Having clear instructions from managers first. The average Nokia or Intel employee working on something specific probably has a manager concerned on deliveries for release X. Depending on managers and teams, open development is already assumed - or not. Everybody know we need to change this culture but when it comes to pressure, having the first release still clearly wins. - Anything with a UI is still very sensitive, specially in the Handset UX. In theory you could indeed go to a public mailing list and just start discussing. In practice, the moment you do this you need to be prepared for a significant amount of feedback and noise coming from users and media. We have seen examples of this every other week. A lot of new development in MeeGo has to do with these areas (desktop apps). Nobody wants to be the guy quoted in the media before it's the right time. - Having consolidated/specialized channels? I'm wondering myself, but there might be some personal resistance (combined with the two points above) to go to meego-dev to share some development info and opinions if there is a remarkable risk of starting a long thread with high noise to signal ratio originated mostly by people not related to the development in that area that will be of little help to deliver sometyhing better sooner
Re: [MeeGo-dev] Projected timelines for full openness
Forgot another important aspect. See below. :) Gil Quim (Nokia-D/Helsinki) wrote: Hi, ext Graham Cobb wrote: On Tuesday 27 April 2010 10:16:07 Quim Gil wrote: The plan is to have in few weeks a first complete MeeGo release followed by a roadmap to work on the next release. Once this is out the MeeGo project shouldn't have any obstacle to have all the daily work and routines in the open. I am very disappointed in this. I really expect a project which is sponsored by the Linux Foundation to have **all** discussion on public mailing lists. No exceptions. That is my expectation too. However, there is a difference before and after a first release. I'm not defending the current situation of closed development prior to the first MeeGo release, but this is the reality. Before the first MeeGo release there is a lot of code being developed behind Intel or Nokia closed doors or in some public repo somewhere. Those pieces of software are being developed more or less by the same teams that were developing them before the MeeGo launch and without much changes. The release dates are around the corner and those teams from Intel or Nokia are not really in a condition to receive and process much feedback at this point, noting that such feedback might include prospective contacts from potential industry partners, media sensationalism, users asking when that piece of software will be available for their devices, etc. Then in few weeks a full MeeGo stack will be released, news and blog posts with screenshots will fly, deep and superficial feedback of happy and unhappy people will circulate, etc. All good! A roadmap for the next release will be published and the project will be finally in a situation to build a daily routine based on plain simple open development. Each MeeGo subsystem should have its own mailing list, visible for anyone who is interested. This is a comment aside but yes, we need to discuss how the daily routine of project discussion is held. The current approach is to concentrate on the current lists (-dev, -sdk and -l10n) and spin off new ones only when the traffic deserves that. In the Linux Collaboration Summit a speaker of IBM explained that at some point they forbid internal technical discussions about development of open source components, forcing their own engineers to go and have those discussion in the upstream projects channels. I find that is an excellent idea: after the MeeGo release discussions about OSS development through private emails should be a well justified exception and not the norm. It really helps nobody: not to the development of those OSS components and not even to the interests of Nokia/Intel. I have no problem with benevolent dictators -- I have a problem with calling MeeGo an open project if decisions being made behind closed doors, particularly technical decisions. If there is some concern over the amounts of traffic on public lists then you could require some sort of qualification or sponsorship for the privilege of sending to the lists: but the conversations must be visible for all! Improvising a bit here, the reasons for having private discussions prior to the first MeeGo release are: - Building common proposals first. Nokia and Intel don't aim to have everything polished before discussing every bit publicly, but having a common plan in place and going through the first rounds of discussion internally before makes some sense. - Having public roles first. The average Nokia or Intel employee working on something specific wants to know what is his/her official MeeGo role so they know when are they speaking for themselves, as upstream maintainers, as company employees... Having a full release out makes things easier for everybody. - Having clear instructions from managers first. The average Nokia or Intel employee working on something specific probably has a manager concerned on deliveries for release X. Depending on managers and teams, open development is already assumed - or not. Everybody know we need to change this culture but when it comes to pressure, having the first release still clearly wins. - Anything with a UI is still very sensitive, specially in the Handset UX. In theory you could indeed go to a public mailing list and just start discussing. In practice, the moment you do this you need to be prepared for a significant amount of feedback and noise coming from users and media. We have seen examples of this every other week. A lot of new development in MeeGo has to do with these areas (desktop apps). Nobody wants to be the guy quoted in the media before it's the right time. - Having consolidated/specialized channels? I'm wondering myself, but there might be some personal resistance (combined with the two points above) to go to meego-dev to share some development info and opinions if there is a remarkable risk of starting a long thread with high noise
Re: [MeeGo-dev] Projected timelines for full openness
Hi, ext Glen Gray wrote: By openness I mean code available, for me to download, compile and work on. Some code was released for Day 1 as regards the base operating system but the project is still largely being designed and developed behind closed doors. The plan is for this to move to an open model which includes the MeeGo community. What I'm asking for is timelines on when this will happen. The plan is to have in few weeks a first complete MeeGo release followed by a roadmap to work on the next release. Once this is out the MeeGo project shouldn't have any obstacle to have all the daily work and routines in the open. There might still be some areas under the shadow, but always related to new developments e.g. imagine the arrival of a new cool UX category or key platform feature. Once they are released they go to open business as usual. All this is related to two main factors: - One that is quite unique now: two big teams having to sync on 1001 little things before going public common. - One that will be around basically always: marketing factors making company X or even the MeeGo project itself to go for a sound release instead of an open development since the first line of code. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Repository Working Group - next steps
Hi, ext David Greaves wrote: quim@nokia.com wrote: Hi, I think we have a mismatch between the name and the content. 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. :) Heh :) So what about Downloads as a compromise between clarity and accuracy? I agree the name is actually quite important; now we almost have the scope we can address it. Personally, I like Surrounds. I find Downloads a little mundane and non-inspirational? Surrounds clearly says not core and is nicely embracing and quite positive :) I reckon Downloads is mundane. So descriptive that everybody understands it. ;) Surrounds is indeed poetic but I don't believe it clearly says anything to most of us here, leave alone people seeing the project from the outside. About people downloading apps, music, videos, etc... the only thing we know for sure they download are... Downloads. Let me insist on Downloads, then. :) * 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. Fully agree. My only 'worry' was that the 2 types of surround (individual applications and 'universe') would be split apart. Why split apart? The Downloads team is responsible of the QA and distribution of any downloads distributed from meego.com not comprised in the official release, including dependencies. It was good to have Mike's feedback. Now, can we have at least Bob's feedback? What is the current status and how to help and continue the work? -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Repository Working Group - next steps
ext Graham Cobb wrote: why don't we call this the Community Repositories Team. +1 Being picky someone still could say that since all MeeGo is community all repos are community repos. Still, most people do understand that one thing are the repos of software officially supported making a MeeGo release, and another thing are the repos of software containing software from all kinds of third parties. -- Quim Gil open source advocate MeeGo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Open drivers (was Re: N900 Questions...)
Hi, ext Adrian Yanes wrote: We asked to Nokia when was Maemo, this is the response: http://wiki.maemo.org/Why_the_closed_packages Arguments like brand and differentiation are present in the official response. So before involve other vendors, would be nice if your company clarify their own components. As it is pointed out in the wiki page you are linking, if you want a Nokia closed component to be open, please see http://wiki.maemo.org/Open_development/Licensing_change_requests This is meego-dev and you are asking about binaries in Maemo based Nokia products. We had this discussion plenty of times at maemo.org and you are free to continue it at maemo.org. Please limit your discussion here to the MeeGo stack and how it plans to handle closed binaries officially supported. The fact is that now Intel and Nokia are together. They can obtain these components, even without money. Do you mean that without money one can write the best drivers for latest hardware? I'm not a big fan of closed binaries for hardware adaptation but I understand that companies involved in this complex and highly competitive activity want to pay salaries and bring benefits to shareholders. Perhaps the world is not perfect but it doesn't mean that we should not have the best intentions to improve it. Looking at the IT mobile industries it looks like Intel and Nokia are actually championing with best intentions when it comes to investments in open source. This is only my personal opinion, but I think open source adoption in the mobile industry is going as fast as it gets evolving without breaking the business models in this industry. The argument pushed sometimes by free software enthusiasts (also in this thread) is that big corps like Nokia or Intel could push the free licenses further thanks to its predominant position in the market. Even if that would be true, the execution would remove a bunch of smaller innovative players from the map (acquired, bought out, pushed out of business). If that would be a better world for software freedom, I don't know. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900 Questions...
ext Adrian Yanes wrote: I understand your arguments, but we need change the vendors mentality ( didn't change Nokia?, the others can ). Nokia and Intel *have* changed vendors mentality and they keep changing it with projects like MeeGo no matter how long this thread goes. Adrian, if you want to change any mentality then this is not the best place since all here we are convinced already. You could invest your time seeing how to convince Imagination co that open drivers would be beneficial for their business. You can also inquire Nokia about Nokia binaries if you wish, following the process described at http://wiki.maemo.org/Open_development/Licensing_change_requests -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] N900 Questions...
Hi, ext Jeremiah Foster wrote: I guess backporting a lot of development that happens in MeeGo to the N900 is not in Nokia's plans at the moment. The N900 is a MeeGo reference platform. This means that MeeGo testing needs to be done against this hardware. This means that MeeGo needs to work on the N900. And this is a goal a team coordinated by Nokia is trying to accomplish already now. Although the N900 already has an awesome OS in Maemo, official support for MeeGo on the OMAP3 will probably not be done by Nokia. I think the community will have to pull down the kernel sources and build them and add in any functionality the community thinks is missing themselves to the N900 if they want a pure MeeGo release. A pure MeeGo release (an open source stack from kernel to apps) is precisely what is expected to come from the MeeGo project (in practice, a task assumed by a team coordinated by Nokia). -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] First TSG meeting on Friday @ 20h UTC
Hi, http://meego.com/community/blogs/qgil/2010/first-technical-steering-group-meeting The Technical Steering Group is having the first IRC meeting on Friday, 19 March 2010, 20:00:00 UTC time [1]. The meeting will be held in the #meego-meeting IRC channel. * MeeGo architecture update. * MeeGo release plan. * Release program setup. * Technical Steering Group setup. * Community working group proposal. * Localization working group proposal. * Appointments * AOB The meeting will be moderated and instructions will be posted in the chat room topic. http://timeanddate.com/worldclock/fixedtime.html?day=19month=3year=2010hour=20min=0sec=0p1=0 -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo Working Group at Linux Collaboration Summit 2010
Hi, ext Sivan Greenberg wrote: Hey List, Does anybody know who is going to attend this WG from MeeGo ? I will be there as well. Perhaps someone can start a wiki page to coordinate our presence there? What are the subjects and matters going to be discussed/worked on ? That was also my question some days ago as well. Basically what happened is that the MeeGo launch timing didn't play well together with the Collaboration Summit call for participation. Dirk Hohndel from Intel secured the track and actually some MeeGo related proposals were submitted through the regular process. But that was not enough to fill the schedule and it was too late to make an MeeGo-level call for participation here. So Dirk asked Dawn Foster to look for the remaining session and she is finishing the details. The schedule will be available soon at http://events.linuxfoundation.org/lfcs2010/meego-workgroup Is this event going to have any significance to the project development wise? It will be good to catch up there and discuss over drinks and in corridors in a way no email discussion can substitute. Other than that I don't expect any crucial discussion and even less decisions. For that we need to wait to the MeeGo Summit. :) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Some questions about the Technical Steering Group TSG meetings
meego.com still need some RSS love, so here is a link to http://meego.com/community/blogs/valhalla/2010/towards-day-one where some questions are answered by Valtteri. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
