Re: Maemo - MeeGo migration (was Re: maemo.org team meeting Tuesday the 14th?)
On 09/07/2010 11:56 PM, ext Andrew Flegg wrote: [Follow-ups to maemo-developers, please] On Tue, Sep 7, 2010 at 19:22, Quim Gil quim@nokia.com wrote: On 09/07/2010 10:10 AM, ext Andrea Grandi wrote: let me understand better then. If neither a migration is planned, how the Maemo Community will be related to the MeeGo one? The question is: what would you migrate or bridge from Maemo to MeeGo? Some steps being done: running MeeGo in the N900, having a MeeGo Extras process in place, [...] Without being able to reuse each other's packages - or indeed break ones own application into multiple packages - I suspect the MeeGo Extras process is going to fail: http://lists.meego.com/pipermail/meego-dev/2010-September/005525.html However, it seems that Intel Nokia in their ivory towers are concentrating on app stores and single-package applications which include all their dependencies. I can understand why, given the lead that Android (and iOS, but let's at least pretend to be slightly realistic ;-)) has, but it seems the MeeGo Spec is going out of its way to sabotage community efforts. Let Intel and Nokia care about the app store battle and let the MeGo community (you are involved with) define the MeeGo Extras process that suits your interests. Tero is coordinating the MeeGo Extras repository. I also miss regular updates about this task (see http://wiki.meego.com/Community_Office#Committed_Tasks ) but I recommend you to help getting those updates instead of (or in addition to) spread the it seems assumptions. And don't get me wrong: thank you for pushing the things that matters to you. Actually most of them matter to my work as well. It's just that what you call Intel Nokia in their ivory towers is actually a less glamorous problem that can be tracked down to specific teams and individuals. And Tero don't get wrong either. You must have your reasons not to have http://wiki.meego.com/Proposal_for_Community_Application_Support up to date and running openly, but as you see this creates problems. Thank you for helping pushing MeeGo openness! PS: now, once you are fine at maemo-developers please move this discussion to meego-dev or meego-community, where we actually can commit to MeeGo things. Thank you! -- Quim Gil MeeGo advocate ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Request: Tutorials use-cases for documentation
ext Gary Birkett wrote: excellent idea! try to allow the examples to come from different toolkits. there is more than one method of doing everything. if the same question is answered in both gtk and qt for instance, it will help existing developers to adapt and see the differences in approaching problems. There is a good point behind this which is how to cross use cases with technologies. I don't think the answer is to aim to cover all technologies equally for each use case e.g. How to get a nice % progress bar - In Web Runtime follow these steps. - In Qt follow these other steps. - In GTK+ you would do it this way. - In PyMaemo... I guess developers first make a decision about the toolkit they are going to use and then expect to find documentation specific to that toolkit. Cross-links are nice but that's it. So let's assume that use cases will concentrate on a specific toolkits. The ones we will push will be based on the toolkits officially supported, then others can add the translations to their preferred community supported toolkit if they wish. Looking at http://wiki.maemo.org/Documentation/Use_case_template it is not clear whether such links should be placed in the intro, Related APIs... Tips Tricks would force the template too much. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Qt 4.6 Extras
Hi, The Qt 4.6 libraries in Extras-devel are starting to make their way to Extras-testing as applications using them start to feel ready. However, we should avoid them landing in Extras. The reasons: - Their own maintainers (the Qt team) don't want them in Extras. They say they are not final and ready, and having them in Extras-devel was the obvious way to get the feedback that is helping a lot getting them in shape. - When the Qt 4.6 libraries are final they will be integrated in the Maemo 5 official release. We will share this plan in more detail before that release comes so the affected developers are aware and can work in sync. We all want to avoid any hassle to end users and if Qt 4.6 ends up in Extras the risk of them getting in trouble with dependencies when updating is high. So please, don't promote Qt 4.6 apps to Extras-testing and if there is any already there don't promote it to Extras. Don't worry, the Qt and maemo teams are working at full speed to get that release/update out in a reasonable time. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo code in Linux kernel?
Denis-Courmont Remi (Nokia-D/Helsinki) wrote: On Thursday 04 February 2010 12:53:22 ext Christopher Intemann, you wrote: Hello, I came across this blog-entry [1] which is describing why the Android kernel extensions were removed from the current kernel version. I'm just curious: Where does Nokia/ Maemo stand? Are there Maemo sources in the official Linux kernel tree at all? Regards, Maemo has contributed quite a few pieces of the N900 kernel upstream. To name a few that I know: - OMAP framebuffer, - WL12xx WLAN adapter, - large parts of the OMAP base port, - UBI file system, - TWL4030 watchdog, - Si4713 FM transmitter, - Phonet stack and USB drivers, - parts of the USB gadget framework. Thank you! I updated http://wiki.maemo.org/Open_development/Maemo_contributions#Upstream Feel free adding more detail in that page. I am surely missing some pieces. Not that some of the N900-related contributions were merged upstream after the 2.6.28 kernel. Obviously, there are also some parts which haven't been merged, or not yet. We are still working on upstreaming the SSI port driver (the interface to the cellular modem) for instance. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo Base Port documentation
Hi, We don't expect to find many chipset vendors in this list, but still this new doc might be interesting for those of you interested in the low level interfaces of the platform and also for those with an open source agenda. Maemo Base Port http://wiki.forum.nokia.com/index.php/Maemo_Base_Port Maemo is a Linux-based operating system designed to run on high-end Nokia mobile computers. The Maemo architecture is divided into three layers: independent applications layer, middleware layer and base layer. The base layer is responsible for fundamental OS services and first-level HW abstraction (direct HW access) and forms a runnable and testable entity as such. When Maemo is ported to a new chipset and HW environment, the majority of the SW work takes place in the base layer. However, some adjustments may also be needed in the other layers. The porting work as a whole is a combined effort by the chipset vendor and Nokia. This document describes the deliverables expected from the chipset vendor in such an effort. More: http://www.forum.nokia.com/piazza/wiki/images/7/7d/Maemo_Base_Port_v1.1.pdf -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Base Port documentation
Hi Marcin, ext Marcin Juszkiewicz wrote: Dnia czwartek, 4 lutego 2010 o 11:56:45 Quim Gil napisał(a): Hi, We don't expect to find many chipset vendors in this list, but still this new doc might be interesting for those of you interested in the low level interfaces of the platform and also for those with an open source agenda. Maemo Base Port http://wiki.forum.nokia.com/index.php/Maemo_Base_Port Which version of Maemo it covers? Rather not Maemo6 as it had to be Qt based and pdf talks about GNOME GVFS. The document is not directly linked to any exact Maemo release, but in practice it assumes roughly Maemo 6 level SW architecture and functionality with some portability related differences. http://wiki.forum.nokia.com/index.php/Maemo_Base_Port And does nokia follows this document? I think not: What you are seeing now is partially a consequence of the contracts signed years ago. This base port documentation defines the rules for the years to come. If we succeed having chipset vendors playing happily by these OSS-friendly rules then we will be able to improve our open development practices as well. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
http://lwn.net/SubscriberLink/370157/2a06baf10df8e58a/ Interesting! My personal take: 1 is to make the project depend as much as possible on difficult tools Improving 2: Encourage the presence of poisonous people and maximize the damage that they can create. sense of humourNow this makes me wonder whether I should be putting my time in this reply... politically correct smiley ;) /politically correct smiley/sense of humour 3: Provide no documentation. Actually our problem is to organize well all the documentation available. Improving. 4: Project decisions should be made in closed-door meetings. True in many cases. Half of them come from the fact of having to run a profitable business in a very competitive sector. The other half comes from an inertia, consequence of the same business reason. Improving. 5: Employ large amounts of legalese. Nokia has legalese for the Nokia actions and products. For the Maemo community we have very light http://wiki.maemo.org/Maemo_contribution_guidelines and little else. We have used NDAs with community members only to give them access to secret hardware, as per suggestion of the own community. 6: The community liaison must be chosen carefully. It has been chosen carefully, indeed. ;) Jokes apart, we have a rich community liasion including several Nokia members (some of them appointed, some of them at their own risk) specialized in their areas and, in the other end, an elected Council and a professional maemo.org development team. 7: Governance obfuscation. You might or might not agree on the part governed by Nokia, but it's clearly formulated. The community governance is decently clear and documented imho. 8: Screw around with licensing. For the feedback received it looks like the LGPL based licensing makes happy a majority of community commercial developers. Now even Qt is LGPL. Note that a % of legalese Nokia has is precisely to make sure that we act properly with licenses. 9: Do not allow anybody outside the company to have commit access, ever. Basically true for the components copyrighted by Nokia, even if there is a grey area with e.g. Hildon or Modest. On the other hand Maemo is made of hundreds of components where no Nokia developer has commits rights. I believe we have to solve other problems before this one e.g. increasing the code contributions in the first place. 10: Silence. Actually I and other Nokians would get a lot more work done if we wouldn't be active here so often. :) Let me add one point, since this is about companies nurturing communities: 11: Fail in your core business Then no matter how good you are in 1-10 your community project will fail. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
ext Jeff Moe wrote: Haha! And he even occassionally responds to comments there too! (More than Maemo's leader.) Like I said, *ideal* Linus Torvalds is chief architect and coordinator of a free software project, hired by a non-profit foundation. Ari Jaaksi is vice-president of a corporation and head of a team developing devices with free and commercial software. If you want to compare both at the same level, that is your choice. On the other hand you could reckon that is not frequent to find business managers at his level blogging and commenting with his casual and quite straightforward approach. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to destroy your community
ext Andre Klapper wrote: Am Dienstag, den 19.01.2010, 15:37 +0200 schrieb Quim Gil: I believe we have to solve other problems before this one e.g. increasing the code contributions in the first place. With regard to attaching patches in Bugzilla, it's currently probably quite non-attractive because: * It's not clear where which code repositories are located and if the code is free, and if so how up-to-date it is. Carsten Munk is working on providing an overview for this (9.11-04). Of course tarballs are available, but that means hacking ancient code. * Code reviews by maintainers often take way too long. Nokia should put a high priority on any community-provided patches, otherwise contributors get impatient and lose motivation. Sure, I was thinking about http://maemo.gitorious.org/ In the long run looking forward to seeing co-maintainership of projects. Wondering if anybody has tried yet in the Maemosphere... andre -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Bootstrapping the Maemo 6 Developer Guide
Have you ever seen a Developer Guide being created from scratch? Now is your chance, also to get involved. Complain and be bold now so we all have a better time when the time to install the Maemo 6 SDK comes. :) http://wiki.maemo.org/Developer_Guide_table_of_contents I have started the discussion at http://talk.maemo.org/showthread.php?t=36646 since I believe we are getting many newcomers (and less Linux experienced) developers there. You can give your feedback here if you prefer. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Double checking free/nonfree packages
Hi, Tamminen Eero (Nokia-D/Helsinki) wrote: Hi, ext Christopher Allan Webber wrote: For now there seem to be two main pages on which the documentation of what is free/nonfree is: - http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Top_Level_Architecture - http://wiki.maemo.org/Why_the_closed_packages The first contains that rather informative graph, but I suspect that the intended purpose of that page would be made less useful if we put all of the documentation of free/nonfree components on there. The second one seems to be a good start, I think main issue is that it's not really updated for Fremantle, a lot of the stuff there would seem to be Diablo release specific... True. It looks like in 2010 I will be able to concentrate more % of my time doing tasks directly related to my role as open source advocate, since others will be able to cover more and better the time I'm putting in developer and maemo.org topics. but I think the naming of that particular page helps defeat our purpose, as it seems to say here is why these are closed as just an explanation, and does not indicate this is a record of pieces that we are working to free. Feel free taking the co-ownership. The first question I get when asking about opening a component is whether there is a true community interest to do work and collaborate around the source code opened. This is a common interest. I guess you don't want us to put our time opening components that nobody actually needs or cares about beyond a nicer percentage of openness. So, unless there are any objections, I think it would be better to start a page with a name such as Free_Maemo or something similar that indicates a kind of free and open source todo-list that I think everyone here seems to want. I'll work on incorporating the Why the closed packages page within that document, and if that proves to be satisfactory, we can probably have the Why_the_closed_packages page redirect to the new one. Do whatever you think it's best as long as we end up having one useful and well maintained page as opposed to 2 half backed and poorly maintained pages. What about following page structure? Index page: * with explanation about: - Why it makes sense to open sources and what should be prioritized (the list below) - Why Nokia has some packages closed (top part of existing page) * Link to page listing closed packages in Diablo (bottom part of existing page) * Link to page listing closed packages in Fremantle * Link to TODO list(s) about opening or replacing above packages with free alternatives The criteria to prioritize components could be (improvising a bit, feel free to suggest improvements): 1. Fixing a bug. I mean a real objective bug: package is in non-free although it looks like it's actually an open piece of software. 2. Nurturing application development. There is a strong argument proving that opening a component will bring more and better apps for end users. 3. Spread of Maemo driven technologies to other platforms. A component fits well in a gap existing in other Linux/OSS based projects and there is a concrete interest on collaborating and contributing to a component if it's opened. 4. Community maintenance. A component is receiving low attention from the official maintainers even if it has high attention from the community and there are developers volunteering to contribute to it if the source code is available. 5. Better architecture. Probably covered by 2 or 3 but just in case. A closed component is sitting in the midle of open components making things more difficult that needed to developers interested in that area. Good list! Glad you like it. :) Now it is here: http://wiki.maemo.org/Open_development/Why_the_closed_packages#Requesting_the_opening_of_closed_components -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Any new information on Developer Device Program?
ext Eugene Antimirov wrote: Quim, can you confirm that old orders are still valid and it's just a notification email we got? If you have questions please contact the email address of the device program, as explained in the invitations sent. Thanks! -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Double checking free/nonfree packages
ext Christopher Allan Webber wrote: Funambol SyncML --- Claims Funambol is the leading mobile open source project and leading provider of open source mobile cloud sync and push email for billions of phones. https://www.forge.funambol.org/DomainHome.html If it's open source, is it really nonfree then? Appears to be under the AGPL? https://core.forge.funambol.org/source/browse/core/trunk/LICENSE.txt?revision=28308view=markup Dual licensing. In short, the Maemo team went for the commercial license to avoid legal risks linking open/closed components. xml2wbxml - Appears to be linked to the wbxmllib project, which is under the gpl? http://sourceforge.net/projects/wbxmllib/develop No, it's an own implementation of the WBXML specification. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developers Guide
ext Dave Neary wrote: I tried the wiki and forum nokia... Forum Nokia also has some useful information - especially pertaining to widget style guides, UI guidelines and such. In fact http://www.forum.nokia.com/Tools_Docs_and_Code/Documentation/Maemo.xhtml has many interesting docs For instance, Get Started with Maemo 5 http://www.forum.nokia.com/info/sw.nokia.com/id/0ea5ec64-2d35-4363-94c0-dd2560c6524b/Get_started_with_Maemo_5.html And even somewhere else http://wiki.forum.nokia.com/index.php/Qt_for_Maemo_Developers_Guide The question is how to link things properly so it's easy to find all things Maemo for developers. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Double checking free/nonfree packages
the source image and link to it instead of forking it. Otherwise the chances of you having a version different to the one in the official documentation is high, when there should not be any reason to show anything different. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Updating the info for Extras-devel non-free
Hi, the information to upload binary-only packages to extras-devel is out of date: http://wiki.maemo.org/Uploading_to_Extras-devel#.22non-free.22_packages Yet there are several non-free packages in extras-devel extras-testing / Extras. Can someone please update the wiki information reflecting the current practice for Maemo 5? We are seeing more questions about this and actually the current information is misleading since it suggests that non-free packages can bypass the Extras-testing QA process, which is not true. Thank you! -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [Fwd: Re: Maemo Barcelona Weekend: best way to ask for help for a UI?]
ext Thomas Perl wrote: 2009/11/19 Andrea Grandi a.gra...@gmail.com: 2009/11/17 Quim Gil quim@nokia.com: Don't expect them to know the insights of Python/Hildon, though. They obviously know the Maemo 5 UI but how you get things done with code is a different matter. Anyway, there will be other colleagues attending and some GTK+/Hildon Qt specialists in the other activities. this was a dart directed to Thomas :) I hope we can find some minutes to sit down, drink a beer and talk about how to organize the UI of my app :P Of course, will try my best to help with technical questions about PyMaemo/Hildon/GTK+ there :) Maybe we should have a map of people and technologies on the Wiki so that when one needs (technical) help with a specific technology, he/she can look up the name of persons that have worked with that technology before? Ideally, everyone can then add technologies they are working with (Qt, GStreamer, GTK+, Hildon, Python, ...), so everyone can make the best use of the time at the event.. Would such a wiki page make sense? Would attending developers be interested in adding their fields of work/interest to such a page? Don't forget that in the neighbor room there will be a developer training track. Feel free jumping there to ask questions or bringing experts to your room. The whole schedule is flexible - and yours by the way. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [clutter] Clutter 1.0 in maemo fremantle
ext Wang Baisheng wrote:
Hi Alberto,
Clutter 1.0 for maemo fremantle is available ?
Please use the search at http://maemo.org/packages
http://maemo.org/packages/view/libclutter-1.0-0
--
Quim Gil
open source advocate
Maemo Devices @ Nokia
Thanks,
Baisheng
在 2009-09-05六的 13:56 +0300，Alberto Mardegan写道：
Update:
Alberto Mardegan wrote:
JiangWei Zhou wrote:
you may remove the EGL_STENCIL_SIZE, 8 from the egl config list
and try again.
i just wonder it may cause this problem. but in our target, there is
no such problem.
I checked the source code of clutter-0.8 in maemo, and with that
attribute list it worked. Then I try to remove the differences one by
one, to reduce them to the minimum: strangely enough, the problem is in
specifying EGL_{RED,GREEN,BLUE}_SIZE. Removing them from the attributes
array make the whole things work.
I guess I won't submit a patch for it, as the change is maemo-specific:
I cannot see any reason why specifying those sizes would break the thing.
Anyway, I'm happy to announce that I got clutter 1.0 and clutter-gtk
0.10 to work fine in maemo fremantle. I'll create a project in
garage.maemo.org and upload the packages as soon as I've cleaned them up
a bit. :-)
Thanks for your support!
Alberto
--
http://www.mardy.it - geek in un lingua international!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: individuals being able to join Ovi store
ext Graham Cobb wrote: A reminder... this discussion is happening in: http://talk.maemo.org/showthread.php?t=34661 It actually jumped to Confirmed/CAUTION: N900 Ovi Apps require Corporation + $1M USD Corporate General Liability Insurace http://talk.maemo.org/showthread.php?t=34783 For the specific case of open source applications published in Ovi there is this Brainstorm proposal where I'm trying to know what the Maemo community thinks that would be the best approach: Open source software distributed via store.ovi.com http://maemo.org/community/brainstorm/view/open_source_software_distributed_via_store-ovi-com/ Please vote and discuss at http://talk.maemo.org/showthread.php?p=385610 -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
REMEMBER: UX meets Code hackfest in December @ Barcelona
Just in case you missed or forgot this: http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend/UX_meets_Code There is a lot of warming up in the UX / organization side, and we are getting a good bunch of professional designers ready to help developers improving their apps. But what we start to miss now are... the developers with the cool applications! REMEMBER TO REGISTER! We are sponsoring 17 participants at the moment (see the list at http://maemo.org/news/events/maemo-barcelona_long_weekend/ ) and we have still budget for some more. HURRY UP! -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo - Barcelona Long Weekend en español
[[[Sorry for the spamming, this is an email specifically for the Spanish speakers in the house. Forwarding to your Spanish speaking friends is also welcome (even if they are not developers!) as long as they have an interest in Maemo and the N900.]]] http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend Por si acaso no ha quedado muy claro, el Maemo - Barcelona Long Weekend en Barcelona está cargado de actividades en español dirigidas a programadores y también usuarios interesados en conocer más sobre Maemo, y la Nokia N900. El viernes 4 de diciembre hay sesiones de interés para usuarios y programadores, incluída una oportunidad para probar la N900, ver demos en directo y encontrate con miembros de la comunidad de maemo y Nokia. También hay un track de formación durante todo el fin de semana de acceso libre y gratuíto (pero registro obligatorio). Nivel básico e intermedio para aprender a programar con GTK+/Hildon, Qt y lo que se ofrezca (la agenda es flexible). Además, como es habitual en los encuentros de Maemo los expertos de la comunidad abundan y tendrás ocasión de consultar tus dudas con ellos, etc. Y bueno, aunque lo importante es el conocimiento y el intercambio, también es interestante saber que estamos sorteando Nokia N900s entre los participantes... Lee la letra pequeña en The Barcelona Long Weekend raffle! http://talk.maemo.org/showthread.php?t=34390 -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
[Fwd: Re: Maemo Barcelona Weekend: best way to ask for help for a UI?]
Forwarding since this email in maemo-community is more relevant to developers. If you have more questions about the Maemo - Barcelona Long Weekend please ask. http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend Quim ---BeginMessage--- 45 people registered at http://wiki.maemo.org/Maemo-Barcelona_Long_Weekend - 11 of them with accepted sponsorship. Hurry up if you want to join us! Also please help promoting the event. Make sure your friends based in Spain know about it. Make sure the developers of your beloved applications know about it as well. Yes, you can make a difference by micro/blogging, forwarding a bringing the topic to relevant forums. ext Andrea Grandi wrote: I'd like to ask for help for this but I think that a slot in the three days is too much for this application, surely there are more important one to discuss. Will we organize short session where people like me can ask help to more skilled people? Don't get obsessed about not getting a slot in the official agenda. These sessions are not meant to keep all the people wrking in that project. It's more a reference in the schedule and an activity for you to follow and get involved if there is nothing else/better you find for that particular time. The idea is that you help yourself by helping others. You learn by discussing with others about how to improve their projects. We are working to have enough UX specialists in order to have someone available basically at any time. In particular I need help in Python + Hildon field (maybe I should offer a beer to a person I've in mind and probably he will help me... let's see if he reads this :D ) Don't expect them to know the insights of Python/Hildon, though. They obviously know the Maemo 5 UI but how you get things done with code is a different matter. Anyway, there will be other colleagues attending and some GTK+/Hildon Qt specialists in the other activities. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-community mailing list maemo-commun...@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-community ---End Message--- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
ext Dave Neary wrote: Hi, Quim Gil wrote: We are asking the renaming of pure end user apps called Maemo Something in order to avoid confusion of what is official and what is not. Just to be clear, when you say what is official, what do you mean? A piece of software that Nokia is responsible of, and therefore customers can complain to Nokia about. Is this applications shipped with the device by default? Or applications created by Nokia? Or applications in the Nokia applications repository? I'd like to think that eventually, applications written by anyone in the community can become official and be installed by default in future Maemo devices, if they prove themselves capable. Cheers, Dave. (For the rest, I agree - if we're not talking about user-targetted apps, the impact is small - I just want to clarify the meaning of the often-used word official) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
popularity-contest (was Re: Follow up from QA meeting on IRC)
Hi, ext Edward Page wrote: Which reminds me, any reason Maemo doesn't use Debian's popularity contest? At least at a community level there is https://garage.maemo.org/projects/popcon/ -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
ext Jeremiah Foster wrote: Can we change the name of the package? I know that is PITA, but you risk running afoul of Nokia if your package name begins with maemo, trademark and all that. Can you just swap it around to version-maemo? We are asking the renaming of pure end user apps called Maemo Something in order to avoid confusion of what is official and what is not. In this case we are talking about little utilities relevant only to SDK users, am I right? The impactb is minor. If the utilities are really useful then why not even consider them to be officially supported at soe point. Gabriel is a busy guy and I'd prefer not to bother him with this. ;) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing marathon QA Feedback
Hi, In general I think that new apps should tend to get all ratings reseted if they go back to extras-devel because of a blocker, while app updates would keep their current positive ratings through new extras-testing iterations. This way we are conservative with new apps but more liberal with updates. Makes sense? ext Ville Reijonen wrote: Hi, But the time should be better split. The basic feedback I got from busy Nokia employees with devices, professional experience and willingness to help is that the thumbs up/down should be applied to each QA criteria. Yap, this I suggested. Good that this is verified. So, it should be possible to give thumbs up for single item on the QA list. This of course means that current 10 upvotes system does not work as is. Proposal below (feel free to hack): -Every package has minimum 10 days of quarantee. -Package overstaying over a month is booted back to devel. (If it is not accepted by then, it will never be) -Package retains its history for later viewing. (Nice to see what has happened before) -Every package has QA list. (Based the current wiki list - the testing criteria) -Every item on the QA list has to be examined before acceptance. (The procedure should be the same for all) -A person can check one or multiple QA items. (Do what you are good at or what you have time for) -Same QA list item can be checked by multiple persons. (Never trust a single person, or do we? High karma - power of two) -Some QA items can be checked automatically. (optification for example) -Bugfix will reset the quarantee timer. (The quarantine was clearly working, some more is therefore needed) -Bugfix will remove the second upvote for every QA item. (Bugfix can introduce other bugs, better to be sure) -A qualified application is released to extras. Looks good overall. - If something can be checked automatically then it must be moved to the jump between extras-devel to extras-testing, where the automated tests are done. - Maybe it would be good to present user karma next to their thumbs? It would be useful to have an approximate idea of the experience put in an evaluation, or at least it could be useful when someone is trying to game the system creating a bunch of virtual users. - Maybe 3 thumbs up in each criteria is enough? I mean, if someone with high karma (read community reputation) says in the Power Management entry I have run powertop and this app is fine next to his thumbs up... most of us will give thumbs up only after checking that indeed our battery is not drained after installing the app. - If an app is dumped back to extras-devel because of a blocker in one row, the karma there should be reseted but the other rows could just stay. As said, feel free to modify. First is always rough.. :) ditto -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing marathon QA Feedback
ext Ville Reijonen wrote: Is the approval/karma process going to be actually a popularity contest? Popular titles get votes fast, a niche software will not. Unless there is regular testing marathons, I think this will be an issue. I believe this problem will be solved as soon as we have the first thousands of real users. Very popular apps will get a critical mass of testers ready to process new releases. Very specialized apps... too. You only need a dozen of committed users. Then it ight be that new fresh apps take a while to get enough testers and it might be that the first jump to Extras is difficult. Having a brigade of mercenary testers might help, sure. But if after some time an app still hasn't got enough interested to atract a dozen of regular testers... well, it might be that such project has other deeper problems due to lack of user interest. We need more people doing this, so the effort could be split (e.g. tester group A checks one app while tester group B checks another). One can not test everything on virtual machine. For good testing, one should have a device with a default setup so the effects can be observed - ie. energy usage, system configuration changes, compability, etc. Good testing takes quite a lot of time. But the time should be better split. The basic feedback I got from busy Nokia employees with devices, professional experience and willingness to help is that the thumbs up/down should be applied to each QA criteria. If you are asking me to give thumbs up / down on 10 criteria the realistic options are: - I won't rate. - I will rate ignoring some QA criteria. - I will rate after investing a lot of time and skills. If instead the rating would be done by QA criteria then it would be easier to see whet are the parts missing testing. Someone might find interesting to test optification because it's simple for him, and this will save the testing to another one more interested on crashes, or legal aspects, usability, etc. I believe this idea needs further thinking. This might be a big part of the solution. Additionally, I would think that one does not want to just put any packages for testing on personal device with personal data. You might accept the risk for software you like (and trust for some reason), but not for all random packages - popularity contest. As comparison, nothing should never be tested on a server in production. The N900 is not a server. There is not lack of people out there ready to install testing versions of Debian, Ubuntu, Windows, Firefox and long etc for their primary use. For instance, that has been my case for many years and for something like my laptop = 100 times more critical than my mobile device. Maybe this manna/karma thing has been though out, but somehow if feel that the research for similar systems was not done before rolling it out. There seems to be too many holes, and I just though a while. Every serious linux distribution has some kind of QA system. Most of the software makers have QA systems. Do not invent the wheel again.. URLs proving your point, please? Not every Linux distribution has the consumer focus of Maemo 5 / N900 and definitely not every Linux distribution needs to handle specific problems of mobile devices. Besides, not every Linux distribution pay actually much attention to the application packages being pushed by its contributors and it takes only 10 random installs from your distro to find out. So no, there are not that many references for community QA models. I believe the Extras QA process is highly innovative and it has its chances of serving a useful purpose to the rest of the free software community. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Source code Kernel drivers Maemo 5
ext Adrián Yanes wrote: Thanks Quim for your explanation. I am waiting impatient the release, I have a lot of interest in some drivers. Could it be that they are already contributed to OMAP kernel? I believe we are more or less up to date with Maemo 5 kernel contributions. -- Quim Gil open source advocate Maemo Devices @ Nokia Regards, Adrian. 2009/11/2 Quim Gil quim@nokia.com: Hi Adrián, ext Adrián Yanes wrote: Hi, I was checking the kernel's source realease with Maemo 5 ( linux-2.6.28 ), correct me if I am wrong, but some drivers using in N900 aren't in this kernel's version . (Altought they ara avadaible in to be installed like modules using a deb package). It is correct or I am checking the wrong version? The kernel sources published correspond to the Maemo 5 Final SDK. http://www.forum.nokia.com/info/sw.nokia.com/id/c05693a1-265c-4c7f-a389-fc227db4c465/Maemo_5_SDK.html The N900 is not in the shops yet and there is no public Maemo 5 image available. Some testers have a pre-production unit with a pre-sales version. We didn't make a formal release for this, and we will do it once the N900 starts selling with the stable release. Thanks, Adrian. PS:I was checking the next sources: http://repository.maemo.org/pool/fremantle/free/k/kernel/kernel_2.6.28.orig.tar.gz http://repository.maemo.org/pool/fremantle/free/k/kernel/kernel-modules_2.6.28-20093908+0m5_armel.deb -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Source code Kernel drivers Maemo 5
Hi Adrián, ext Adrián Yanes wrote: Hi, I was checking the kernel's source realease with Maemo 5 ( linux-2.6.28 ), correct me if I am wrong, but some drivers using in N900 aren't in this kernel's version . (Altought they ara avadaible in to be installed like modules using a deb package). It is correct or I am checking the wrong version? The kernel sources published correspond to the Maemo 5 Final SDK. http://www.forum.nokia.com/info/sw.nokia.com/id/c05693a1-265c-4c7f-a389-fc227db4c465/Maemo_5_SDK.html The N900 is not in the shops yet and there is no public Maemo 5 image available. Some testers have a pre-production unit with a pre-sales version. We didn't make a formal release for this, and we will do it once the N900 starts selling with the stable release. Thanks, Adrian. PS:I was checking the next sources: http://repository.maemo.org/pool/fremantle/free/k/kernel/kernel_2.6.28.orig.tar.gz http://repository.maemo.org/pool/fremantle/free/k/kernel/kernel-modules_2.6.28-20093908+0m5_armel.deb -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Tentative: UX meets Code hackfest in December @ Barcelona
Re-post made at http://talk.maemo.org/showthread.php?t=33719 - please reply there if you are interested in order to track the feedback in one place. Hi, an idea we are cooking these days: Maemo community developers and user experience professionals meet 3 days with 3 main goals: - Improve the usability and visual appeal of great Maemo apps. - Improve the UX documentation for Maemo developers. - Get a critical mass of people interested in pushing forward UX meets Code activities online and face to face. Idea: December 4-6, Barcelona. About 50 people invited. We are lining up the right UX professionals from the Maemo team, Forum Nokia and developer partners. Who is interested? Please provide in this thread - Your maemo.org profile making sure that there one can find info about or links to your current projects and your interests in Code or UX. - If you are more into Code, a link to the app hosted in maemo.org, either under Fremantle packages or OS2008 Downloads. - If you are more into UX, a link to wherever your work can be seen. If we have a good response we will confirm the event. Forward this to your colleagues working on great stuff! For budgeting and also practical purposes we will keep the number of participants around 50 people even if we get more requests. The criteria will be defined more or less by fast response, travel costs, community involvement and of course Maemo excellence in Code or UX. General feedback about the hackfest itself is also welcome. We will share here more news. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Extras QA checklist
Hi, ext Andrew Flegg wrote: Hi, Quim's done a sterling job producing a first draft of the Extras QA checklist. This is the list of things which need to be checked before an application should get a thumbs up in the packages UI[1]: http://wiki.maemo.org/Extras-testing/QA_Checklist Thanks Andrew. So... with this I interpret my task 9.08-10 Draft quality guidelines for extras-testing to extras promotion is DONE and you continue with 9.08-11 Document communicate packages interface to testers BUG TRACKER ~~~ My own issue is the XSBC-Bugtracker requirement. Some applications really are trivial and having this as a blocker doesn't make sense to me; after all, testers can leave comments against a specific version in the packages UI and most end-users don't raise bugs IME: http://wiki.maemo.org/Talk:Extras-testing/QA_Checklist#Bug_tracker So this could be an automatic check from extras-devel to extras-testing making sure the field exists and is filled with a value starting with http://; For starters and for simple apps is good enough to add http://maemo.org/packages; as bug tracker. But if things get more complex then testers should encourage the developers to have a propoer bug tracker in bugs.maemo.org or elsewhere. If we all agree then we can implement this in the extras-devel automated tests and remove it from the Extras-testing QA checklist once it's proven to work. DUBIOUS CONTENT ~ The phrases here include promote or endorse the misuse of alcohol, tobacco, illegal drugs or other addictive substances and promote gambling. These are weasel words. What about Dope Wars[2] or a simulated gambiling poker application? What about an actual online gaming application? I think this should be a SHOULD NOT and contain excessive and/or likely to cause offense. Yes, agreed. I didn't know exactly where to start so I took the Ovi guidelines almost literally. META-DATA ~ * I think a good package description should be a MUST. * I think XB-Maemo-Icon-26 should be a SHOULD. * I think XB-Maemo-Display-Name should be a SHOULD (there are apps, like vim, which don't require any capitalisation or spacing changes over and above the package name). Sounds good. About the responses, it looks like we are trying to find corner cases that according to the written word would be approved/blocked. Let's not forget that ultimately such guidelines need to convince at least 10 very human testers. Common sense is expected to prevail over the literal written word. It's difficult to describe beauty but it's easy to recognize it when you see it. We can fine tune the ugly corner cases as they come. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-testing and WONTFIX ?
ext Till Harbaum / Lists wrote: Hi, Am Samstag 24 Oktober 2009 schrieb Andrew Flegg: The QA criteria aren't very stringent and can be summed up as play nice, don't waste battery, try to use /opt. Any package which gets 10 thumbs up can be promoted. So, in your hypothetical case, a if the developer won't fix a bug but 10 people still think it's worthy of going into Extras, the developer will have that opportunity. In fact exactly that happened with gpxview. The fremantle port uses a gtknotebook with bottom tabs. This isn't themed and is a WONTFIX in fremantle (and not documented anywhere, btw) and looks a little bit odd. But it i got the permission to move it to extras, anyway. Looks like a non-blocker: http://wiki.maemo.org/Extras-testing/QA_Checklist#Non-blockers Developers are encouraged to adopt the Maemo 5 UI guidelines and optimize their application to finger use. However, lack of Maemo 5 UI optimization is not a reason to block an application in its way to Extras unless it is unusable even with stylus. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: extras-testing and WONTFIX ?
Stoppa Igor (Nokia-D/Helsinki) wrote: Hi, my (biased) pov is that at least excessive power consumption should be a blocker. It is a blocker: http://wiki.maemo.org/Extras-testing/QA_Checklist#Power_management_issues The problem I see now is that either you know about power management issues and how to detect them or you don't. it would be great to have really basic documentation telling testers like me to install whatever tools, follow clear steps and evaluate the output. I understand such output is not yes/no, but it would be good to have something like: - Run Tool X, boot the application and leave it a whole night running. If in the morning you see XYZ then the app is probably buggy and draining your battery. Ans similar cases like this for widgets running or not in the background and etc. In fact, the simpler the docs are for testers the simpler they will be for developers unfamiliar with power management tests and, hopefully, the more power friendly even extras-devel software would be in the first place after some iterations. It is proven that normal users (and many times even power users) don't usually really grasp the problems related to running badly written applications and end up blaming the whole system. If someone is writing some code to scratch a itch, the devel repository should be more than enough, and he can anyway try to hand over the project to someone else, with time and will, who can bring it to the quality level required by Extras. But refusing to fix bugs and whining about not being admitted into Extras because of this is just lame behavior. igor -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo.org/packages and bug tracker url
ext Graham Cobb wrote: On Thursday 22 October 2009 16:04:41 Luca Donaggio wrote: Is the proposed XSBC-Bugtracker field to specify an alternative bug tracker used by the package interface at the moment? Yes. The GPE packages in extras-testing are using it. Hi, is there a canonical place documenting this? If so, please link it at http://wiki.maemo.org/Extras-testing/QA_Checklist#Lack_of_bug_reporting_database Thanks! -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
extras-testing QA checklist (proposal)
http://wiki.maemo.org/Extras-testing/QA_Checklist Feedback please. This checklist is common for developers (before promnoting their applications to extras-testing) and betatesters (before giving them farewell to reach Extras). It would be good to have more specific instructions to measure performace and power management, since sometimes the problems are not obvious specially in only one session or even a couple of days of casual testing. This has been posted at http://talk.maemo.org/showthread.php?p=355270 as well. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
SDL + OpenGL = testing needed
Hi, the SDL libraries currently shipped in the Maemo 5 SDK and device come without OpenGL support. This is a problem for games like Frets on Fire: http://jyro.blogspot.com/2009/03/frets-on-fire-on-maemo-5-fremantle.html http://jyro.blogspot.com/2009/03/fof-pyopengl-minifof-possibly-for-n810.html Now there is a package with the SDL libraries recompiled with --enable-video-opengl. See https://bugs.maemo.org/show_bug.cgi?id=4177 We are looking for testers in order to make sure that the new package would actually work without affecting performance or stability for non-OpenGL, plain SDL games. fwiw Talk discussion thread started at http://talk.maemo.org/showthread.php?p=353549 Thank you. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification breaks package on upgrade from non-optified older version
ext Thomas Perl wrote: Hello! In the latest version of gPodder (written in Python), I have started using maemo-optify. It saves around 1 MB according to maemo-optify's output. The problem is that now when a user upgrades from an older version to this version, it breaks (the user cannot start the application from the icon, and starting it from the command line tells me that Python can't find the gpodder module). Uninstalling and re-installing the package fixes this problem, but I assume there will be lots of users upgrading from the current version in Extras (non-optified) to some optified version in the future, and they won't just try to uninstall and re-install it and assume that the application is at fault :/ lots of users before sales start = actually not that many and all of them quite savvy and even probably reflashing at this point. Thanks for you report though. It's clearer that unless we find several solutions the time for optification is NOW, or whenever a developer is pushing a first release to Extras. Is it possible to fix that problem somehow? Or should I just disable optification? Another problem is the slower startup speed, which is really noticeable now. That's another reason why I would like to go without optification. Thanks, Thomas -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo Summit hotel room allocation - spare rooms
Hi, ext Valerio Valerio wrote: Hi, we've some spare rooms/beds at the Ibis hotel[1], since the rooms are already paid, we'll give the opportunity to no-sponsored participants to stay there. All the rooms have two beds, we don't have any single room booked. I have just listed the only 3 rooms that will be taken by Nokia. Most people at Nokia had booked their accommodation already, so it was not easy to drag new ones. This means that more rooms are available. Please fill them! The hotel asks us to send the list of people in advance, by Monday if possible. Thank you. If you're interested in one of those rooms, please send a e-mail to coun...@maemo.org mailto:coun...@maemo.org . We'll attribute the rooms in a first come first served basis. [1] - http://www.ibishotel.com/gb/hotel-1556-ibis-amsterdam-centre/index.shtml Best regards. On behalf of the Maemo Community Council, -- Valério Valério http://www.valeriovalerio.org -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to use extras-testing correctly?
ext Aniello Del Sorbo wrote: I am not developing for Apple because of their approval process and their desire of control. What is your opinion about Deboan, Ubuntu, Fedora... all of them having also QA processes in place in order to make it to their stable releases? I don't want my application to go through an approval process to reach my users. I think that the developer HAS the last work on whether or not her application is ready to be promoted to Extras. Your work as an individual developer has an impact on the overall image the Maemo platform and even the Maemo devices have in the hands of real users. maemo.org wants to keep good quality for community applications and this is why this community qa process was started. You can still skip it completely by convicing your users to install the version in extras devel, go ahead with your own repo... From a community point of view you are simply not encouraged to do so and follow the QA process. But I like the idea of my application being tested and I'd love to get feedback from the final users. Android has a nice approach, I think the application goes straight to Market and when a user removes it, she's being asked why. After going through http://www.android.com/us/developer-distribution-agreement.html - which I reckon I haven't read entirely. I learned that the extremes are almost never the best choice. Thus, I would like to see is a mix of Apple idea of testers and Google Android uninstallation survey. Here's my proposal: We leave Extras-Testing as it is, with votes, comments, bug reports an so on (or improve it, as you wish). But then it's only the developer that decides, based on that feedback, if or not to promote the application to Extras. When the application gets promoted to Extras, people will start using it. If there's a major bug, the user will uninstall the application. The Application Manager should ask the user, as Android Market does, WHY she uninstalling the application. Of course she may choose not to give any feedback. One of the choice she has is Uninstalling because of a bug and she can fill in the bug if she wish so. Implementing this in the Application Manager before the Maemo 5 final release is impossible. Only debating it here might take longer. This bug goes straight to bugzilla for that application and we should count them and decide on two limits: a soft threshold and a hard one. Soft threshold: if the application goes below this soft limit a yellow flag is raised (how to handle it, it's another topic). Hard threshold: if the application goes below this hard limit a red flag is raised and application pulled from Extras. This way the Developer has full control of when and how she wants her application to reach the public. The Community has some control of which applications should be removed. A good application with a good developer stays there. A good application with a slow developer might get a yellow flag and developer may feel pushed more to fix bugs A good application with a bad developer might become buggy over time, outdated and gets pulled out A bad application with a good developer has a better chance to become a good one A bad application with a slow developer has its life on the edge of a razor.. be ware A bad application with a bad developer is dead and not in Extras. Aniello 2009/9/24 Quim Gil quim@nokia.com: ext Fred Lefévère-Laoide wrote: I know you can't force people to vote or test ... But it means that if an app has a very limited public it doesn't get out of extras-testing ? This is a very good point. I believe it won't be an issue once there are more people with devices able to vote, but still. Something that would help is to have a strict chronological sorting at http://maemo.org/packages/repository/qa/fremantle_extras-testing_free_armel/ so oldest submissions are always on top. And encourage people to help kicking the apps on the top even if they don't use it normally. At the end it's not that hard to give an app a shot and look whether the basic QA factors are in place. I believe after the N900 sales start there will be also a sustainability approach for the applications not used by many. Some will be highly specialized with a small but committed audience that will help testing and ranking. If a bug goes through they will be the ones suffering it first. :) Some will be just starting and have a real small audience. But well, in such cases a bug going through won't cause much harm either. In most cases as the audience grows the less obvious bugs will pop up and then the developer will need to respond with newer and better versions. If major bugs are standing without fixes and the users of the app increase, then the relevance of the bug will increase as well and it might imply at some point the demotion back to extras-testing. -- Quim Gil open source advocate Maemo Devices @ Nokia
Re: How to use extras-testing correctly?
ext Graham Cobb wrote: By all means add a comment if you are unhappy with the UI but it should get a +1 as long as it doesn't conflict with the requirements. Ideally every -1 should require a comment saying which of the QA requirements is violated. Agreed. And even better, a link to a bug report with Major severity or worse. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to alter package karma in extras-testing?
ext Till Harbaum wrote: There's this package karma box with those thumbs-up and thumbs-down icons. But clicking them does nothing. How do i rate something?? It does something, but it takes a long while. It's just the same with News and Brainstorm. I just don't know why the thumbs can be automatically colored. Wasn't that the beauty of Ajax? :) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Considering /opt and MyDocs in your packages
ext Attila Csipa wrote: To reiterate, my main concern is that it has been said that for various (perfectly understandable) reasons, libraries are NOT to be optified. I haven't followed all the email from this thread but until yesterday libraries were thought to be good candidates for the /opt and actually specific examples for Python or Qt were given. including dependencies. You can't really count the size of those, as they might have dependencies of their own, some are parts of the OS, and most of the time you don't know how many other apps will use them (if 100 apps depend on a 400KB package, there might be more ratio to optify it than if it's just one app depending on a 600KB package). The Application Manager does make a size estimate, I would say useful enough. Before installing the first Python app all the Python apps are very thick in the AM. Once you have the Python libraries most of them are quite thin actually. In practice, if the maintainers of libraries have done their homework optifying properly and we still agree with the 500kb rule, I beliebe this whole /opt thing will affect only a bunch of developers very conscious about the weight of their software and the problems it might cause to average users. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Considering /opt and MyDocs in your packages
Hi Maemo developers, This is an important information specially for those handling large packages. You can find an online version updated at http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing/Installing_under_opt_and_MyDocs (or http://tr.im/yeWM in short) The N900 has about 100MB of free space in the root file system partition. This is not very much and would fill up quite quickly when installing additional applications. As a workaround, the /opt directory has been linked to a different partition with more space (about 1 GB) and /home/user/MyDocs is also available in certain cases, with even more space (about 25 GB). Developers are encouraged to make good use of them, specially for applications requiring more than 500KB, including dependencies. /opt as a good alternative The /opt directory is on an ext3 partition that is permanently mounted. Users cannot mess with it by accident. Of course, not everything needs to be moved to /opt: configuration files are best left in /etc, for example, and there is no point in moving small files like the various *.desktop and *.service files. The maemo-optify tool helps developers to prepare Debian packages that use /opt. This tool moves selected files inside the package to locations under /opt, and will symbolically link from the original location to the new place of the file. An early version of the tool can be found at http://gitorious.org/maemo-af/maemo-optify - see the README file for details. [edit] Considering /home/user/MyDocs The /home/user/MyDocs directory is another candidate for large collections of data files included in applications such as game graphics or maps. Using /opt is mostly transparent to package maintainers and end-users, but /home/user/MyDocs needs more careful consideration. The /home/user/MyDocs partition uses VFAT as its filesystem (which has some limitations compared to ext3) and it is removable: it will be unmounted and exported over USB when the user plugs in the cable. Also, /home/user/MyDocs is visible in the File manager. This all means: * You need to be aware that VFAT isn't really a POSIX filesystem. Things like symbolic links, permission bits, etc wont work as nicely as they do on a real POSIX filesystem. * You should be prepared that your files aren't there at all while the partition is unmounted. You should also not prevent the partition from being unmounted because you keep some of the files open. * User might see your files, could get confused and try to delete or rename them. In summary, you can't really put programs, libraries or theme graphics into /home/user/MyDocs. Instead, use /opt for these. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: New apps for fremantle with Qt?
Hi! ext Alberto Garcia wrote: Nokia has already announced that they're switching from Gtk to Qt in Harmattan (which has been a confusing move for many users and developers), but I don't know if they plan to keep the same basic widgets and UI style that has been designed for Fremantle or not. If the plan is to keep more or less the same UI style I'd expect a decent, community-supported, release of Gtk/Hildon for Harmattan. We will start talking about the Harmattan UI plans in the Maemo Summit, with plenty of time to discuss and develop before any Harmattan final release gets in the hands of the users. The Maemo Summit is a also a good place to start discussing the future of Hildon/GTK+ in the hands of the community. We want to see what is the community interest and how can we help getting this community support in the Harmattan time frame. What about a BOF in the Maemo Summit? I have seen several developers registered that are familiar with GTK+ and Hildon and even upstream maintainers. Some of them are currently working in Fremantle, and will probably keep working during the maintenance period. There are also Nokia developers registered that are working on the Harmattan UI framework based on Qt, the Qt developers themselves... I bet that you could share a room for one hour and get some ideas started, then dinner, beers and a draft plan. :) Our aim is to pull Qt to Fremantle to offer a beta path to get developers into Harmattan, and also offer a continuity path for those developers preferring to push their software based on GTK+ forward. It can be done. So... who submits the proposal for the BOF in the maemo Summit? -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developer device program
ext tz wrote: I've done the extras for Diablo but haven't for Fremantle since I really need some specific hardware features which aren't quite there in emulation (the underlying code will work anywhere, but the interesting problems will only show up on the target). I hope it isn't a paradox that I can only get the hardware by having apps, but can only really test the apps by having hardware. Just curious, what project(s) are you referring to? What are the showstoppers? Other developers (e.g. those using the accelerometers) have uploaded first versions to Fremantle extras-devel and they actually got the apps quite right after getting some feedback from people with a device. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developer device program
ext Adilson Oliveira wrote: Em 02-09-2009 17:42, Quim Gil escreveu: Hi, there is going to be an N900 device program and the terms will be announced soon. I will absolutely love when it happens but this time I may be not able to participate because the N900 seems to lack support for the 850Mhz 3G band that's essential for it to work in Brazil with some carriers. This is not a big problem if you are developing something amazing targeting thousands of potential users, as long as testing cellular connectivity is not a crucial use case. The device program has the objective of offering developers easier access to real devices in order to have their software ready for real users. Having such device for personal can be considered as a collateral effect. :) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How much are Nxxx open?
Hi, Finally, it may be nice if Nokia may donate some devices to FSO and OpenEmbedded core team, any interest/chance about that? We will start talking soon about the N900 device program. In the meantime, having members of these projects involved and with concrete ideas will help. Being active in the maemo.org Extras is one way but it might be difficult for such projects going beyond application development and actually needing some hardware to get things done with certain guarantees. An interesting approach would be to have members of these projects submitting proposals to the Maemo Summit. It's a way to have a name linked to a concrete purpose. Feel free forwarding your proposal (or remaking your own) to your preferred developers involved in these projects. Thanks! PS: about the topic of the thread, please bear with us while we are in this weeks of launch, final release and sales start. It will be much easier to analyze how open, relicensings, replacements etc once Maemo 5 and the N900 is shipped and the community has got the chance to see all the release code and how it works in a real device. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developer device program
ext Kaustubh Atrawalkar wrote: Just out of current ongoing topic being generic Question.. are there any developers devices going to be distributed just like N800 last time? - Hi, there is going to be an N900 device program and the terms will be announced soon. If you are a developer the best thing you can do is push your software through the maemo.org Extras process. If you are not a developer just keep whatever you were doing. :) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: WRT or W3C widgets
Hi, ext Delfim Machado wrote: Hi all, i've searched in the archives and found nothing about this, so here is my question. Since this is mobile computer/OS web 2.0, do you plan to support WRT/ W3C widgets? They are currently not supported but they will be coming at some point. Official announcements to come by http://wiki.maemo.org/Maemo_Summit_2009/Schedule#Friday.2C_October_9 latest. Maemo Summit 2009 Friday, October 9 17.00 - 17.25 Developing apps with Nokia Web Runtime Santtu Ahonen, Head of Developer Offering, Nokia -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: SMS and phone calls API of N900: will you give these to us?
Hi, ext Andrea Grandi wrote: Hi all, I think now it's the time to ask this. Since when I did read about N900 rumors about being a phone, I was wondering if we had been able to use the SMS and phone calls functionality from a simple API. fyi this question was raised last week at Telephony API? http://talk.maemo.org/showthread.php?t=31038 My answer, pasted here for convenience: There is no Telephony API as such and actually some of the use cases you are listing seem to belong to other components. I didn't have the time to ask today but Daniel/Soumya will look at this next week with the aim of adding some clarity in the Maemo 5 Developer Guide. So don't quote me on this but perhaps PulseAudio and Telepathy could be the places to search for APIs related to voice calls and SMS. And then there is DBus in the very middle of many other actions that you might be relating to Telephony. What I mean? I mean, for example, that if I wanna create my own application that send an SMS or read it when it arrives I can do it. It would be usefull, for a lot of applications cases, to be able to send an SMS without user interaction or being able to read and parse some magic string. Application case n°1: I'm in my office and I realize to have left my N900 at home. Oh sh**! The N900 is powered on but of course not connected to wifi and not connected to 3G network. So, how can I interact with it? That's simple. I send an sms to my phone with a particular magic string (it can be a simple password/keyword), a program in background on my N900 read it and it knows it have to connect to Internet (wifi or 3G, it doesn't matter). Once is connected to internet it can send its IP to me or simply updating it trough DynDNS service. At this point I'm able to SSH into it and open an x11vnc session too and do... everything :) Application case n°2: someone just stole my N900. Oh f***!!! I send an SMS to my phone in silent mode. I mean that the background application receive it first and doesn't notify the system sms service. At this point it tries to do everything: starting up GPS, trying to get the exact postion and sending me back, taking pictures from the front camera and sending me back ecc wouldn't be useful? Application case n°3: I want to record my calls (voip, normal calls, ecc...). How can I do it? For all these cases, I think we need access to SMS/telephony APIs. Will Nokia give us (developers) access to these API? -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo isn't on the netbook?
Hi, there are long threads about this topic at http://talk.maemo.org/showthread.php?t=30940 and in the maemo-users list. No need to open another thread here in maemo-developers. :) -- Quim Gil open source advocate Maemo Devices @ Nokia ext Paul Bloch wrote: Hi All, I know you don't hear from me often. I've dropped in and out for awhile now but thought I'd pop in and ask the community why Nokia isn't using Maemo for its netbook strategy. Especially when there is a struggling but growing App Store library built on the platform. Fremantle is meant to be much more graphically powerful and seemingly capable to offer a complete experience as hybrid desktop/mobile environment but isn't pushed to market as much as other mobile platforms. Android is already making its way to netbooks so obviously there must be some logic to Google's strategy. And Nokia is deciding to use windows. I can see the logic in being able to offer a complete operating system with the support that Microsoft has, but still. The same way of thinking could reason that Nokia should just use all microsoft software on all of its devices and can Maemo and their portfolio of mobile software...Maemo certainly isn't as polished of an experience as Windows but that's what hiring a large design studio to take care of is all about...I digress. Just some thoughts looking to hear other's opinions. - Paul ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Time to push Fremantle extras-testing?
Hi, if you are maintaing packages in Fremantle extras-devel or you have a generic interest in the Extras QA process, please have a look at http://talk.maemo.org/showthread.php?t=30541 and a say in that thread or here if you prefer. Thanks! -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Any plan for PyQt and Harmattan (official support)?
Hi, back from holidays. ext Andrea Grandi wrote: My question is: wil PyQt be officially supported by Nokia in Harmattan? Currently Python is not officially supported, although it has a good unofficial support - and sometimes we help on that. This is more or less how we expect it to work in Harmattan as well. Python developers willing to base their work on Qt have a way to do it already in Diablo, and hopefully the support level will be kept and improved in Fremantle already. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Share your Fremantle screenshots
I'm working on the keynote presentation we will have at http://www.grancanariadesktopsummit.org/ on Saturday July 4. The presentation is about Harmattan, and I'm thinking of having a collage of Fremantle screenshots in one of the slides. As a way to illustrate that from a platform development point of view, Fremantle is mostly delivered. If your application is looking good in the Maemo 5 SDK please take a screenshot, upload it somewhere and share the URL here or at http://talk.maemo.org/showthread.php?t=29836 . I can't guarantee all of them will be picked but I will do my best. Please make the selection hard. :) -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Publishing developer documentation (was Re: The role of the docmaster)
I have been silent on this thread about the role of the docmaster (even if I started it). Couldn't find the words for my thoughts. It is clear that we have structural problems to handle developer documentation: its production, update, contribution, publishing methods, quality... First of all, let's remember the defined goals: http://wiki.maemo.org/Objective:Co-production_of_official_%26_community_documentation Some progress has been done patching the current processes, but for further progress some deeper changes are needed. First of all, we need to look at 3 very different types of developer documentation: - API references. Generated from source code. Their publishing and contribution processes are as open and collaborative as their related source code. No less, no more. Always on-line on HTML pages updated directly from the code. The tools are specific, bug reports and code repositories to commit contributions. Owned by Maemo Devices and published in maemo.org. We have already contacted Fred Peters, creator of http://library.gnome.org/ , to have a good solution in place by the Maemo 5 final release. The quality is defined by valid references (mapped to current code) and working code. The descriptions of the APIs need to be clear and undestandable by developers. - Technical documentation. The Maemo Reference Guide, derived directly from the API references: what Maemo allows application and also platform developers to do. Human readable but without much flourishing. Always on-line with only a marginal case for printed versions. Wiki is an ideal support for fast an easy contributions. Everybody can add feedback in the Talk pages an contributors with special permissions can edit the main content. Then something like http://www.mediawiki.org/wiki/Extension:Pdf_Book could be used to allow Nokia and whoever else to create PDF files directly out of the wiki content, that would be the one and only source. This needs more discussion and an agreement on how to proceed. Target: Harmattan since we have a process in place already for Fremantle. Owned by Maemo Devices. The quality criteria are the same as in API references + even more accuracy in language and good provision of examples in the form of graphics, code snippets and demo apps. - Generic developer documentation. Tutorials, training materials and other educational/introductory/marketing documentation. Derived mainly from the technical documentation and ready to be published in many formats, including videos, books, PDFs... Online editable formats e.g. wiki pages can be possible too, but the default scenario are stable and consolidated documents published once and updated only when really needed. Improvements to be proposed via bug reports unless the specific document has a more direct way to apply changes. The quality criteria are the same as in the technical documentation with a special emphasis in the language, the structure of the content, the visual appearance and the cleverness of the content and the examples provided. Forum Nokia is responsible of this kind of documentation, and they are getting ready for this in Fremantle and even more in Harmattan onwards. I'm confident that we are doing the right steps in the API and generic documentation. But more thought and perhaps a change of direction is needed in the very important layer of technical documentation. If this one doesn't work flawlessly inside Maemo Devices and in maemo.org then Forum Nokia and the avantgarde of Maemo developers will have a much harder time producing the generic documentation that most developers (and specially newcomers, visitors, tech media etc) will look at. As I see it, it's basic to have that technical documentation in a wiki or a similar system easy to contribute and moderate. Now the axis is an infrastructure ready for publishing PDFs and printed documents, but this is imo a secondary use case compared to having the documentation online with a process allowing fast and easy improvements. The Maemo developer platform team and the Nokia internal developers would start creating such technical documentation in an internal wiki when needed (for instance now for the new components in Harmattan), and as soon as those components would be published in unstable releases, those wiki pages would be copied/moved to the public wiki, being used and improved there by the same Nokia teams but also by the community developers. Then frozen versions on PDF could be created with the right wiki tool when needed e.g. beta and final releases. This looks much easier and efficient than trying to combine a Latex master maintained by Maemo onyl with a wiki copy where contributions would be made. And the result would be the same, or better: living docs in wiki pages useful for Nokia and community developers + static exports of those docs frozen for specific releases. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers
Status of Fremantle stars and other interesting projects
There are many people at Nokia and in the community interested in the status of cool projects aiming to be ready for prime time the day Maemo 5 goes to the hands of real users. These cool projects include the Fremantle Stars but also any other open source project with committed developers behind. Please have a look at http://wiki.maemo.org/Fremantle_Stars#Status_of_Fremantle_Stars_and_other_great_apps and fill the information relevant to your project. Suggest or just apply any improvements in that table in order to help everybody know how are you going and what do you need. If you play this little game you might get more contributors willing to help in the success of you project, including Nokia and its marketing arm. More information and questions from other developers can be found at http://talk.maemo.org/showthread.php?t=29469 -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Unsatisfied with bugs.maemo.org
Hi, ext Till Harbaum / Lists wrote: Hi, i am really unsatisfied with bugs.maemo.org. The reason is simple: Just too many bugs are just closed with WONTFIX which basically means: We understand and acknowledge the problem, but we won't spend any time on it. bugs.maemo.org is only the messenger... This would be acceptible if maemo would be a really open plattform and anybody could just fix things. But that's not how maemo works and there's such a huge number of bugs that never get fixed and the same issues appear ever now and then again. I e.g. just filed bug 4630 and should have noticed myself that 1504 was the same one filed june 2007. It was never fixed but was just WONFIX'd. And we are not just talking about some weird feature. We are actually talking about something being documented in the maemo api docs. I think Andre and you can still try with bug 4630 if it relates to the Maemo 5 API. Why is there a bug reporting system if so many bugs end up with WONTFIX? This doesn't make much sense to me. Again, don't kill the messenger. Maemo 5 bug handling has been already a lot more efficient than in previous versions, thanks to people reproducing old bugs in the Fremantle pre-releases. We expect the good responsiveness to be kept once Maemo 5 is launched and we get new bugs from Maemo 5 users, getting the fixes out in new updates. What we have is a bag of bugs still open affecting mostly Diablo. Because of many reasons those bugs were not handled in time or there were no resources to fix them at the time. Now we are cleaning those bugs week after week and yes, this brings lots of WONTFIX among those that are not an issue anymore in Fremantle. It's more a consequence of a past problem than a reflection of a current problem, though. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Continued problems with python dependencies
ext Anderson Lizardo wrote: * python-support =0.90.0 : it is already there since the PyMaemo beta release (version 1.0.2maemo1). I think the person who reported this did not have the extras-devel repository added to his/her target sources.list. Can you confirm that you have extras-devel enabled Quim? Since I can see that python-support_1.0.2 is in fremantle extras-devel. I don't think Quim himself had the problems, but possibly he aggregated the issues from other sources. Quim: is that the case? I'm testing with fremantle extras-devel repo installed in one of those developer units, not on SDK. GPodder can't be installed today: Application packages missing: python-support ( 0.90.0) Same for MyTube and mediabox among others. python (= 2.5.2-3maemo2) and python2.5 (= 2.5.2-15maemo3) are missing dependencies for maemo-python-env, in addition to python-support ( 0.90.0) In practice, no Python app works from the many uploaded to extras-devel. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Qole, see what you are doin'. :) ext Qole wrote: Kimmo and Quim: First of all: I did not start this thread as an attack on the Maemo team, nor was my comment, that's disappointing, meant as an attack. It is a simple statement of fact; it is disappointing to me that Maemo 5 does not yet have the infrastructure in place to be able to run hardware-accelerated 3D graphics in OpenGL ES applications. To me, this is a very important feature for any future device, and I was disappointed that this is not apparently a high priority within Maemo. This is a developers list and you were disappointed by the answer of a developer telling you that the technologies involved are all open source so anybody can contribute to the solution. Kimmo and Kate are giving technical details telling that the enablers are in place and they need fine tuning. They also tell you that such wrapper can be developed by anybody (with the knowledge and the time, sure). No matter how high the priority of your request would be, having the official release and developer offering tops (logically) the priority. Besides, based on this thread you are making your own conclusions in talk.maemo.org about the status of the release etc. I really want the next Maemo device to succeed, and one of the first things the gadget blogs and technophiles will want to see is the games. This means making Maemo 5 games friendly, and to me that means making it easy to port existing OpenGL games to Maemo 5. We also want the next Maemo device to succeed and we have a list of priorities to make this happen. Any input is welcome and your point is taken. Now, please let's move on. Qole, basically you came to a developers list with a user request (OpenGL based games are important and Maemo 5 should be ready for them), you got valuable feedback from Nokia developers but you are still pushing your agenda without getting in development/technical details and you are extending your disappointment here to threads of (mainly user) speculation in tmo. My recommendation is to follow this discussion in talk.maemo.org or maemo-users if you prefer. I don't know the internal workings of Maemo, and perhaps you have a good strategy in place for games; I was thinking purely of porting existing Linux games that were written for OpenGL. So I began thinking of what needed to be in place for this porting to be done. Developers can do this. I also admit I might have been influenced by the video of Quake3 on the Pandora. :-) Pandora is a gaming device, so they better have the gaming enablers in place. I also don't expect Maemo to port the games, I'm just concerned that the path will be too thorny to encourage others to do it. Right. Why don't you ask this in the OpenGL community? It's not Maemo who defines the gaps and incompatibilities between OpenGL flavors and versions. THAT would definitely help the success of the next Maemo device much more than putting more pressure in our developers. -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fremantle OpenGL wrapper?
Hi Qole, Hamalainen Kimmo (Nokia-D/Helsinki) wrote: On Wed, 2009-06-03 at 09:17 +0200, ext Qole wrote: That's quite disappointing. Well, more disappointing would be a hildon-desktop inconsistent, sluggish, buggy and with weird wrong interactions between GTK+, Hildon, Clutter, OpenGL ES, Xorg, OMAP3 kernel... and more brave technologies Kimmo and others are dealing with, putting them for the first time in a commercial product. What Kimmo is saying quite frankly (as he is a pure developer as opposed to people like me, more into words) is First Things First. He is also saying that there is plenty of work only the people in the Fremantle project can do, while there are many other things others can do thanks to all these technologies being open source. It makes sense that Nokia engineers like Kimmo concentrate first on the things that need to be in place in order to release a successful product with Maemo 5 inside. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Problems with Python dependencies
Hi, this weekend I took a chance to try several apps available in extras-devel. That included some SDL games that just showed how slow I'm getting, but that's not the point of this email. :) There were plenty of packages unable to install due to missing dependencies: all of them Python based. I sent emails to the maintainers (it would be better to file bugs in bugs.maemo.org, maybe we can add a 'misc' component for these, so at elast we could mail the maintainers with a link to bugzilla instead of a purely private message?). The answers from the maintainers were similar: - They didn't know about these missing dependencies as the packages work on their local systems (where I guess such dependencies are satisfied). - They didn't know the auto-builder would let a package go through to extras-devel wit dependencies missing. - Some didn't know where the python-support (= 0.90.0) dependency actually came from. - Plus other questions about Python bindings that, as the user I am, I have no clue about. Again, filing bugs makes easier to help them since all the discussion is public and others can jump in and help. Or in this thread here. Or... fwiw the dependencies missing included osso-gnomevfs-extra, python2.5-hildondesktop, python-mokoui python-support =0.90.0. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python packaging (Was: Re: debmaster priorities [YOUR INPUT HERE])
ext Jeremiah Foster wrote: On May 15, 2009, at 21:09, Thomas Waelti wrote: Did anybody ever stumble over my two wiki articles about this issue? ;-) Nope. But thank you very much for posting here, this is really good stuff. They are written from a no-real-clue-but-finally-got-it-working perspective, which might shed a light on the problems these amateur developers (such as myself) face on the platform. http://wiki.maemo.org/Py2deb (accessed 3000 times?) http://wiki.maemo.org/PyPackager (accessed 4000 times?) Perhaps they could also serve as the foundation for an advanced article or get linked in the next blog that Jeremiah writes. I think it will be an excellent subject to include in the next blog post. Sure, but please make sure all this good advice in blog posts ends up in well organized and visible wiki pages, and even in the official documentation: http://maemo.org/maemo_release_documentation/maemo4.1.x/node14.html http://maemo.org/development/training/maemo_application_development_content/plain_html/node9/ http://maemo.org/development/sdks/maemo_5_beta_docs/ (not yet there) -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debmaster priorities [YOUR INPUT HERE]
ext Jeremiah Foster wrote: Yes. I will try to create an additional channel in addition to the others with the goal of trying to be more available. Being available is the main task of the debmaster, I think. Everything else comes from the problems this availability brings: - If you spend a lot of time answering basic questions about X, Y, Z it means that X, Y, Z needs to be better documented. - If you spend a lot of time dealing with problems related with missing dependencies and conflicting packages it means that work is needed there making easier to bring/port dependencies and preventing conflicts. - If you spend a lot of time with packages that violate the Maemo policy there is probably some work to do around that. etc I'm not saying that all the work should be ad-hoc and see what the day brings, but the day to day should define the planning agenda. About the current sprint, let's not touch it (it's good to keep the deal signed among the sprint participants in the monthly meeting) but please consider all this in the next sprint plan. -- Quim Gil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
debmaster priorities
Hi, I think we could have a better prioritization of the tasks of the debmaster, if not for this sprint at least for the next(s). http://wiki.maemo.org/Maemo.org_Sprints/May_09 says Run a test build of all Diablo Extras packages on Fremantle . Could. The fact that developers are porting packages themselves somewhat obviates the need to me to do a lot of this. ... wouldn't this be the other way around? Developers have to port themselves because there is no automatic build trying to push as much packages as possible from Diablo? Reducing number of external repositories - contact outstanding owners appears as should, which looks more like a Could compared to the other task. Same for http://wiki.maemo.org/ITP - appears as Should, but it could probably wait a month or two (first we have packages, then we have the tool to search them) ;) Anyway, I think what developers need right now is direct support for their packaging. The idea of hiring a debmaster came with the will to save time and hassle to developers. For that high level tasks are needed, but the primary work should be to offer direct support, and getting your Diablo dependencies working already in Fremantle looks like a very good and immediate help. Or at least this is my humble opinion. :) -- Quim Gil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
Hi! ext Graham Cobb wrote: On Monday 11 May 2009 17:58:46 Quim Gil wrote: Also, what if this is a brand new application (e.g. liqbase, last year) -- how does the developer recruit beta testers? It's extras-testing who needs to recrit betatesters, not a specific app. Imagine 200 people getting their 'betatesters driving license' and going to a page where they see the status of apps tested, how many votes, how many days, what needs special attention... Now I am very confused. Your view of extras-testing is very different from mine. Graham, I actually believe we are talking about the same thing, only assuming different contexts. :) I think we are agreed that extras-testing is going to be a place to put apps that the developers think are of beta quality and are trying to go down the path to release in extras. I also thought that a lot of people (including probably most of those who actually contribute to maemo-users or ITT) would choose to have extras-testing permanently enabled on their tablet and would tend to update new software from it frequently (both things that are dangerous to do with extras-devel today). Yes, this looks like a good half description of maemo-testing. However, I did not think that the bulk of the people using extras-testing would actively think of themselves as beta testers, would apply for a betatesters driving license or would even rate applications. I would hope that a proportion of them would be willing to log a bug report if they found a problem but would be surprised if it was more than 10%. Yes, and no. Indeed, I also think that only around 10% will be active testers, or even less. Since we are looking at around 20 OK, thinking of 200 (or even 1000) users of extras-testing sounds like a reasonable approach. But this is where the Crash Reporter (helps (thanks Eero for the correction on the name). This is how this crash reporter works: - 1 click install. - You don't need to do anything with it if everything is fine. - You simply don't see it if everything is fine. - You forget about it if everything is fine. but If something goes wrong and there is a crash somewhere in the system, the Reporter pops up a window notifying the crash, offering a window for comments What were you doing? and an option to Send the report. Nothing else. Then the report goes to a server with the information that could trace (Eero can extend on details here). So plain users have a means to report crashes without caring about the details, only pressing Send. And maemo.org has a means to detect what is crashing in peoples' devices, what is occasional and rare and what is frequent just this week. Asking users of extras-testing to install this simple app sounds like a fair dair probably to 40%-60% of them, and perhaps more plain users are willing to do it just to help and be-part-of. Then talk.maemo.org can also work as proxy. If there is one noticeable problem is very likely that you will have a thread there that after some posts will figure out what is perhaps going on. I assumed that the N weeks and M testers requirement would really be in N weeks, M people downloaded it and no one reported any serious problems. If we are expecting an actual report on it, or any active testing (trying out menu options, etc.), then even for popular apps I don't see M being larger than about 3! When I release a Beta version of GPE and announce it on ITT, asking for people to reply to let me know they have downloaded it and tried it, I get about 3-5 responses. I know others have also downloaded it because I sometimes get later replies asking questions, reporting problems, etc. I have to assume that even more people downloaded it and haven't had a problem. You are talking about the past (which is good since this is the real experience nobody can contest) and I'm talking about the future, where I firmly believe we will have more Maemo users than we have ever seen (which is a logical thing to say for a marketing dude at Nokia). ;) Now you can evaluate past and present and bet for the details of then implementation. As said, we trust you. Installing a new app and giving it a try of 10 minute and then rating if there were showstoppers or not is not a big-big deal. If Nokia or the Maemo community can come up with a way to recruit/incentivise people to do that then I am very supportive. It would be great! But I have not heard any ideas on how to do that. I don't think 200 people will do that without some serious incentive. We'll see. The open source community has several models of high involvement of users. Also initiatives like Nokia Pilots - http://www.nokia.com/A41082081 - show that you can get a lot of user involvement if the process is simple and the outcome is clear. Inviting top reporters to the Maemo Summit? Be a great tester of Fremantle and be the first to have Harmattan unstable in your hands? You excel testing with your device
Re: QA from extras-devel to extras-testing
ext gary liquid wrote: automated unit testing will not find all bugs or problems in perfectly packages software. manual human testing will not find all bugs or problems in perfectly packaged software. a combination of both involving common sense and prior history should minimize the risk of problems though. ... and this is exactly what I proposed! 1. Developer pushes packages from extras-devel to extras testing. 2. Automated testing does the checks. 2a. If the test fails, the packages don't get to extras-testing. 2b. If the test is successful, the packages go to extras testing. 3. In extras-testing the betatesters put the software into stress, equipped with Nitro (crash reporter installed in their devices) plus whatever tools they can use voluntarily. 3a. If they find severe bugs the packages go back to extras devel. 3b. If nobody finds a showstopper the app goes to extras after N weeks and N votes. I see the point of asking for qualified humans giving the green light as something more trustworthy than community testers rating. The problem I see is that these people are usually busy and being the filter can put a lot of stress in them (holidays, exams, problems at home... and a dozen of developers waiting for you to press a green button). This is why this option is preferable. Skilled humans can still test whatever comes and raise the blocker bugs, before or after the final release. In fact, what we probably should and will do is test more those apps that are most downloaded, for a simple logical reason: they are more used. Also, more automated testing and torture could be put on the most downloaded apps. But doing intensive and reliable testing on every package uploaded is not scalable, probably not even when automated since there are all kinds of apps, languages, dependencies... If a major bug could make it inside a final release of an app downloaded 50 times and the chance for the bug to explode is 1/1000... tough luck. It happens all the time. 2 weeks in the pipeline in exchange of free true testing and the trust of Nokia for potential promotion and collaboration sounds like a good deal to me. Testing the latest software 2 weeks before any regular use even sees the releases sounds also like fan and a good deal for the betatesters. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
Hi, ext Graham Cobb wrote: Not sure about the requirement to have Nitro installed. In particular, what happens to the (potentially large number) of people using maemo-testing who do not have Nitro installed? What happens if none of the people who want to beta test this package have Nitro installed. I don't know why on earth would someone refuse to install Nitro (silent, convenient, informative) when is actively joining a testing program to assess the quality of the software that is trying out. In any case, using extras-testing and not using Nitro is not the big deal. The big deal would be if people would actively rate Yes, this app is OK without having a crash reporter installed. If you mean that 20 people well organized can push a buggy package of extras bypassing Nitro... well, that would be true if they are the only 20 testing it. If a 21st tries and makes Nitro detect crashes, with one reporter you have enough to start suspecting of a package. Also, what if this is a brand new application (e.g. liqbase, last year) -- how does the developer recruit beta testers? It's extras-testing who needs to recrit betatesters, not a specific app. Imagine 200 people getting their 'betatesters driving license' and going to a page where they see the status of apps tested, how many votes, how many days, what needs special attention... Installing a new app and giving it a try of 10 minute and then rating if there were showstoppers or not is not a big-big deal. What if this is a commercial company who has created an app and wants it available as soon as possible? maemo.org doesn't need to bother about commercial companies with special needs. Forum Nokia does that. 3a. If they find severe bugs the packages go back to extras devel. This at the judgement of the developer, presumably (one man's severe may be different from another's). Downgrading packages in repositories does not work well so this would have to be a rare occurence. Let me bring again the Requirements for extras (humans are needed to test) - Don't crash or freeze systems. - Don't drain batteries. - Are feature complete: everything inside works. - Have been tested by someone trusted before. Crash and freezes are easy to detect. Nitro helps reporting them automatically with traces to a server. About draining batteries we hope to have a tool easy to use for betatesters. Everything inside works is also relatively objective: you go through the menu options and you check that there is nothing obvious. Normal and minor bugs are ok, happen to everybody. The latter is achieved by the requirement of 20 approvers. Also, let's say that downgrading from testing to extras is less severe than downgrading from extras to testing. I agree that stronger reasons need to be provided for that. 3b. If nobody finds a showstopper the app goes to extras after N weeks and N votes. Certainly not if the developer has not requested it. Good point. The option by default might be Not releasable, and this would stop a package even with 500 favorable ranks. This might be useful to organize releases, and no just find out that your app made it to extras with big success (or awful feedback) precisely when you were 3 weeks on holidays. Then for small releases developers in a hurry might decide to select Releasable when they push the app to extras-testing, and forget about it (unless it comes back). I don't see the humans as more trustworthy, just more flexible. Maemo is a small community, with a very small number of packages compared with (say) Debian. And as a mobile device oriented distribution we need to be encouraging developers to make availabe neat applications, of good quality, as quickly as possible. And I don't see a fixed rule as being the best way to achieve that. I would rather that any one of a team of (say) Jeremiah, Jaffa, Qole and a few others reviewed a submission request form allowing the developer to explain what testing has happened, by whom, over what period of time and then made the upgrade if they are convinced. The N weeks, M testers would be the standard guideline but the reviewer can change the criteria if they feel it is appropriate to the circumstances. At this point I can only say: you know better than me. I have just tried to propose in broad terms a community process that both developers, community and Nokia could agree upon. You have our total trust defining all the details you think are better to pursue the main goal. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Identifying free/non-free apps (was Re: ... and QA of closed source applications?)
ext Jeremiah Foster wrote: On May 6, 2009, at 17:47, Quim Gil wrote: Hi, ext Attila Csipa wrote: To make things worse, the application manager does not display the repository, much less the component an application belongs to. Indeed, more information could be probably put in the Application details -- Summary e.g. the repository branch and there you could see whether it's free or non-free. Do you mind filing an enhancement request? I am happy to do this if you don't want to Attila. Fine, but I please set your work priorities right. Only in the April sprint you have 8 committed tasks, and the QA process (open closed) is still more relevant that being totally clear with end users about the license of the software they install. Then we really ought to specify two domains, Nokia and Community. Done? Inside the Community domain we can specify whether an app is closed or open source. This way there is no misunderstanding, everything in the repos is free as in beer just some things are open source and some things are not. Maemo is doing this already through the Debian traditional way of defining free/non-free, or am I missing something? However we want to implement that is fine, but I think the free / non-free distinction and its clumping together in the AM has to change, its just too confusing. Fine, but one thing are repository structures used by developers and tools, and another thing are localization strings for end users. Let's not mix them, please. May I submit for your critique: /repository.maemo.org/extras/name/open/ /repository.maemo.org/extras/name/open/testing/ /repository.maemo.org/extras/name/open/new/ /repository.maemo.org/extras/name/closed/ /repository.maemo.org/extras/name/closed/testing /repository.maemo.org/extras/name/closed/new/ open? free is the standard and what is currently used. Why change. closed? non-free is the standard and what is currently used. Why change. new? This actually sounds fresh and appealing to end users. devel is what is currently used and defines the target and quality quite well. Why change. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ... and QA of closed source applications?
Hi, ext Jeremiah Foster wrote: the reality is that there are even more opportunities to get very good software for the devices if we allow also non-free software to be a part of our community supported extras repository. Do you have some examples? I am sure you are right, I just would like to know which apps. I don't think maemo.org should block or even judge developers willing to distribute their closed software free of charge.If it does, then they will find another way and if the apps are good users will be on their side, asking what is our problem. Besides, maemo.org extras has got (always?) a non-free branch. So what would be the reason to change now. - Don't bring conflicts in dependencies. How do we know they are not violating the GPL if they rely on GPL'd libraries but don't ship their source? Those 'dependencies' may require them to ship the source, that is a major conflict. The fact is, we don't know. But it's fair to apply the concept of habeas corpus and presume that people is innocent by default. We can make the developer tick a box saying that it is their responsibility to respect the licenses of the software used. If someone finds a way to demonstrate that then files a major bug and we demote the app. See http://maemo.org/legal/terms_of_use/ for a complex hint on that. There are some problems still. For example, will Nokia face a patent lawsuit if it ships software which violates patents? How do you know the software does not violate patents if you do not have the source? Quim, could you explain Nokia's position on patented software in closed applications available for Maemo? Are they cognizant that even with a disclaimer they may be subject to a patent lawsuit like the recent TomTom case? In most cases patents only bring uncertainty and risk, this is why having the source code matters. I don't think open or closed source brings any difference when it comes to infringe patents. Nokia is 100% liable of whatever is pre-installed in the devices sold. But Nokia is most probably 0% liable in software from third parties installed by users at their own will and risk, as explained in the disclaimer users get when installing that software. http://maemo.org/legal/terms_of_use/ talks about IPR, copyrights and trademark violations as well. In practice the same legal checkbox for the license check could cover the disclaimer for all these kinds of legal issues. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: ... and QA of closed source applications?
ext Attila Csipa wrote: I think one of the key issues is not if it is possible to install non-free software, but rather to be in the clear that people *know* which software is, and which isn't free and then decide for themselves if they want it or not. In the spirit of recalling the history of the wheel, I'll mention the Debian and Ubuntu families solve this by putting them in a separate repository (just as available as the free ones). Since we already have a nokia/extras split, this could be just as extension to that. Done since years ago. http://repository.maemo.org/extras-devel/pool/fremantle/free/ http://repository.maemo.org/extras-devel/pool/fremantle/non-free/ http://repository.maemo.org/extras-devel/pool/diablo/free/ http://repository.maemo.org/extras-devel/pool/diablo/non-free/ etc. In the same vein, Ubuntu solves the question of 'I just ported but I have no clue how it works' with the main/universe/multiverse repo split, so you know which package is really cared for and when are you treading more dangerous waters with regard to support (this also defines where the bugreports go - for a universe package most of the stuff will go upstream - unlike packages in main which have maintainers/packagers who actually have the knowledge to check/fix bugs and decide if a bug is worth sending upstream or not. Applied to Diablo, the Ubuntu/Canonical repo structure can be more or less mapped, in different terms Main http://repository.maemo.org/pool/maemo4.1/free/ Restricted http://repository.maemo.org/pool/maemo4.1/non-free/ plus binary-only packages from catalogue.tableteer.nokia.com Universe http://repository.maemo.org/extras/pool/diablo/free/ Multiverse http://repository.maemo.org/extras/pool/diablo/non-free/ Canonical's Partner catalogue.tableteer.nokia.com - certified There is a downside, of course - dependencies get more tricky with multiple repositories, but with a clearly defined procedure and repository purpose that can be remedied in most cases. The alternative, shoveling everything into a single giant melting pot repo (regardless of license, level of support or origin) did not work for Debian or Ubuntu, so I'm a bit skeptical if it's the right way to go in Maemo, either. As you see we never have gone that way. Actually Nokia is the least interested mixing open and closed licenses, supported and unsupported software. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Identifying free/non-free apps (was Re: ... and QA of closed source applications?)
Hi, ext Attila Csipa wrote: Just arrived... out of order mail is so much fun :) On Wednesday 06 May 2009 14:37:18 you wrote: non-free software, but rather to be in the clear that people *know* which software is, and which isn't free and then decide for themselves if they want it or not. In the spirit of recalling the history of the wheel, I'll Done since years ago. http://repository.maemo.org/extras-devel/pool/fremantle/free/ http://repository.maemo.org/extras-devel/pool/fremantle/non-free/ As Jeremiah pointed out, it's more of a clarity thing. As it is now, it's fairly difficult for users to see/make that choice. I see. Users can get their software from maemo.org Downloads and there the applications do tell whether they are open or not. See for instance http://maemo.org/downloads/product/OS2008/personal-menu/ http://maemo.org/downloads/product/OS2008/canola2/ To make things worse, the application manager does not display the repository, much less the component an application belongs to. Indeed, more information could be probably put in the Application details -- Summary e.g. the repository branch and there you could see whether it's free or non-free. Do you mind filing an enhancement request? I don't see too much the point of saying anything in the main list of applications. Most users don't care and are not even aware of the free vs gratis question. Listing free and non-free would make most users think non-free = paid. Even if it would, if you install an application directly from maemo.org, you will likely get a [extras] name = maemo Extras uri = http://repository.maemo.org/extras/ components = free non-free stanza automatically from .install. Now, provided you even know about free/non-free components, you would have to go to the application manager - tools - catalogues - pick extras - edit and then know what free and non-free actually means in that context and how to edit them. I don't think it's trivial for newbies at all. Making this a higher (repository level) choice IMHO makes it a lot clearer. I agree this is not trivial to newbies. However, I wonder how many Maemo newbies are concerned by this. If you are concerned, you are probably not a newbie. And even if you are concerned, I wonder what would be the % of Maemo users that actually would not give a try to an interesting gratis application because of the license. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
Hi, Let me start again because I don't think this downstream-upstream relationship is relevant to define hhis extras QA process. Proof: if an application in extras has been demoted because of a severe bug in a library it's the maintainer of that app the main responsible of finding a solution. Going upstream might be the safest bet but probably not the fastest. He will decide in any case. If a package is used by many apps then the problem is common to many maintainers and, again, they will decide whether to fix the bug themselves and file the fix upstream or report upstream and fix the problem altogether. In any case it is not the business of the maemo.org extras QA process to deal with the bugfix itself. This process should make sure the quality of the apps offered to end users is good, promoting what is good and demoting what is bad. Goals - We need to know when an application in extras-devel is ready to be tested by power users (betatesters). - We need to know when an application in extras-testing is ready for end users. - We need to have a community process to report severe bugs and demote an application if a confirmed severe bug is not being addressed. Assumptions: - We have extras-devel, extras-testing and extras. - The jump from extras-devel to extras-testing is initiated manually by the maintainer of an application once he thinks it's free of major issues and would be stopped by some kind of objective criteria applied to automated testing with no human testing: installs/de-installs, package info complete... - The jump from extras-testing to extras is made automatically after n days when human-based criteria are met: no crashes or severe bugs detected, n votes for promotion. Betatesters have specific tools installed in their devices helping them to detect and report crashes and power management issues. - Betatesters can also flag an application that is buggy enough to be demoted. Only the relevant packages should be demoted, as one library might be shared by many apps. They would be all demoted if the library is demoted so we want to do this only when it is proven that the severe bug is in the library. This means that the demotion needs to be done manually by people really knowing what they are doing. - We are looking for end user perceived quality and therefore we need to handle end user bug reports. We can't expect a user to know what exact package or library is causing the problem, the bugs will be filed against applications found buggy. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
ext Murray Cumming wrote: On Mon, 2009-05-04 at 12:06 +0200, Jeremiah Foster wrote: [snip] And if someone does not want to create a bug tracker, for whatever reason, how can we convince them not to open their own repo if Maemo rejects their package? maemo.org extras would reject their package, but perhaps not extras-testing and definitely not extras-devel (unless there is some kind of criminal intend or something). We can't. But then it probably won't be as easy for people to install that application. At the least, it will be much less visible on the device and on maemo.org. ditto -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
ext Jeremiah Foster wrote: On May 5, 2009, at 15:41, Quim Gil wrote: The problem is that many package maintainers don't know the programming language of the software they are packaging. If you are packaging something written in erlang you will not be able to quickly fix bugs in that package if you don't know erlang. This problem is a big one in debian, which is why they pass bugs upstream. How many package maintainers know the code of the package they maintain in maemo? No idea and actually not the business of the QA community process. If an application is causing real pain to users *now* it needs to be demoted asap and be promoted again only when the pain is fixed. The fact that a severe bug can't be fixed because there is only one maintainer interested in it not knowing much about the code and lazy about reporting upstream... would tell a bit about the quality of that piece of software, by the way. In any case it is not the business of the maemo.org extras QA process to deal with the bugfix itself. This process should make sure the quality of the apps offered to end users is good, promoting what is good and demoting what is bad. Fair enough, but quality needs to be specifically defined. I.e. installs, de-installs, has a source tarball, description, etc. Looking at the list proposed in the first email of this thread, this could be: Requirements for extras-testing (should be testable automatically) - Install and deinstall flawlessly. - Don't bring conflicts in dependencies. - Their info in the app manager is complete (icon, summary, URL to project, updates info). - Have decent page in maemo.org/downloads. - Have a place to report issues to the developers. Requirements for extras (humans are needed to test) - Don't crash or freeze systems. - Don't drain batteries. - Are feature complete: everything inside works. - Have been tested by someone trusted before. Goals - We need to know when an application in extras-devel is ready to be tested by power users (betatesters). As soon as it is uploaded? Developers upload to extras-devel, betatesters watch extras-testing. A betatester could be a regular users willing to invest time going trough fresh stuff and reporting about the findings. If we can save them the major bugs automated testing can find, all the better. - We need to know when an application in extras-testing is ready for end users. After going through a policy check and two weeks of power users' tests? 2 weeks minimum and 10 testers OK with no blockers? We can fine tune how many days and how many testers are required. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
... and QA of closed source applications?
This deserves a separate thread. In the QA from extras-devel to extras-testing thread we are discussing a community quality process that relies heavily on the fact that the source code of an application and its dependencies is available. But happens with the closed source applications? The commercial developers signing contracts with Nokia go to a blessed nokia.com repository, but what about all the rest? There have been very popular and even community friendly apps that were not open source, like Mauku or Canola. We can expect more in the future: free as in beer but not as in freedom. Currently the situation explained at http://wiki.maemo.org/Extras#About_Extras is non-free applications are usually closed, binary only and their quality and security must be taken on trust It's not good to have a free extras repo with good QA next to a non-free extras repo equally offered to end users with no QA control. But what to do? Some options come to mind. - Don't distribute closed source, binary-only packages through maemo.org. This will only help the proliferation of repos again, though. - Keep the same QA process where availability of source code is not determinant, - Same as above but making the extras-testing hurdle higher to be more on the safe side. For instance requiring more OK testers and/or a dedicated OK from someone qualified e.g. the debmaster + bugmaster. - ... -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA from extras-devel to extras-testing
ext Murray Cumming wrote: On Sun, 2009-05-03 at 20:15 +0200, Jeremiah Foster wrote: Who is going to build all of this infrastructure? For the voting stuff, I have no idea. Maemo/Nokia wants it so I guess they will make it happen. Hopefully the maemo.org team and the community council also wants it, so they will make it happen. :) Won't this type of requirement help create separate private repos? You mean the possible bug-tracker requirement? I hope maemo.org still eventually aims to provide real bug tracking (bugzilla) to any package in extras. So a package can just use that if it doesn't have something already. Agreed. I'm missing this already now, trying to install and playing with applications available in Fremantle extras-devel. But when a package doesn't install or has a serious problem and then I need to figure out where to report... If I feel lazy imagine the average betatester or end user. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
QA from extras-devel to extras-testing
Hi, The Fremantle beta SDK is out and now the real time starts for application developers targeting Maemo 5. The plan is to have the maemo.org extras repository active by default in the Application Manager. This means that Maemo 5 users opening the AM for the first time will see already the apps available there. In order to do that we need to have a QA process in place, though. The goal is basically to have only the applications there that: - Install and deinstall flawlessly. - Don't bring conflicts in dependencies. - Don't drain batteries. - Don't crash or freeze systems. - Are feature complete: everything inside works. - Have been tested by someone trusted before. - Their info in the app manager is complete (icon, summary, URL to project, updates info). - Have decent page in maemo.org/downloads. - Have a place to report issues to the developers. These are many items but kind of makes sense to have them, isn't it. The question is how to check and enforce them. What can be automated and what can be evaluated via testers feedback. The first question is how to jump from devel to testing, which ones of the items above (and others missing, if any) should be applied already there. And put it in practice now in Fremantle. What we shouldn't do is to create extras-testing or extras and let packages jump in without the QA process in place. Taking a buggy package out because of a new policy is going to be much more complicated. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [GSOC-09]-Semantic-Based Context-aware Personalized News reader System for Maemo
Hi, welcome! I think the GSOC discussions should be better placed in the maemo-developers list. These developers have developer plans and will have developer questions, and the best audience for that is in the maemo-developers list. Sorry for the crossposting and please remove the right list once we have decided where to have the GSOC project discussions. ext FENG GAO wrote: Hi, all: I'm Feng Gao, an undergraduate student in Beijing, China. This fall, I will go to UK to continue my study in univ. of Southampton as a phd candidate. The project I proposed for GSOC is Semantic-Based Context-aware Personalized News reader System for Maemo. The main goal of this project is to add some intelligent features into the reader system then it can recommend or filter news information according to user's interest which is represented as keywords (or named tags) and user’s environment which depicts physical condition and abstract condition about user, and can be used to answer questions like what is user doing now? What’s the status of user? Where is user? And whom is user with? Moreover, it even can intelligently store and download information according to the status/type of network connection and storage capacity of the Internet Tablet. It would be in linked context-aware and semantic technique to reach the goal. Very interesting! Is your work tied to a specific news reader engine? In any case, what engine do you plan to use as a reference? I will use C+gtk to implement the whole project( if possible, I can try python), and for GSOC, during the 3 month or according to my schedule the 5 month. Related to the above: is the programming language used for your layer dependent of the language used by the engine or is it independent? Anybody starting an innovative mid term project should consider Qt as it is well supported in other platforms and will be supported in Symbian as well. Helping users getting cool unexpected news looks like a very good mobile use case, where you might have time to read (e.g. commuting or in your couch) but you are probably less inclined to spend much time searching what to read. If you really achieve your goal in Maemo I don't see why your project wouldn't be interesting in other mobile platforms (and not mobile as well). -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [GSoC 09] - IM Client For Canola Using Python-purple
Welcome Thiago! ext Thiago Bolaum wrote: Hi, My proposal for GSoC this year is to build a IM Client plugin for Canola. It'll will use python-puple and continue the development of this libpurple's binding. I was not very keen with the load of Canola specific projects presented to GSOC. Not that I have anything against Canola and not even against their good job mobilizing developers, but at some point it felt that Canola would become a whole services framework per se (a similar feeling to the one got with liqbase, but this is for another thread). For instance, Canola-Bittorrent is a marriage that kind of makes sense. Canola-IM... less so? It's fair to assume that most systems where Canola will be installed will have Maemo's RTComm, Pidgin and/or some kind of Telepathy related IM aplication. Why another IM? The point of your project is good: make it easy for Maemo users to IM with friends in several networks. I wonder if Canola is the right platform for that (but fair enough if you project got approved) but I hope a big % of your time can be invested improving the integration of libpurple in the Maemo platform. At the moment this integration is not precisely optimal and any help improving this situation is welcome. The idea is to improve python-puple along the whole development, adding features and correcting bugs as needed. Everything inside Canola is done using Python, and I will use the existing plugins as reference. I also intend to compile a comprehensive tutorial on how to build plugins, explaining what I've learned about Canola's architecture and framework in a wiki or blog. I'll try to release a usable version as soon as possible, because one of the most important parts of the project is respond to community feedbacks. Features and bug fixing will be done with your help, guys! =) I'll count on you to use it extensively and report problems and ideas to me. I'm currently a M. Sc. student, working with processors interconnection, at Unicamp (Universidade Estadual de Campinas) in SP/Brazil. My nick at freenode and garage is bolaum. -- Thiago 'bolaum' Borges Abdnur -- Trust no one... - Deep Throat (The X-Files) -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: [GSoC 09] - Liqbase Framework Development and Application Implementation
Hi Zach, welcome! ext Zach Habersang wrote: Howdy, As a GSoC student for this summer, I will be working on the project entitled Liqbase Framework Development and Application Implementation. The key idea behind this project is to develop the liqbase UI framework so that applications can be built on top by everyone and anyone with a stunning vision of an application they want to build with the sleek, interactive UI features of the liqbase library. I also voted for you being here, although my comment was and is: I really think liqbase should concentrate all efforts in doing what does best: taking notes combined with produced or captured images. My vote goes here hoping Gary gets more developers for that core purpose. Since Gary will probably not be convinced about concentrating in 2 tasks and forgetting about there rest until they are top notch... liqbase will surely benefit from an architecture where a core engine works together with independent plugins. Then we will help as much as possible Gary co fine tuning the 'sketching' and 'capturing' plugins, so Maemo end user don't have to bother about the intermediate menus and the micro-demos/features currently flying around the core purposethat has brought this little success to liqbase. My stunning vision of an application that I would like to build is a Systems/Network Monitor. As well as provide a awesome little netmon for the Maemo Community, my goal is to also have my application serve as shining example of how to use the liqbase framework to build applications on top. I plan to code almost entirely in C. I will be using the liqbase library built entirely from scratch by Gary Birkett (lcuk) to build my applications GUI. And, of course BSD sockets for the backend functionality of my netmon. I'm currently a high school student, attending Texas AM University @ College Station, Texas (USA) next fall. You can find me on IRC, ITT forums, and Maemo Garage with the nickname z4chh. I look forward to developing full time for Maemo and Liqbase this summer! Zach Habersang -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
OSM2Go finger friendliness (was Re: Reduce fremantle button spacing)
Hi, ext Till Harbaum / Lists wrote: Hi, fremantle increases button sizes significantly to make them more finger friendly. However, some applications like osm2go are imho not suited for finger usage and those big buttons thus waste screen space. As Claudio says, http://maemo.org/api_refs/5.0/pre-alpha/apis/libhildon-2.1.24/hildon-hildon-gtk.html#hildon-gtk-button-new allows you to define the size you wish overriding the very-finger-friendly defaults. The Maemo UI offers a default, developers are able to go for alternatives. No need to repeat in maemo-developers the 'stylus wars' debate we are seeing these days in ITt. But speaking opf OSM2Go, I do think it is suitable for finger usage and I would encourage the project to think it twice. I'm a fan of this application and I'm willing to help giving ideas and testing. Your app is 2Go and genuinely mobile. You are targeting several platform being Maemo the primary one. I guess mobility and touch are implied in the rest of platforms primarily supported. Yes, a stylus might be useful when it comes to draw lines in a map but I really wonder how frequent is in reality that use case compared to adding information to current maps. You do this by hitting a coordinate (and you have zoom), selecting a type of information and typing the infor related to it. Drawing is more for the end of the day, at home, with all the data you gathered while being on the Go... and probably you are going to prefer to do that still in front of your laptop. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Is osso-media-server open source?
For the Maemo 5 multimedia plans source see also http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle#Media_Application_Framework http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle#Multimedia Quim ext Martin Grimme wrote: Hi, osso-media-server is a D-Bus service that comes preinstalled on the tablets for playing media. Applications can control it via D-Bus, but the source code is not available. Its interface is not even public and applications using it won't work on the next major Maemo release (Maemo 5). So Nokia discourages using the osso-media-server interface by 3rd party applications. Maemo 5 will have another more versatile media server which will be open source. But osso-media-server is using GStreamer internally, which is open source, so you might want to take a look there. Regards, Martin 2009/4/17, Zhou, Jianchun (周建春) jianchun.z...@asianux.com: HI, there: I am new to Maemo, and now I am interested in Canola, especially it's Media Backend. I found that there is a media backend named oms(osso media server) I want to get it's source code to develop it. Is it open source? Thank you in advance. - Best Regards Wind Zhou ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Transitioning to the new package categories
ext Ryan Abel wrote: I'd like to propose that we start actively transitioning to the new categories in the beginning of May Note that first we should get a one and only list of categories. Now we seem to have 3 (Community proposal, Maemo policy and Fremantle current build): https://bugs.maemo.org/show_bug.cgi?id=3844#c6 -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Transitioning to the new package categories
ext Niels Breet wrote: A request for a Maemo policy change has been requested a long time ago: http://wiki.maemo.org/Task:Packaging_Policy_proposed_changes There is no visible progress on that task though. Ok, I guess we need to work on a new release between now and the Fremantle final release. We've been discussing this out in the open for a long time, it is kind of strange that the Fremantle team didn't do anything with these categories? After a bit of research... actually they seemed to do something with them, even if not discussing publicly: https://bugs.maemo.org/show_bug.cgi?id=3844#c8 -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Developer call: Mozilla/Maemo Danish Weekend
Gil Quim (Nokia-D/Helsinki) wrote: Hi, we are happy to announce a really exciting event for YOU: Developer call: Mozilla/Maemo Danish Weekend http://maemo.org/news/announcements/developer_call_mozilla_maemo_danish_weekend/ The Maemo and Mozilla projects are organizing a joint developer camp in Copenhagen the last weekend of May. If you are working on Fennec, Fennec add-ons or Maemo 5 applications this call is for you! The meeting is open and free, although registration is needed for planning purposes. Developers short on budget can apply for travel sponsorship now: http://wiki.maemo.org/Mozilla_Maemo_Danish_Weekend#Sponsorship Selection criteria: * Developers of Fennec add-ons, Fremantle Stars and the Mer project. Link to your projects and get references from lead developers. * Developers of cool software for average users available in [http://repository.maemo.org/extras-devel/pool/fremantle/free/ Fremantle extras-devel]. * Other key Maemo contributors with [http://maemo.org/profile/list/ high karma] and a concrete development plan for the weekend. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Developer call: Mozilla/Maemo Danish Weekend
Hi, we are happy to announce a really exciting event for YOU: Developer call: Mozilla/Maemo Danish Weekend http://maemo.org/news/announcements/developer_call_mozilla_maemo_danish_weekend/ The Maemo and Mozilla projects are organizing a joint developer camp in Copenhagen the last weekend of May. If you are working on Fennec, Fennec add-ons and Maemo 5 applications this call is for you! The meeting is open and free, although registration is needed for planning purposes. WHEN May 30-31 + Friday night party (29th). WHERE IT University of Copenhagen, easily accessible and conveniently located between the airport and the city center. There will be a hall + 3 rooms for hacking and an auditorium for presentations (follow the link above for map and pictures). WHAT This hands-on developer meeting is all about getting software ready for end users. Both Fennec and Maemo 5 will be in beta stage and approaching their final releases. Code, test, fix, improve... and have fun! Focus areas: * Fennec add-ons. * Mozilla core development common to Fennec and the Maemo browser. * Maemo applications: Fremantle Stars + other community projects willing to join. * Mer, aka the Maemo 5 community edition for N810/N800. Check http://wiki.maemo.org/MozillaMaemoDanishWeekend to know more about the Danish Weekend schedule and to get additional information. See you there! -- Your Mozilla-Maemo Garage Committee ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: detect window iconified/maximized in SDL
Hi, CCing Kuisma, Maemo SW maintainer of the SDL packages. ext Kees Jongenburger wrote: Hi, Should we/I start a small libsdl project on garage to address such issues? And what would be the goal of such garage project? Isn't enough to file bugs/patches against http://repository.maemo.org/pool/fremantle/free/libs/libsdl1.2/ http://repository.maemo.org/pool/fremantle/free/libs/libsdl-mixer1.2/ http://repository.maemo.org/pool/fremantle/free/libs/libsdl-image1.2/ Greetings On Thu, Mar 26, 2009 at 9:35 PM, W. de Hoog wdeh...@exalondelft.nl wrote: Hi, Do you have a separate thread that listens on the libosso callback stuff? That could work also if it locks up the main loop when display is turned off and (like your main thread) doesn't use SDL to wait for events. I do not have a seperate thread for it. I did register my callback but as I mailed, it is not being called back when the display goes on or off. This is very weird and disappointing. You can in select() listen on that file descriptor. You could look for an example here: http://hg.berlios.de/repos/hatari/file/c6567e2a430d/src/control.c Thanks for the link. However this seems a bit beyond my reach. regards, -- Willem-Jan de Hoog -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: detect window iconified/maximized in SDL
Hi, about these good SDL tips. Could you please help updating and documenting better SDL at http://wiki.maemo.org/Game_development ? It would benefit everybody. Thanks! ext W. de Hoog wrote: Hi, BTW. another, perhaps a simpler, way with SDL is to track the FocusOut -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Clutter in Fremantle (Alpha SDK)
ext Henrik Hedberg wrote: However, I think that the Clutter-GTK should be included in the official SDK. Could someone from Maemo Software comment on this? Yes, it needs to be. Hopefully in the beta SDK will be there. A reason for the delay has been that we are aiming to have Clutter 1.0 in the final release. Before integrating that version it was not critical to have the clutter-gtk bindings in the SDK. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OSiM
ext ma...@bitblit.net wrote: Are Nokia developers planning to be at OSiM in San Francisco this week? At least Not from Maemo SW. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder for Fremantle now available
ext Graham Cobb wrote: How about submmitting all the source packages from the existing Diablo extras-devel to try to build in the new Freemantle environment? That would help us get all the prerequisite libraries and tools built quickly, even if the GUI programs fail. Would be cool indeed. I for one would be interested to see how much of GPE (for example) just builds -- I haven't created a Freemantle build environment yet. And I for one would be interested to see how the API break affects really the current Maemo applications. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frets on Fire on Fremantle
Hi Jayesh, ext Jayesh Salvi wrote: Hi all, I have ported the popular desktop game Frets on Fire (Guitar Hero clone) to Fremantle. It leverages the OpenGL support in the new platform. Here is the video (http://blip.tv/file/1839929) You can find the details of the port on my blog post (http://jyro.blogspot.com/2009/03/frets-on-fire-on-maemo-5-fremantle.html). Some tweaks in the GUI and we might convert the next Nokia tablet into an electric guitar. Cool, thanks for the fast porting and the details in your blog post (including the bugs found through the exercise). You got a nice proof point for software relying directly on OpenGL ES and we hope to see more ports. Playing the game itself on the touchscreen might be problematic when having to register more than one press at the same time, though. By the way, do you mind uploading your packages to http://repository.maemo.org/extras-devel/pool/fremantle/ ? This way you don't need to mix the Diablo repositories and we start building a Fremantle extras common library. Same for the rest of developers starting to develop with Fremantle. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Frets on Fire on Fremantle
Gil Quim (Nokia-D/Helsinki) wrote: By the way, do you mind uploading your packages to http://repository.maemo.org/extras-devel/pool/fremantle/ ? This way you don't need to mix the Diablo repositories and we start building a Fremantle extras common library. Same for the rest of developers starting to develop with Fremantle. Sorry for the noise: I thought the repo was accessible with direct uploads but now I have been told that it's not, and the autobuilder is not yet in place. The guys in the know are working on this. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo 5 Alpha SDK released
Today, Nokia introduced the Maemo 5 Alpha SDK including the new UI framework and APIs for application development. The redesigned Maemo UI provides a simple and beautiful experience with a finger based full screen context. Developers can now use hardware-accelerated 3D graphics at WVGA resolution. We recommend that developers writing applications for Maemo 5 follow the UI style introduced with this Alpha SDK to provide a user experience consistent with the core applications. More: http://maemo.org/news/announcements/maemo_5_alpha_sdk_released/ http://maemo.org/development/sdks/maemo5_alpha_sdk/ -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
openSUSE Online Build System
Hi, any experiences and opinions about Build maemo-apps with openSUSE BuildService ? - It works ! http://lizards.opensuse.org/2009/01/27/build-maemo-apps-with-opensuse-buildservice-it-works/ http://en.opensuse.org/Build_Service/ I met the developers at FOSDEM and it looks like an interesting well thought service. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: multiple SDKs on the same sbox
ext Marius Gedminas wrote: On Sun, Feb 15, 2009 at 05:17:12PM -0800, Daniel Monteiro wrote: Hello folks, long time since my last email here. I've been silently developing my games for Maemo,but now here I am with a new question regarding Freemantle: Can I have Freemantle and Gregalle in the same sbox? This used to work with older SDK versions, see http://inz.fi/blog/2007/10/22/multi-target-development-for-maemo/ You might want to have a look at the beta release of the Maemo SDK+ based in Scratchbox2: http://maemo-sdk.garage.maemo.org/ -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Beagle board (was Re: Maemo 5 and hw accelerated X.Org?)
ext Quim Gil wrote: ext Alex T. W. LEUNG wrote: Hi Frank and maemo team, Do you mean if I have a beagleboard, I can use it to test drive maemo5 readily? https://garage.maemo.org/projects/maemo-beagle The slides of Juha's presentation at FOSDEM are on their way. I recorded the session but I'll have to check the sound quality on a laptop first. With the Fremantle alpha SDK release (to come soon) getting things to work in the Beagle board will be much easier. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo for commercial development (was Re: N810 RIP)
ext Ville M. Vainio wrote: On Mon, Feb 2, 2009 at 9:19 AM, Quim Gil quim@nokia.com wrote: My advice to commercial developers is to make a step in the Maemo platform, learn and have fun with it. ? I think this is the most sensible approach, yes. If you have a better advice for commercial developers in Maemo please share it. It seems the original statement is a bit too strong - creating a product for maemo doesn't need to be exclusively for entertainment/learning purposes. If you make your app with Qt, you also have a very good shot at providing a S60 port of the app in the future (with a much bigger installed base). Qt has community support in Maemo, it will get a stronger support in Fremantle and will be officially supported in Harmattan. So again, I think I'm just being consistent with what we have. Don't get me wrong, of course I want to see also commercial developers bringing great applications to Maemo. I also think the best way to get them is to be frank now, invite them to have a look by themselves and concentrate on what they are really looking for: platform, devices, sales and distribution channels. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Maemo for commercial development (was Re: N810 RIP)
ext John Holmblad wrote: Quim, are you really serious with your comment My advice to commercial developers is to make a step in the Maemo platform, learn and have fun with it. ? I think this is the most sensible approach, yes. If you have a better advice for commercial developers in Maemo please share it. Do you and Nokia really believe that in today's market environment software development businesses have the luxury of having fun. I think not. I can't speak for Nokia about this topic, but my personal opinion is that there is always a chance to try and learn something new and have fun with it. In fact, many economists say that learning and having fun with new things is an essential part of a business sustainability. I think their focus has to be and will be on creating applications that produce cash flow fast, that is, in timeframes measured in months, not years. Agreed. Since the Maemo platform nowadays hasn't got the volumes or the business infrastructure to produce cash flow fast by licensing software, I think my advice quoted above is correct. One exception that could bring you cash flow (if succeeding) would be to get a deal in the Forum Nokia context, which was also part of my advice in the same paragraph: Getting yourselves introduced to Forum Nokia might help you having some business even before. Nokia may have the luxury of supporting negative cash flow while it invests in and tweaks and has fun with a new hardware platform over a period of several years but software development shops, most of whom are innovative and small businesses do not have the luxury of such time. Agreed. And this is why Nokia is not trying to convince commercial developers to set up a business on top of Maemo nowadays. Perhaps one day this will change, and that day commercial developers will notice. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Maemo for commercial development (was Re: N810 RIP)
Hi, I understand all you want to know what device(s) come after the N810 and when. The only details we can share now is that more products will come for sure. ext Jeffrey Barish wrote: The rumors are fascinating. I wouldn't call rumors to - Public presentations done by Nokia representatives, from engineers to a vice-president. - 2 unstable releases (the second yesterday) telling already a lot about supported hardware and features. - Significant contributions done already upstream, starting from the omap list in the Linux kernel project. - Dozens of bugs resolved as FIXED targeting the Fremantle release plus an additional bunch of bugs commented as reproducible in Fremantle. - An announced selection of community projects that will get early access to new hardware. All the content visible and linked at http://wiki.maemo.org/Task:Maemo_roadmap/Fremantle comes from official sources. In the meantime, I am nearly ready to start shipping my software but my potential customers have nothing on which to run it, unless they happen to own an N8x0 already. The N810 sales are continuing. The progressive price reduction is business as usual in this industry. Nokia opened their platform to encourage developers to contribute their expertise, but their capriciousness and opacity about their hardware roadmap are tolerable only to hobbyists or companies porting software from another platform as a sideline. As much as I love free software and open roadmaps, I must reckon that in the current times transparent hardware roadmaps are not helping companies to sell devices sooner, cheaper or better. For companies like Nokia, the ultimate reason behind hardware roadmap opacity is to sell more and better, which is equivalent to increase more your potential user base. Get more (and happier) users by bringing better products than the competition and get more (and happier) users by managing consumer expectations and media hype. If you see only melodrama in these concerns, then perhaps you have never tried to run a business in the face of such uncertainty. For what is worth Forum Nokia is being quite frank presenting Maemo today more as a platform for fast prototyping and Linux innovation than a profitable business for application developers. My advice to commercial developers is to make a step in the Maemo platform, learn and have fun with it. This way you will be ready to go when the right time for commercial software comes. Getting yourselves introduced to Forum Nokia might help you having some business even before. -- Quim Gil open source advocate Maemo Software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
