Nokia Web Runtime developer questions
Posted also at http://talk.maemo.org/showthread.php?t=38214 Do you have questions about Nokia Web Runtime in Maemo? As announced in the Maemo Summit, it's coming for Maemo 5 and the Maemo 6: * Developing apps on Maemo with Nokia Web Runtime http://www.slideshare.net/santtuahonen/developing-apps-on-maemo-with-nokia-web-runtime * Hands-on development with Nokia Web Runtime http://www.slideshare.net/olevine/handson-development-with-nokia-web-runtime * Forum Nokia: Web Runtime widgets http://www.forum.nokia.com/Technology_Topics/Web_Technologies/Web_Runtime/ We have still some months to go. Now starts to be a good time to share questions about this developer technology, so we can fine tune the developer documentation. Nokia Web Runtime will be landing on Maemo and Symbian (S60 had it for a while but the new generation based on Qt and WebKit is a much more powerful beast). Web Runtime will be positioned as an entry point for cross-platform development and the expectation is to have the majority of developers using this technology, leaving the native Qt based development for specific and justified cases where more complexity and performance is needed. In fact it is very possible that some of you considering Qt now for cross-platform development will end up using Web Runtime instead. It is also possible that some of you power users not thinking of learning C, C++ or even Python will end up giving a try to the Javascript based Web Runtime, turning yourselves into developers as well. So please, share your questions and thoughts here. I can't promise any answers soon but I can grant you that such questions will be taken into account when writing the documentation, helping us to bring the first Nokia Web Runtime releases for Maemo with documentation more suitable for your needs. Since the Nokia Web Runtime is a cross-platform technology, most of the documentation will be just as cross-platform in itself. However, depending on your feedback we might have some content in the Maemo Developer Guide providing the extra bits interesting to Maemo developers, linking to the original and independent Web Runtime documentation for the rest. -- Quim Gil + N900 open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Pushing optified Python libs
Hi, it seems that more users than wished are still reaching the rootfs limit only with the Nokia and Extras repos installed. Most (all?) Apps in Extras seem to be correctly optified, so one possibility is that the problem relies in the libraries. Sorry if I have missed something but I remember a post mentioning that optified libraries were available in Extras-devel but still not Extras. if true, and if the libraries have been tested, would there be a possibility to push them to Extras forcing an update in the background? Also, if you know or suspect other causes for Extras users filling their rootfs partitions please let us know. -- Quim Gil + N900 open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: individuals being able to join Ovi store
Please see original communications below. The subject is how can indiduals without a business affiliation sell on Ovi?. Currently they are bing rejected: http://talk.maemo.org/showthread.php?t=34661 Can we encourage a broadening of policy? Should we? Answer before jumping to the plane to Copenhagen' Maemo Developer Days: http://talk.maemo.org/showthread.php?p=380253#post380253 Let's continue the discussion about OSS Ovi wherever you prefer but one maemo.org place is enough. -- Quim Gil open source advocate Maemo Devices @ Nokia - Original message - From: Valerio Valerio vdv...@gmail.com To: Randall Arnold tex...@ovi.com Subject: Re: individuals being able to join Ovi store Date: Tue, 17 Nov 2009 21:22:27 + Hi, On Tue, Nov 17, 2009 at 9:03 PM, Randall Arnold tex...@ovi.com wrote: I'm starting this on the council list because I think we should champion the cause... but I'm okay with this moving to the Community list at any time. I really believe we need to address the issue of individual developers being unable to to sell through Ovi without being incorporated. One of the reasons I started the LinkedIn group maemo daemons was to explore the idea of a loose consortium setup for this purpose. Oh, I thought if you pay the 50 € you can sell things as a individual, does that changed ? I've friends selling things through OVI (S60) and they aren't a legal identity, maybe it varies from country to country. Anyway this should be moved to the community list, you've my support ;). Thanks for catch this issue. Best regards, -- Valério Valério http://www.valeriovalerio.org I'm no expert in this area but I will definitely facilitate what I can, if there's a way to resolve this with some sort of collective. Latest thread on the subject: http://talk.maemo.org/showthread.php?p=379852#post379852 Thoughts? Randall (Randy) Arnold maemo.org community council -- Ovi Store: Get free stuff for your mobile phone http://store.ovi.com/?cid=ovistore-fw-bac-na-acq-na-ovimail-g0-na-1 http://tabulacrypticum.wordpress.com/ -- Ovi Mail: Simple and user-friendly interface http://mail.ovi.com Attachment ATT1..txt ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Does Uploading to Extras need updating for Fremantle?
Warning: I'm planning to attack extras-testing wiki page tomorrow in order to offer clearer information about quality criteria for developers and betatesters. My humble contribution to the extras-testing marathon http://talk.maemo.org/showthread.php?t=33164 -- Sent with Maemo 5 Quim Gil open source advocate Maemo Devices @ Nokia - Original message - Hi all, I'm wondering if http://wiki.maemo.org/Uploading_to_Extras needs updating in the context of http://wiki.maemo.org/Extras-testing and http://wiki.maemo.org/Extras after the Maemo 5 release - I'm afraid I don't have teh smarts to be able to tell. Could someone who has experience using Extras, and familiar with the extras-testing extras-devel set-up, please have a look see if it needs revising? The page is linked to from http://maemo.org/development Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-community mailing list maemo-commun...@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-community ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Seriously: don't send users out of Extras without a big warning
(This has been posted at http://talk.maemo.org/showthread.php?p=343619 as well) Now that we have hundreds of N900 testers it's a good time to settle on something that we have discussed many time in the past: the big majority of users should rely on the maemo.org Extras repository and the official Nokia repos only. Anybody installing extras-testing, extras-devel, a third party repository, a single deb package or any combination requiring openng xterm is not a pure end user anymore but a tester. At least s/he should know! So please think it twice before posting, forwarding, reposting and recommending anything out of the stable repositories at nokia.com and maemo.org. Two very concrete examples that current N900 users can suffer already today: - Full memory because of apps ignoring the recommendation of installing big files in the internal memory. - Significantly shorter use times because of widgets and apps not paying much attention to power management. The Maemo community has put a big effort creating a quality assurance process in order to guarantee certain standards. Advanced users aware of the risks of unstable software are helping evaluating whether apps are ready for end users or not. Don't bypass all this hard work by making popular buggy software. At least not without a big warning. End users might be happy in the short term with your links and tricks but the risk of making their Maemo life miserable are high if they are unaware of the possible consequences. Instead, giving feedback to the generally goodwilling developers will help them fixing the problems and offering the software end users want without hacks, tricks and dirt under the carpet. BIG THANK YOU for reading this, propagating the message and helping out. -- Sent with Maemo 5 by 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: repository.maemo.org
Hi all, i am missing something like packages.debian.org for repository.maemo.org http://maemo.org/packages :) -- sent with Maemo 5 by 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 5 Final SDK + gitorious
Hi, two great things happened today. We released the Maemo 5 Final SDK http://flors.wordpress.com/2009/10/06/maemo-5-final-sdk-released-go-extras/ We also opened http://maemo.gitorious.org http://maemoteam.wordpress.com/2009/10/06/maemo-gitorious-org/ See also the related discussions at http://talk.maemo.org/forumdisplay.php?f=13 quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
On Wed, September 30, 2009 10:47, Andrew Flegg wrote: On Wed, Sep 30, 2009 at 05:25, quim@nokia.com wrote: Given the speed around which the colour picker discussions settled down, and the fact it will iterate quickly once actually being used in a real world app, I can't imagine working in upstream libhildon *and then waiting for Nokia to ship that update* (assuming that it is shipped at all) will be very effective at all. Unless I'm missing something and Nokia aren't just willing to ship a libhildon update, but you're willing to ship one when we (i.e. the widget developers and libhildon maintainers) ask. Unless the SSU is being done at regular intervals, because then you can at least aim for a certain date. But even then, you would need to know if your updated lib will be part of the SSU in the first place. Projects like GNOME or Ubuntu need 6 month iterations between stable releases. Would you say that 6 months after the Maemo 5 final is good enough or too slow? Quim PS: if 6 months to reach end users is considered too slow for an official widget that today is still under discussion then perhaps we need to re-check expectations based on real life examples? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
No, you are right, it should not be hard to accept contributions to libhildon. I agree. Maybe I'm wrong but I think Hildon updates are possible in Fremantle. As long as the new widgets make sense, the patches are good and they are well tested by the community and don't introduce risks or regressions... Why not? The Fremantle program runs their tests on the software pre-installed. If new widgets are introduced but they are not used by the official apps the probkem is perhaps not that big. Again, if good design, programming and testing back those new widgets. This is no different than any mature piece of software being deployed in commercial devices. You can try out these widgets in an unstable branch, Nokia can keep the stable branch for Maemo. If patches in unstable are proven to work then libhildon can have this minor update. In the meantime you can work on more radical changes if you wish, that will belong to a future major update perhaps. At some point Harmattan will be under our feet, Hildon will be out of Nokia's domain and whoever in the community works in the Harmattan version will be able to decide what comes in and what stays out. Quim Gil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Community widgets for Fremantle
I agree. Maybe I'm wrong but I think Hildon updates are possible in Fremantle. As long as the new widgets make sense, the patches are good and they are well tested by the community and don't introduce risks or regressions... Why not? Because there's a perceived *risk* of risks regressions. How many of our App Manager patches shipped to Diablo users once Maemo Devices had moved on to Fremantle? None. Is there any reason to suspect that the situation will be different with Fremantle once Maemo Devices is pushing for Harmattan? Yes, there are reasons that come to mind: - Hildon is a library. Adding widgets doesn't affect the user experience, testing, etc of current widgets. If a new widget turns out to be conflictive it won't affect any official app since they will stick to the widgets used now for the Maemo 5 final release. Therefore the whole discussion of accepting enhancements is made more among platform developers without adding much of UI designers and product managers to the mix. If the changes don't bring any straings for localization all the better. This is very different compared to a pre-installed application. - App Manager Diablo was moving to App Manager Fremantle both inside the Maemo team and there were clear project management instructions about where to put the resources. Instead, the Desktop team has mostly two different subteams for Hildon and the Qt based application framework for Harmattan since both projects require different timings and skills. The Hildon skills and mid term decisions are nowadays in practice more in the hands of GNOME developers working for Igalia, Lanedo, Openismus, Collabora... If they want to push Hildon forward and your patches and commitment are convincing you will need to deal with less and less Nokia internal project plans. - It is clear that Hildon must go upstream around GNOME and GTK+ or will have clearly no sustainable future. The Maemo team needs to start handling this transfer of ownership. The schedule is not defined by the end of the Fremantle timeline but by the beginning of the Harmattan timeline. You have seen the Maemo Summit schedule and you know this time is coming already. - The Maemo team has learned a thing or to, thanks to many factors including the App Manager Diablo contributions fiasco. We have contribution guidelines, we had Fremantle pre-releases since pre-alpha and you have here non-Nokians like Claudio or Berto able to discuss openly details about their are of responsibility and run entire garage projects and git repositories. You will know better the technical decisions about packaging etc but at least you know my opinions as one of the persons in the Maemo team responsible of finding the best future for Hildon as a community supported project. I hope you can keep all Hildon contributions around the Hildon trunk repository and within one real project. Hildon needs all the community interest and support concentrated in one point. Spreading energies can be too expensive. Like Claudio says, if the problem is the distribution then let's concentrate on the root of the real problem while developing code and features in the optimal way. -- Quim Gil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: N900 usb host + power charge
Hi, I plan to create a proposal for the push n900[1] and I plan to use the usb port. I have the following question. When the device is in usb-host mode it should of course provide power does it? Is it possible to charge the device while it's in usb-host mode? The N900 comes without USB host mode. When I asked I was told that the limitation comes at hardware level. The reason for this decision was the complexity of providing support for charging, PC connectivity and USB OTG efficiently through the same Micro USB port within the project deadlines. We needed to make choices and the decision was to sacrify USB OTG and concentrate on the essential use cases of charging and connecting to the PC, bringing the N900 to the market in its due 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: Considering /opt and MyDocs in your packages
Limiting it to a hack for a large app results in a question of when is an app large: 1MB, 2MB, 4MB, 8MB, 16MB, ...? If we can have a consensus on *that*, that could be something we have a QA check for? Developers are encouraged to make good use of them, specially for applications requiring more than 500KB, including dependencies. http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing/Installing_under_opt_and_MyDocs Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Maemo will switch (completely?) to Qt?
Hi, I'm away from computer but you can check the audio and slides of the presentation plus some links at http://flors.wordpress.com Quim --- original message --- From: ext Klaus Rotter kl...@rotters.de Subject: Maemo will switch (completely?) to Qt? Date: 5th July 2009 Time: 9:37:29 pm Hi there, I've just read, that Maemo will switch to Qt for the new Maemo 6 version. Well, I personally think this is a good decision. Quim Gil told this at his keynote at the Gran Canaria Desktop Summit. If this is true, what will happen to the gtk toolkit? Will it stay on the tablet? When will it be obsolete? Is it planned, that the Qt shipped with Maemo 5 will be compatible (at least source code) with the one shipped with Maemo 6? -- Klaus Rotter * klaus at rotters dot de * www.rotters.de ___ 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: closed tools, Re: Maemo Flasher-3.5 Tool Beta for Fremantle an d Diablo released
Hi, I'm following the discussion but bare with me these days since I'm in the Desktop Summit well away from the office and the people to ask about this are very possibly on holidays until August (just like myself after the Summit). If you think we are violating any license or doing something wrong in general please file a bug or ping in an existing one, CCing me. This is the best way to discuss and solve a problem between different people across the Summer. Thank you! Quim --- original message --- From: Hassan Mohammed.2 (Nokia-D/Helsinki) mohammed.2.has...@nokia.com Subject: Re: closed tools, Re: Maemo Flasher-3.5 Tool Beta for Fremantle and Diablo released Date: 3rd July 2009 Time: 3:53:52 pm Oops. Forgot to CC him. On Thu, 2009-07-02 at 14:33 +0200, ext e...@okerson.com wrote: Hi, Faheem Pervez wrote: You sure you have a choice in the matter? Considering how you're already violating the GPL. Dave Neary wrote: I don't know the details of the situation. I just want to remind you that the GPL is a distribution licence. That's why we don't get all Google's changes to the Linux kernel and Apache back upstream. It seems that I've seen people say that Nokia doesn't even distribute the initfs tools. If that's the case, there wouldn't be any GPL violation. But Google isn't distributing their Linux Kernel or Apache, Nokia is distributing the initfs. Which is why Nokia is violating the GPL (I haven't checked myself that code is not being distributed for stuff in initfs). I'd say the best option is to poke Quim Gil as I assume he's the correct person to handle this (I'm CC'ing him although I assume he reads this list). Cheers, -- Maemo Software Nokia Devices ___ 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
Maemo developers wanted in Санкт-Петерб ург
If you could read the subject ;) then maybe you are target for this: http://fruct.org/index.php?morus_itemid=65 This morning we met the organizers of the next FRUCT seminar and they told us they would welcome Maemo developers willing to showcase their work and tell about their experiences in the Maemo community. If you are good and not too far away they might even have some budget to sponsor your trip. If you are interested introduce yourself to Timofey (dot) Turenko at Nokia (dot) com. FRUCT stands for Finnish-Russian University Cooperation Program in Telecommunications and they develop several Maemo research projects - http://fruct.org/index.php?morus_itemid=3 This was also posted at http://www.internettablettalk.com/forums/showthread.php?p=274894 -- 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 contribution guidelines - v1.0 candidate draft
http://wiki.maemo.org/Maemo_contribution_guidelines This has gone through several rounds of feedback and it will be considered official as is unless sensible major changes are proposed. Feedback and precision are always welcome. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
About release dates (was RE: maemo Bug Jar #7)
Hi, Am Donnerstag, 5. Juni 2008 schrieb [EMAIL PROTECTED]: Frederic Crozat wrote: Remember that most people are not used to Nokia policy to embargo any date (even estimate) regarding software (or hardware) release. True. These people need to understand that Nokia is a company watched by competitors, the media, shareholders... Device launches and software releases have an impact in this context far beyond the software update itself. This is why Nokia generally doesn't disclose release dates. For simplicity's sake, I don't know when Diablo will be released. Quality first! Releasing shouldn't _only_ be a management decision. When the quality is as expected then the (scrum ?) team should hand over the responsibility to the management. They can then powerpoint the great event ;-) And this is what the maemo development team does. To understand better what Josh is saying you need to know that there is a gap of time between the moment the development team says 'this release is ready' and the moment the image goes actually out. The public release date is decided from a business and marketing perspective based on many factors that go beyond the quality of the software. Personally I consider fix release dates as contra productive. Quality it the key to success. There are lots of books about waterfall and agile development, and about feature or timebox based development. In fact all combinations exist i.e. agile + timebox. Also, who said our release dates are so fixed? Remember how upset some people were last year when I dared to give rough time estimations for the Hacker Edition and the OS2008 releases, and at the end they came later? Guess what was the role of quality in that. However, consider fix release dates as contra productive is easier said than done when you have factories, distribution channels, marketing teams and more releases ongoing at different stages, all of them needing to have a good coordination with you, while having to support also other development projects running in parallel elsewhere. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: New Jobs section
Hi, I would like to work for Nokia @Nokia as a think-tank, Your options are: - Watch the job positions posted in maemo.org and apply in the ones that interest you. - Learn more about Nokia Careers at http://www.nokia.com/A4126297 -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: maemo Bug Jar #4
Thanks! Very useful already and hopefully it will be even better as we do more Jar iterations. Suggestions for improvement: - Separate bugs and enhancement requests properly, since they have different degrees of urgency, the level of responsibility on them is different and in fact they follow different processes internally. It is not always easy to differentiate a bug from a feature request and many enhancement requests are minor and totally based on small fixes a developer alone can do, but this is the work of the persons dealing with the bug report, not a problem in this report. This is most visible in the Ten biggest open bugs by number of votes and Ten biggest open bugs by importance, where each enhancement request there is actually taking the place of a bug that would deserve more visibility. otoh it is easy to generate top 10 feature requests tables. - Highlight what is new and major-critical-blocker. Sometimes it helps addressing issues sooner and better, sometimes it helps assigning the right severity. - Of course graphs showing the basic history are always useful. For instance, having trends, seeing if things go better or worse, see the impact of i.e. the Diablo release in the numbers... All this would help us pointing out to people inside Nokia what is going on in the wide picture. This summary is also available on Internet Tablet Talk: http://www.internettablettalk.com/forums/showthread.php?p=18182 1#post181821 What about keeping the history in the new maemo.org MediaWiki. Thanks again for your time and help. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Corporate ownership of open source projects [LWN]
Thanks for the discussion and the many good ideas. About silence, in fact a lot of it has not to do with confidentiality but lack of priority (or too many top priorities in the hands of us able to respond). What about a short term plan with common objectives: - Raise in a structured way the topics that matter to you where you feel there is a lack of response from Nokia. Now it is difficult to follow everything even to people like me spending a lot of time here, leave alone the average lead developer, project manager or product manager in the house. - Tag silences i.e. ToDo (answer will come when we have time), Planning (still undecided, working on it), Later or Depends on XXX (other events need to come first), Confidential (the stuf we really cannot talk about, probably less than you think). - Prioritize the items you want answered first. Proposal for actions: - Niels (web tools), Dave (web content) and Andre/Karsten (to be introduced officially as bugmasters) are your kind of representatives and they have lots of hours funded by Nokia to work for you. They are the ones prioritizing the tasks that are relevant to the community. Make sure they see how important is the thing you want to push. Avoid private communications unless your stuff is private: lobby here, in bugzilla, in planet maemo... - This prioritization should be visible somewhereand people should be able to impact it directly. Someone proposed to have some kind of ideastorm where the community could make visible the stuff that really matters. Voting bugs in bugzilla kind of does it but kind of not. Let's work on this, starting soon and simple - then improve. Give us the hottest topics in the main areas and let's concentrate on those. - Diablo is coming. Let's pick the components in this software release and let's make a table where packages are organized in a clear way to show where they sit in the platform and what functionality they provide. Then let's look at the closed components and let's work on the why are they closed and what is the plan about them. - Roadmapping the open source components of the platform. Should be doable in most cases, specially those libraries developers care about. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Google SoC 2008
Hi, So please tell me how maemo won status of legal entity under Google terms and provided Google with tax statement as an organization ? We din't provide any tax information and this was not an obstacle to get approved (but I understand this is not the rule). Because we didn't provide that information we actually didn't get any money as organization. I asked around what to do with the money but there was not a specific plan or something I could simply delegate. I really can't answer your doubts about Google, but I'd say that many organizations (even some really informal when it comes to legal status) got approved without much complication, thanks for running something cool and have a community around it. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: N810 availability?
Hi, Is there anything you can do a little less silently? Such as comment (or even *hint*) as to what the delay *is*? Now we can comment that there is an OS2008 beta for the N800 targetting basically you, the developers: http://maemo.org/news/announcements/view/os2008beta_for_n800.html . It is also said there that the OS2008 final for the N800 is expected to be released by mid December. We can also comment that we expect the N810 discount codes for maemo contributors to be fully operational in the Nokia online shops by 15/dec. Providing details about the availability of Nokia devices in the shops is out of our scope in maemo, really. This is the work of the Nokia sales channels, shops and retailers. We hope you understand. Quim PS: fwiw I commented this weekend in out-of-office mode at http://www.eth0.it/2007/11/24/about-n810-release-date-and-nokia-strategy / ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Repositories mess: conclusions and actions
Alright, so we seem to agree in the general concepts. Let's go into details. The question is not the quality of the Quality awareness document which likely could be improved. The question is, if such a document is the right way to control quality? Alright, what about leaving the role of this document in a checkbox developers check in order to get upload rights to extras, à la terms conditions. Something like I'm aware of the maemo Quality Awareness criteria and I have tested my applications against them before uploading them to extras. Of course developers might check the box after having gone through the 100%, 50% or 0% of cases and his software might or might not contain major bugs, but at least nobody can say - 'sorry guys, I didn't know my app could brick the device'. So what we then would need, is a in-queue with new packages and every package has to be manually testes. This would assure quality on a very high level, but likely would not scale (and possibly would not work with a small community). Agreed. In this case I would still suggest using the three holy kings (bug tracking, staged repository, application catalog) but at this point would not concentrate on the holy guide but on the holy process. Sounds good. * A packages does not get into the stable repository if its bugs are over the limit (and debian has a precise definition for limit :-)). Any requirement about where these bugs should be filed? The minimum requirement would be a public bug tracking system and responsiveness from the developers. * A packages does not get into the stable extras repository if there are not at least X successful installation and behavior reports. * A package needs some average ranking to enter the stable repository. http://maemo.org/downloads can serve well this purpose. * We must find some clever way to get a response from the user since we cannot trust the masses (our masses are not of equal size then that of debian). * For example: What about the program manager on the device periodically requests a rating from you for newly installed applications. There will of course be a way to switch it off, and the the notification must not violently jump into the middle of the screen swinging its broadsword, disturbing my circles. We might discuss about this feature in the Application Manager. However, if you find this idea useful it would be faster and probably better to start with an installable 3rd party application covering this functionality and targeted to maemo power users. * Also it might be very effective to collect and submit regular crash reports from the device to the application catalog (of course delivery must again be optional and not the microsoft way). Good point. * Also we need a very easy way to get bug reports (and feature requests) directly from the device into the bug tracking system. It is clear the convenience of having an automated way to send crash reports with traces, but what else would be needed other than that? Do you mean an option inside the application saving you the effort to find the right bugtracker/product/component? This all requires some very fine, polity and well though out additional applications and internal workflows but I think it Looks like a pretty feasible set of points to start working in the right direction. More criteria or is this enough? What about the human side? Who has the authority to say 'you get in', 'you go out'? Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo 4.0 Chinook beta SDK released
Nokia has released the beta version of the maemo 4.0 SDK http://maemo.org/development/sdks/maemo_4_0_chinook_beta_sdk.html , codenamed Chinook (shortcut http://tabletsdev.maemo.org/unstable/chinook-beta/ for the impatient). Developers are encouraged to port their applications from maemo 3.x Bora to the new version and be prepared for the next Nokia Internet Tablet OS release. You can also use this SDK to create your brand new maemo software. A new Chinook repository has been created to host your new packages. As previously announced http://maemo.org/news/announcements/view/1184675758.html , Chinook comes with lots of new features an enhancements, including an upgrade to the upstream GTK+ 2.10 and Glibc 2.5. More details can be found in the release notes http://tabletsdev.maemo.org/unstable/chinook-beta/maemo-sdk-relnotes_4. 0beta.txt and the documentation explaining the API changes between maemo 3.2 and maemo 4.0 http://maemo.org/development/sdks/api_changes_between_maemo_3_2_and_mae mo_4_0.html . If you are developing a GUI application make sure you use the Hildon audit tool http://live.gnome.org/Hildon/TwoPointZero , it will save you a lot of time and hassle. The beta SDK has still some missing packages and known issues, but the APIs are frozen and the software is solid. The Nokia binaries are not included either but none of this is an obstacle to get software working in maemo Chinook. We could choose between releasing now or waiting until getting more packages and fixes. Giving developers more time to get their software ready has been considered a top priority. We can't compromise to a public date yet but you will know in advance when the new Nokia Internet Tablet OS will be released. The Chinook beta SDK offers a new modular installation, allowing to choose the components needed according to the type of development the SDK is used for. This means that now the rootstraps are reduced to a small set of critical packages, while all the rest are hosted in the repository. This setting provides us also more flexibility releasing updates. More information in the installation instructions http://tabletsdev.maemo.org/unstable/chinook-beta/INSTALL.txt . We hope you like this beta! Please provide feedback, we have room for improvement until the final release. We are specially interested hearing about the SDK specific components. Remember to file your bugs at bugs.maemo.org specifying the 4.0 beta version. maemo team http://maemo.org ___ maemo-announce mailing list [EMAIL PROTECTED] https://lists.maemo.org/mailman/listinfo/maemo-announce ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: General bugs being assigned to ITOS2007HE in Garage, not Bugzilla
Hi, the non-770 exclusive bugs will stay in bugzilla. I believe some of the bugs were copied to Garage because they had an IT OS 2006 flag or something. No big deal. Justice will be done for each bug in the right bugtracker. Quim There seems to be an effort to comb through Bugzilla (always a Good Thing) to look for ways of improving OS2007HE (also a Good Thing)... however, once identified the bugs are being copied into OS2007on770's bug tracker in garage and keywords added to the original Bugzilla bug suggesting it's now being tracked in OS2007HE's Garage. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Ideas for Diablo and Elephanta: OpenEmbedded
Hi Sebastian, It would be great to have a working DISTRO configuration in OE which enables one to produce binary compatible packages. Is http://dev.openbossa.org/trac/mamona going in the direction you wish? Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Ideas for Diablo and Elephanta: OpenEmbedded
Mamona will be more useful and successful if it serves properly maemo developers like Sebastian. I'm sure the INdT guys have this in mind. :) In terms of roadmapping for us maemo + OE = mamona INdT is doing pretty well with the development and I don't see a need for us now to take part directly. Nor have we currently plans of supporting officially mamona. In the meantime we have an official SDK based on Scratchbox, and we prefer to concentrate energies in improving it. We are relatively happy about it: it works and we use it ourselves. There are some things we dislike and as for today we think that we can address them through something like Scratchbox2 + System QEMU + Raemo + IDE plugins. One development for many targets is an important principle for us, not always easy to apply. Usage of common components, versions and developer tools across hardware vendors would help. We try to do the steps to align as much as possible with the Linux desktop and the diverse mobile variants based on GNOME/GTK+. Quim No. When I understand mamona right, it is an approach to create a completely free distribution for the N800 (as replacement of maemo). The package selection seems to be based on Angstroem and it uses an upstream gcc4.1 with binutils2.17.50.0.5, at the moment [0]. While mamona is a very nice thing, it does not help to produce packages for maemo. For this we would need at least a binary compatible gnu toolchain in OE (mainly gcc, binutils, glibc). Of course, it would be nice to have the hildon libraries buildable there, too. Whereby the later one should be easy, I can't estimate the effort for the toolchain. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Public maemo repository
Ok, let me go once again back to this boat analogy. I wasn't in the early days of this project so I really don't know the detals of the first decisions, but I still see that the options chosen probably made a lot of sense on that time. Maybe because the whole concept of something that is heavier than water but still floats without effort seemed to be too good to be true. Wood floats, agreed. But sorry, not without effort. Nokia has good engineers even if sometimes you disagree with their decisions. I believe they knew about the Archimedes principle when playing with wood. But you know what, good saylors of my Mediterranean town know that this perfect theoric principle doesn't work in reality (and Archimedes surely knew as well): floating wood ends up soaking and sinking if you don't put a lot of effort maintaining it. Combine this RealPhysics principle with the already commented fact that a distro is a lot more than code (i.e. the humans around it) and you find good reasons to start doing what our Nokia team ended up doing in the early days. Nokia does not make it a secret that they choose for strong upstream projects and the last moves (the ubuntu mobile stuff) shows that apparently something was created that will be usable on different platforms. Let's keep the transport analogies. You know that warning in the aircrafts: Help yourself before attempting to help others. This is exactly our case. We still have a lot to do in order to make application and platform developers happy inside the maemo platform. We are really happy seeing that Intel, Ubuntu and others are interested in using parts of our work. We want to help them, but in order to do that we need to make sure that maemo itself is in a good position to help them. Could you elaborate a litte on the choice for debian as opposed to openembedded or the openwrt kind of distro's?(small fast ships that allow water-skying :P ) is that the strong upstream projects thing? Allignment and direct connection with upstream projects is probably the strongest reason nowadays. We don't say the OpenEmbedded aproach is bad: it's clear that is a good approach that works. But we can't support officially all the alternatives and one choice had to be made. I think we are currently in the right path even if we could make developers' life much easier when compiling, packaging, debugging (but this is another topic). If you disagree you can always try and support alternatives like Mamona. I do like the idea that the time I spend on maemo stuff might be usable on different platforms. I insist on this basic statement: we want people to install whatever they want in the Nokia tablets and we want people to use maemo in the way they want in non-Nokia devices. A core driver of this statement is our will to help developers developing once and targetting to different platform, getting the best result from their software and their time. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Public maemo repository (plus Intro)
Hi Loïc, The first reason Nokia / Maemo might want to offer an unstable repository is quite certainly to ease developer participation. But I think there are two things which you're developing at the same time: - upstream development of some software (especially Hildon, misc N800 apps such as the embedded browser, some proprietary modules...) - the Maemo distribution(s) (its packaging, integration, themes and branding...) These are quite different and while you're doing both at the same time, one might wonder which one of these you're looking to open the development of. This is a very good point, and there is not a common answer for all the packages. Something we have to clarify is the feedback and contributions expected in each component. Some potential scenarios: - Package A developed by Nokia and open source. Bugs and patches welcome. - Package B developed by Nokia and closed source. Bugs welcome. - Package C fully developed upstream and open source. Feedback and contributions to be done upstream, we inherit. - Package D fully developed by some partner and closed source. Feedback where the partner decides. - In the extras side: package E fully developed by a garage project and open source. Feedback, bugs and patches sent wherever it is agreed. if your goal is to improve the development of the Hildon stack, then perhaps the important focus should be on moving to GNOME's hosting infrastructure. Hildon has started already its upstreamization and we have a compromise to complete. This is for real and will take a while to achieve it. On top of extracting the Hildon packages from the maemo context, we have to sort out deep changes like moving to GNOME's release cycle and sharing the development with others. If we ever have a non-stable distro, Hildon will be probably treated as a pure upstream project. You mention a non-stable (and not unstable) repository: perhaps you already tickled the idea of having a testing-style distribution? I'm insisting in non-stable only because at this point there is not a clear idea whether it would be more suitable to have testing, unstable or both. How would this work in practice? Would it be more suitable to use this Debian approach or the GNOME/Ubuntu (n months to go from unstable to stable). Hmm I fail to see a huge difference here: There is. I'll try to summarize the details another day. there's a non-technical angle that will need to be addressed as well: Yes, I have insisted on the human factors of maintaining a distro and, in fact, I'm personally more concerned about them than about the code management itself. who do you grant access to such an archive? Will the archive only be available for Nokia folks to upload to, or will anybody be able to join a new uploaders community? How will you select people who are allowed to upload software which will be built on your build daemons and which will run on the devices of the end-users/end-developers tracking the unstable repo? To be defined. I wouldn't expect radical changes in terms of ownership and control of packages and commits, but there is probably room for a positive evolution. It would be useful to look in detail how other companies (Canonical, RedHat, Novell, Sun...) are dealing with this. IOW, are you interested in creating a new technical distribution tool fully handled by the same people currently handling Maemo, or are you interested in building a new community with its processes, rules and policies? Mmm probably a combination of both. Nokia needs to handle the software that is officially supporting (main restricted, so to say). The extras repository could be handled at a community level (it would be interesting to see this happening down-top). Perhaps one day the community would be in a condition of creating an own flavour totally controlled at a community level and able to run in the tablets. I don't think Nokia would object as far as the core objective is fulfilled: a more powerful IT OS preinstalled and better releases/upgrades thanks to the collaboration between Nokia - community - 3rd parties around the distro. Quim PS: I'm starting short holidays and I will be away from keyboard. I hope in the meantime the developer call gets more feedback and points of view. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo trademark
I owed an answer to Guillem: http://lists.maemo.org/pipermail/maemo-developers/2007-May/010397.html Thanks for challenging the maemo trademark policy with specific examples. They help to detect cases where it would make sense to have a tool to protect your identity and reputation. In the general section when talking about the maemo trademark and significant changes done to products and services it states those may not be distributed. Even if it seems to refer to maemo as a whole (like the distro or whatever), I take that applies to single software projects which have maemo in their name as well? As for today the only product released as maemo is the SDK and associated repository for developers (i.e maemo 3.2 Bora). If you make significant changes to it you can't call it maemo anymore. About other software projects using maemo for historical reasons (i.e. Maemo Something), we don't decide whether an altered version can or can't be named as Maemo Something. We might help the Maemo Something maintainers if they want to enforce a forked version to be named differently. We might end up unauthorizing both using maemo if they cause such a mess and it looks like we have something to do with that. Hopefully we never have to make use of this clausule. How much would be a significant change (I'm thinking on the general patching a distro might do which depending on your interpretatino might be significant)? To be defined if someone raises a case but I guess it would be measured at a functionality level + look feel. If the non-commercial use right applies to those single projects (which I also take it does), those would have to be renamed on inclusion on free distros so that derivatives can use them safely? Hum, good point. You mean i.e. that Maemo Something would be packaged for Distro Mobile and then shipped in Mobile Device that would charge for the software or would promote Maemo Something as part of their commercial strategy. If that's the case Mobile Device, Distro Mobile and Maemo Something could be theoretically in trouble, yes. I say theoretically because we would always decide whether to take action or not. In the current mode the previous example could be considered good publicity for the maemo platform. It is good to have a protection in the case the combinations damage our image, though. What's the license for those logos, there's not file stating any in the zip file? Hum, I have to ask but it looks like indeed there isn't any. If I'm right it means that right now the license would be All rights reserved. I guess what we want is something like http://creativecommons.org/licenses/by-nc-nd/3.0/ - or whatever is similar for logos and other images you want to redistribute but not alter. Suggestions welcome. Of course all the projects/products currently called maemo something can keep the name. You were quicker than us, well done. You will be subject to the policy and guidelines, though, just like anybody else (including i.e. the team running this website). This contradicts with what's stated on the FAQ, which is the correct one? I don't see contradiction today. The FAQ says: Q: I already have an application/plug-in/theme/... product that contains the name maemo. Do I need to change the name of my product or ask permission from Nokia to continue using my current product name? A: If you have published your product or service before maemo published the first draft version of the maemo trademark policy (before 11.5.2007) you do not need to do anything. Maemo trademark policy and maemo trademark usage guidelines are applied only to those products and services that are published after the first draft version of maemo trademark policy was published. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Public maemo repository
Hi, But you can give users the choice to select option to install from unstable repository which may contain OS upgrade packages and this practice is ordinary. We have already announced our plans to allow updated via packages instead of having to reflash the device. This feature implies the existence of a public and stable repository at some point, and we will do it for the benefit of the users. But a non-stable repository is something different: a tool for developers. The steps for us to put this maemo unstable repository in place are not ordinary at all. Create and maintain a public repository is not an ordinary task in general. There must be clear reasons to do that and a crystal clear collection of needs and requirements. The maemo stack has a non-trivial size and variety of components (i.e think of the licenses and distribution rights). Releasing a stable version implies a lot of effort already. Don't think in coding only, there is a lot more. For instance, legal checks of the code that is being shipped. Moving the software integration to the public implies a deep reorganization of parts of our process and implies also more work, no matter how you look at it. Companies accept to handle more work if they will get more benefit from the extra work invested (in fact community developers follow this very same principle most of the times). There is a potential benefit in the fact of having a maemo unstable repository, but I don't think this benefit is based on the end users accessing and using that code. Yes, real testing has a value but we could keep handling this by releasing binaries and the relevant source code by pieces, as we have done this week with the Mozilla based browser and the RTCom update. No need to mount an entire public distro for that. This unstable repository makes sense if upstream other 3rd party developers make use of it to help us and help themselves getting better code sooner optimizing the work. It also makes sense if platform and application developers want to invest their time pushing new functionality to their components, experimenting and stabilizing having the maemo platform in mind. It makes sense if thanks to this unstable context the day we release a new IT OS version the end result is better, and that day there is also a wider collection of stable applications making the most of the new improvements, documented and ready to be installed. For instance, these days at GUADEC we are seeing how many developers are taking an N800 to experiment stuff with their own code. They are using and creating bleeding edge code, and maemo unstable would be a useful context for them to innovate. Nokia wants innovation around maemo, so there is a common interest here. It would help us a lot to know about developers explaining why they would use this maemo unstable repository, how it would benefit their work and their software. There is definitely a value in power users trying fresh code, but it is not clear the effort to launch and maintain a public distro compensates this value. The elements that make valuable an unstable repository are developer quality feedback, insightful bug reports, code contributions, better sync with upstream and, at the end, innovation at a platform and application level. This is evident for your bleeding edge desktop distro of choice. It will be great to receive specific requests and proposals of developers showing that this is an evident path for maemo as well. Share your ideas and plans if we were going to this direction. Don't save details about current problems and future opportunities. The general idea is understood. The progress comes from the level of detail we can achieve through this discussion. For instance: - Context: we need to make sure that this project is useful in the wider context. A big chunk of the maemo code comes from elsewhere. How this distro relates to i.e. Debian, GNOME Mobile and other upstream projects. How it helps developers and maintainers instead of becoming just extra work or hassle. What would you do if you were in our place? We want to be good citizens and be in good relation with our neighbors. - Real cases: Now I'm doing this but with a distro I could do that, I want to do this but currently I can't because of that, etc. - Unstable, testing or what? What is the quality and expectation? Can we have the distro broken or is it expected to build at any time? and etc Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Public maemo distro
Hi Marius, :) Alright, so you want me to play evil's advocate role. Cancel? Accept! Change means work and there needs to be a reason for it. What I find to be usually missing is however a good justification of the status quo. The status quo works. The current process accomplishes its basic mission. There are things to be improved but a public maemo distro is not the only or automatic answer. I would like to see the crystal clear reasons why Nokia decided Who is in a better position to know than you? This work is mainly caused by missing the boat in the first place If the boat was the 770 launch deadline, the boat wasn't missed. In any case my question was how happy are the developers about the current boat and where do they want to sail. a distribution is a good tool to reduce gratuitous work. Yes, sure. I see you are concentrating in the code management, perhaps overlooking the energy that takes to satisfy in a *public* distro human expectations, communication, contributions. It is not difficult to have a public distro with users and contributors unhappy because the human side is not working. In fact just a few distros (from many) succeed in their mission. Failure factors are based more on human factors and context rather than efficiency of the code alone. Just make memory and look around. Quim PS: blogged about this and got another answer so far http://desdeamericaconamor.org/blog/node/378 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Mozilla based browser + brief GUADEC recap
Is there any word out on why Nokia chose Mozilla over Webcore this time? Leonid would explain this in more detail but going to the main concept: As for today, Mozilla based browsers are almost a de-facto standard in the GNOME desktop, so it is a natural choice for us to support the same browser engine. This also gives us the opportunity to align our development with the very successful Mozilla Firefox projects and communities. It makes sense and we have now an intereting horizon of potential collaboration. WebCore, WebKit and the Nokia web browser have proven to be a very good choice for S60 and the more constrained smartphone form factor. No problem with this either. More about this and other topics in Leonid's presentation in GUADEC: http://browser.garage.maemo.org/docs/guadec2007/mozilla_browser.odp Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: ANNOUNCE... (and more, please read)
Thanks Dmitry for the precision. I have just published the announcement in maemo.org: SIP support and more in the Internet communications software update for developers http://maemo.org/news/view/1184660757.html Can you check that there are not problem downloading the packages? It seems some users are getting problems just trying to download the software (while others and ourselves have no problems, weird). Let me add a message for those of you active in ITT, personal blogs and etc: In this case (and in any release we make of software under development) we encourage you to use the bugzilla component to file any bugs or issues, and this list for developers to comment any other issues. The developers of these releases are watching these reports and this list, and they answer asap. It is not an usual practice at Nokia to release software under development. We are doing this (and we want to do it more) to get deeper in the basic open source development rules: release soon release often. But as you know Nokia is a strong brand related to finished end user products. We might be questioned if releasing software under development causes indirectly confusion among Nokia customers (aka end users) rushing to install software provided by Nokia that doesn't work as they expect, or even breaks. And perhaps the problems are not even caused by Nokia but by other factors, usual issues of RD mode like conflict of dependencies with 3rd party beta software (as it looks like it's the case of the issue found yesterday by some users right after the announcement). End users read the issues but perhaps not the solution and explanation given 24h later, and in the meantime Nokia and the Internet Tablets have lost some points from their point of view. This might be expensive in the league Nokia is playing, where 'open source development' is not a key element at all, and it is probably not even quite understood. This is why we want to keep any unstable release under the maemo scope, and this is why you will see that in our announcements we won't save occasions to state that this software is under development, for developers, etc, even if it basically works. So please distribute the information as much as you want (we are really thankful about this) but insist as well on the target audience of the new software to avoid confusion and frustrated expectations. Thank you very much. Quim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dmitry Rozhkov Sent: 17 July, 2007 11:01 To: maemo-developers@maemo.org Subject: ANNOUNCE: Internet Communications Software Update for N800 *Hi, Actually, this is not bug. Apparently the guys who report this problem have also installed additional beta software which is not compatible with this update. And I suspect that it could be some packages from the OpenedHand repository, i.e. 'contacts' which depends on */evolution-data-server (=1.4.2.1.r554-3)/ through libebook. But the package evolution-data-server is deprecated in the upcoming release in favor of evolution-data-server-addressbook. So in order to try the update it would be more safer to flash the official 4.2007.26-8 image and to install the update on top of this clean image. * BR, Dmitry Quim Gil *quim.gil at nokia.com https://lists.maemo.org/mailman/listinfo/maemo-developers wrote: Hi, I just talked to Naba, currently offline. This issue is known and confirmed now. It is caused by a last minute change. We can't fix it tonight but we hope to fix it tomorrow morning asap. As you see this is really software under development, fresh meat released publicly to be shared with other developers. Please be cautious when recommending this update to end users because this is not even a beta release as Nokia understands beta releases (of end user products). Thanks for your understanding. Sorry for this bug, but at least you got the news today. More news to come soon (and if you happen to be in GUADEC come and meet the developers). / Unable to install osso-rtcom-beta // Application pacakges missing: evolution-data-server (=1.4.2.1.r554-3) / ___ 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
maemo 4.0 Chinook alpha SDK released
maemo 4.0 Chinook alpha SDK http://maemo.org/development/sdks/maemo_4-0_chinook_alpha_sdk.html maemo 4.0 Chinook API break and Nokia N800 support https://maemo.org/news/view/1184675758.html Sorry for adding only two links with further comments but I have to run if I want to be on time for Ari's keynote (where more news will be announced). We'll get back to you later on. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Mozilla based browser + brief GUADEC recap
For you to enjoy (and as some of you already know): Mozilla based browser engine available for testing http://maemo.org/news/view/1184699585.html http://maemo.org/browser This was announced today in Ari's keynote and then Leonid from the browser team gave a presentation providing all the technical details (we will upload soon all the presentations we are having at GUADEC). In between Dirk-Jan introduced the Modest email client project and its current status. No binaries to download yet but it is functional and you can either compile it or wait a bit more. Dirk-Jan commented that perhaps it will end up in Sardine. Anyway, in the last 24h we have shown three important pieces of the maemo platform that had attracted a lot of comments and discussion: browser, email client and SIP connector (+ other real time communication enhancements). Three projects based on open source code and collaboration model, developed openly now with functional versions ready to be tested and improved until reaching final product quality. In the meantime Hildon is making big steps in its way to GNOME upstream and we have published an alpha SDK release to showcase its API changes. We hope you enjoy the first impressions of the Chinook wind... What we are completing during GUADEC is not an Internet Tablet OS release but it implies also a lot of work done not only to provide better software but also to do it in the open source way. I don't do this much, but let me applaude the work of the teams involved and let me also wish them the best in their new or reshaped relationship with the community (aka you). We are Nokia but they are just people, and I can tell they have put a lot of effort and passion to bring the most exiciting results of their work. Quim PS: don't worry, we don't forget all the rest of things that can be still improved. You have seen now some of the wheels that were moving, there are still some moving and some will start moving once the Summer is left behind. We keep listening and learning. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: ANNOUNCE: Internet Communications Software Update for N800
Hi, I just talked to Naba, currently offline. This issue is known and confirmed now. It is caused by a last minute change. We can't fix it tonight but we hope to fix it tomorrow morning asap. As you see this is really software under development, fresh meat released publicly to be shared with other developers. Please be cautious when recommending this update to end users because this is not even a beta release as Nokia understands beta releases (of end user products). Thanks for your understanding. Sorry for this bug, but at least you got the news today. More news to come soon (and if you happen to be in GUADEC come and meet the developers). Unable to install osso-rtcom-beta Application pacakges missing: evolution-data-server (=1.4.2.1.r554-3) Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: NOKIA/MAEMO - SORT THIS OUT NOW
Hi, We are doing internal testing in order to determine the cause of this issue and provide a solution. There is no a conclusion so far. We acknowledge that some users are getting in trouble with some cards but in the meantime we have done intensive testing on cards and processes that haven't caused or suffered any problem. Please keep reporting at http://bugs.maemo.org/show_bug.cgi?id=1204 any details about affected cards: the specific type of card affected and the processes you were doing when you encountered the problem and before. These details are more than helpful to define the problem and fix it. We will communicate here and in the bug report any progress. Quim https://bugs.maemo.org/show_bug.cgi?id=1204 There are 35 comments against this blocker bug which is causing end users hardware failures, and there are only two pointless and unhelpful posts form a Nokia staffer. If you want to prove to us you are serious about communication, how about communicating some updates via this pretty major bug? I'm beginning to sense a degree of arrogance which means you refuse to make public comment when you fck up. I now refuse to accept the we're trying harder excuse when you don't post comment against bugs such as this. I'm really beginning to lose the faith in Nokia - so many excuses and so little progress, and nothing changes. Sort it out for Gods sake. ___ 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: [maemo-developers] Re: [maemo-users] 'Locking down' softwareinstallation
Will future updates be in place and not require a full flash? With any luck, yes. Note though that future means Diablo or later, not Chinook. We will probably start offering this functionality for testing to the maemo community during the Diablo development cycle and we will push it as official (recommended on top of reflashing) when it's ready for mainstream usage. This is the current plan, and is an evolution of the improvements in the application manager and the reflashing process that are being development for Chinook. Chinook will offer as well backup of installed applications (see the enhancement request http://bugs.maemo.org/show_bug.cgi?id=647 ), but this means that your upgrade from the current IT OS to the Chinook version will be still done as today, reflashing and reinstalling manually. So yes, a lot of improvement is expected in the software update area but please be patient. I'm sorry if I gave the impression that upgrading via APT was something to come immediately (someone expected the last update to be working already with an APT alternative to reflashing). Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Eclipse the IDEs
Hi Ian, genealogy. However, as soon as we jump to traditional mobile, Windows based or commercial software development IDEs are a must What do you mean by this?How is 'traditional mobile' so different from any other sort of development that we *must* use commercial software? No, what I mean is: * We want to expand the maemo offer to developers coming from - mobile phone / smartphone software development. - Software development for MS Windows. - Commercial software development for the desktop. * We want to offer them development tools (like the ones) they are used to work with. Eclipse is the most obvious step at this point. * Needless to say, current maemo developers happy with command-line GNU tools, emacs, vim, etc don't need to bother about this. maemo is a Linux based platform and we will keep supporting the native and usual development tools for this environment. * I didn't write anywhere that you *must* use commercial software to develop anything. :) Note that Eclipse is open source software and not commercial. I have been using pyphantom recently and I think it is a great (but pretty new IDE) that definitely deserves some support https://garage.maemo.org/projects/pyphantom/ Looking the list of admins it seems that we are already providing some support to this pre-alpha software. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: extras packages for sardine
Hi Murray, We will have a more solid answer to this question in few weeks, around GUADEC time. We are still working on some plans and feasibility analysis to see how can we help best developers having their applications ready when a new release comes. In the meantime let me say that we are planning to release an early alpha SDK for Chinook plus a proper beta. The alpha's core mission will be to stress the API changes so developers can see where and how their Bora applications break. It won't be ready for real porting/developing yet, hence the alpha tag. Proper porting and developing work should be feasible later on when we realease the beta SDK. Of course Sardine is currently a good channel to follow the Chinook development but it is also limited to a set of APIs (remarkably Hildon, GTK+ and the desktop related components). We are also thinking of bringing the current Sardine to a next step. Quim Is this possible yet? Assuming that the sardine repository is the future Maemo Chinook version, I will want to upload and test packages before Maemo Chinook is actually released. On Thu, 2006-11-09 at 23:18 +0100, Murray Cumming wrote: Is there any way I can upload extras (previously contrib, from garage.maemo.org projects) packages for use with sardine, instead of just mistral? This would help us to make sure our packages work with the latest code, before it is actually released as stable, and help us to adapt to any changes. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Summer of Code update?
Hi, my fault I haven't pushed any kind of cooridnation or update around the maemo participation in the Google Summer of Code. I confess not feeling absolutely guilty because of this since from the first day I have been asking for a community coordinator after having accomplished my mission of getting maemo in the SoC but... So please, could the students and mentors send a brief update about the status of their projects? Also, Google is pestering me because some of you owe them some kind of bureaucratic papers, so I'm pestering you: please take out maemo from the blak list. Thkyou. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Eclipse the IDEs
Keeping the roadmapping/planing track around the developer platform. Eclipse, and the IDE approach in general. The developer audience of maemo will increase if the platform and of course the tablets are attractive. Command line based tools are the natural context for maemo development due to the obvious GNU/Linux, Debian, GTK+ etc genealogy. However, as soon as we jump to traditional mobile, Windows based or commercial software development IDEs are a must and Eclipse seems to be the environment most developers are used to in our wider (potential) context. If you have other IDE preferences/plans, pleas share. There is some Eclipse related interest and effort going on and, again, some coordination / communication between the interested parts would be helpful to figure out what to promote and support. https://garage.maemo.org/projects/pluthon/ and http://www.cs.tut.fi/~laika/ are different projects based on Eclipse with different goals. If you know more, please share. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
maemo through VMware
It would be good to have al the maemo-through-VMware interested focused in a single direction. There is interest enough to make this happen in a reliable way but some coordination is needed. Nokia is not in the best position to lead this even if we support the idea and want to see it happening. The reason is that Nokia checks all the software released in their products and offers a guarantee on them. Perhaps we can circunvent rules (to be analyzed) but the default setting would imply that Nokia would be stamping a seal on a whole Ubuntu distribution (read hundreds of packages) which is totally out of the scope (and feasibility). We are happy seeing an official maemo release inside a VMware envelop. If it's proven to work and be regularly maintained and supported we would give it officious treatment. With identified and reliable speakers we could help having the new versions in good shape right after a new maemo release. It looks like all the ingredients are present already in the maemo community. With some images already out there, a placeholder like https://garage.maemo.org/projects/maemovmware/ , contributors identified, some coordination and an agreed plan the VMware support present in the http://maemo.org/intro/roadmap.html could be pushed forward with a (community) tag and our explicit backing. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Easier way to upload debians to extras repository needed
Enhancement request added to http://maemo.org/intro/roadmap.html (Wishlist - Development). I think we all agree on the problem (developers uploading their packages elsewhere because of the extras upload process). We still don't agree in the solution, though. As soon as there is a consensus we will move this feature from wishlist to roadmap. At the moment there is way too many repositories. I believe this is because it is too hard to upload your creation to the extras repository. Quim PS: please keep filing enhancement requests to the development platform. We *really* want to pick the good ideascoming from the community (and not from us) and pushing them through the official process of planning and development. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Features to improve the platform
You know about http://maemo.org/intro/roadmap.html We have been putting more flesh into it at a platform level. We will keep making each entry a link describing details about the feature and facilitating focused discussion around it. At the end of the roadmap page there are instruction to submit your own feature requests to be, if approved, roadmapped and developed. We really want to see this process happening. There are some platform related feature requests submitted in bugzilla, but most of them are about end user features. We would like to improve the maemo offer for developers by implementing good and well formulated ideas received from the community. So please, if you have ideas for improvement have a look to the procedure in the roadmap page and file our feature requests in bugzilla. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
maemo.org performance (was RE: Features to improve the platform)
Hi Neil, Quim - If you want to improve the Maemo platform, stop messing about in public with maemo.org Discussing new features has no relation with fixing maemo.org in terms of tasks or people responsible. I fully agree that the maemo platform will go nowhere without a solid web performance but I don't see why we should stop the rest of processes until the web issues have been fixed. btw, perhaps Ferenc wants to report more but we have fixed a lot of website bugs. We have also spent a lot of time trying to solve the server issues, starting fixing small things, then the bigger ones and finally renewing/reorganizing the web infrastructure completely - a process going on as we speak. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: Introduction
Hi Tollef, good to see you here. We are looking forward to strenghthen this collaboration. I met Jono last week in LinuxTag also to tell him 'Hopefully, we can work well together'. From our point of view you the Intel team working on MID are now like maemo developers, your wishes are... at least wishlist items in our roadmap. ;) Is anybody (you?) going to blog about the Ubuntu Mobile progress? If the blog has a specific category for mobile stuff it will be a honor/pleasure to aggregate it to planet maemo, a simple way to know about the progress and stay in touch with the maemo community. Also, see you in GUADEC? Hi, I thought it would be appropriate for me to introduce myself. I work for Canonical as the technical lead on Ubuntu Mobile. We are currently working on bringing Hildon and the osso-* libraries into Ubuntu proper. https://wiki.ubuntu.com/MobileAndEmbedded has a bit more information. Hopefully, we can work well together, and I believe most of our patches should be interesting for you as well. https://code.launchpad.net/~ubuntu-mobile/ has our branches where we have made changes and links to both ViewCVS-like functionality as well as the Bazaar branches themselves. If you have any questions, do feel free to ask. :-) -- Tollef Fog Heen ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: See you in LinuxTag?
Dear developers, please have a look at LinuxTag slides with some maemo novelties http://desdeamericaconamor.org/blog/node/369 I will be writing more about each new feature, if you have questions or specific interests just shot and I will prioritize. Java lovers, after seeing, listening and chatting with some very interesting guys in LinuxTag I think the best thing you can do is to hang around http://www.jalimo.org and start contributing there. We all agreed that [EMAIL PROTECTED] needs less requests and more code (or something like that). :) Fliying back to Helsinki. Berlin is always an exceptional city. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
See you in LinuxTag?
I'm flying to Berlin this morning. If you happen to be in Linuxtag let's meet up. I will be around the GNOME/GMAE stand and in today's dinner. Tomorrow there are 90 minutes of maemo report and QA: Nokia and maemo in the new GNOME mobile context http://www.linuxtag.org/2007/en/conf/events/vp-freitag/details.html?talk id=10 The objective of this session is to explain where maemo sits today and where we want to bring it as an open development platform for Internet centric mobile devices. In order to achieve that we need to have a common understanding of what is Nokia's role here, as well as the role of the very diverse maemo community and of course the GNOME Mobile context. I hope to get many of the normal and tough questions we are getting in places like this mailing list, your blogs, InternetTabletTalk, etc. We have been working on the elements of a renewed strategy and they are ready now to be announced and explained. I'm planning to record the session in video. Nokia mobile phones make it so easy nowadays. ;) I will only need a hand (literally): someone to actually shoot the video. The let's see then how to make the video available to everybody. I don't know if 9 chuncks of YouTube would work. Sometimes I think of asking the Fluendo crew about how to setup a basic streaming infrastructure for maemo (and then republish in YouTube the four stars content, if it makes sense). Apart from this I will upload the presentation containing all the core elements, so you know as soon as the session is completed in Berlin. A little more at http://desdeamericaconamor.org/blog/node/368 Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: about SoC organization reward
Using SoC money to sponsor trips to GUADEC sounds very good. The best proposal (IMHO) I have heard so far. What are the thoughts of the other SoC students? Rest of people? Quim Well, I was looking at the quite interesting GUADEC 2007 programme and thought how nice it would be to attend (and how impossible it is with my current budget)... So, here's my proposal: Give travel stipends upon request to maemo community members who'd like to go to a maemo-related conference during this year. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: IT OS 2007 Hacker edition
is there any progress? Where should we discuss issues/suggestions related to this? https://garage.maemo.org/projects/os2007on770/ You don't need to ask permission to push there. :) Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: maemo.org update + call to bugzilla expertise
We have started discussing the reorganization of products and components in bugzilla. The first step is to put in shape product Website: https://bugs.maemo.org/show_bug.cgi?id=1414 Once this is completed we will make firther steps until we all are happy with bugzilla's content structure. In the meantime we keep looking for the bugzilla hacker that will make bugs.maemo.org a nice place to live. ;) Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: maemo.org update + call to bugzilla expertise
Ok. A quick note on this: I don't know if you already run version 2.18 or newer, as the bugzilla doesn't advertize it... It is 2.22, the latest vesrion in Debian stable. Agreed, it is important to reopen maemo's bugzilla. The requirement is though that no email addresses are shown. Let's follow this at Bugzilla shouldn't show emails ever https://bugs.maemo.org/show_bug.cgi?id=1383 Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Garage project news (was RE: Plugins available for Maemo Claws-mail 2.9.2-1)
Hi, As you have seen now the http://maemo.org homepage features the news coming from http://garage.maemo.org, that are written directly by the project maintainers. Users can subscribe to feeds and be the first ones to know. Garage project maintainers, please make sure all your relevant updates are reflected there with as much detail as possible. The GForge interface is not the best in the world to publish news and receive feedback but it does both. As usual, please submit feature requests if you miss something. Sending emails to the mailing lists for new releases can't be considered off topic but with 200 projects in Garage (and growing) it is clear that it's not a sustainable practice in the mid term. Thanks for your understanding (and yes, specifically Claws mail project tends to publish news - I just needed an example to raise this topic). :) Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: maemo.org update + call to bugzilla expertise
I assume you don't mean bugzilla spammers Sorry, I meant spambots gathering email addresses. In our default bugzilla setup email addresses were exposed. Some pages accessible publicly offered bug listings with dozens of addresses. Since we were (and we are) busy with the new website we decided to cut completely the access to anonymous users. Personally I believe this is a bad solution for an issue tracking system: We are not happy with bugzilla closed. We simply don't want to expose users email addresses. If someone knows a good and quick fix/patch please share it. As soon as bugzilla is not showing email addresses we will reopen it. The fact that new users may not know that their email address will be publicly viewable is a problem It's not about users knowing or not knowing. Bugzilla or any other web tool shouldn't expose addresses at all, or at least not in a way that spiders can process. No integration is actually a good thing at the moment, as many garage accounts just do not work on the core website Obviously we will fix bugs first and then we will go for new features. It would be nice to know if there is any progress on this Not according to https://maemo.org/bugzilla/show_bug.cgi?id=1152 . Ferenc is basically fixing stuff full time. Even if this is an important issue there are other things that are more broken. Sorry about that. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: Bugzilla brokan?
For example, whenever I receive an update on one of my bug reports, the URL looks something like this: Bug known, working on it: https://maemo.org/bugzilla/show_bug.cgi?id=1365 Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
maemo.org update + call to bugzilla expertise
Hi, - The new maemo.org seems to be well received. Still some rough edges and thingies to fine tune. Different opinions about the fixed width. Thanks for your bugs and improvement suggestions submitted in bugzilla. - Do not hesitate filing more reports even if they are minor things or matter of taste. We are happy agreeing with you the next moves. We are working on the fixes since the very minute the site was launch and we have just agreed to put some more resources to help fixing these bugs. - About maemo Bugzilla, the tool itself. We have upgraded the software and integrated the design to the rest of the site. We have basically closed the access to non-registered users to avoid spammers even if we agree it's not the best option. We will integrate soon the users so same login will apply to the core website, Garage and bugzilla. But there is more. Our bugzilla still needs lots of love and we want to put a remedy. Please file any improvement ideas to https://maemo.org/bugzilla/enter_bug.cgi?product=bugzilla . We are not talking now about the content (Jake co are taking care of this). Not even about the products components structure, that we need to discuss in order to make it more consistent and useful. The core topic is the tool itself, the user inteface, the features missing... My personal approach to this is to have anything good available in the bugzillas out there and useful for our case. What can I say, I'm in love with http://bugzilla.gnome.org and Olav aka bkor is in my (quite restrictive) Olympus of Free Software Heroes. We want ideas to have something as good as that, and perhaps also ideas to have something better we can try and contribute back. Once we have a plan we will need the expertise, or perhaps we need the expertise first and then the plan...? Anyway, the first step is your feedback. You are the first ones that need to be happy with that tool. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: maemo.org update + call to bugzilla expertise
Ahem, forgot one important big, the one I'm directly responsible of :P WEB CONTENT - Fixing broken content, links, etc. The migration had its consequences and we are fighting at it. We have asked the Midgard guys (btw: applause please) to put someone working specifically on this family of bugs. - Improving existing non-documentation pages and creating the missing ones. Again, Nemein will provide a good writer to go through these asap. - Improving official documentation. The new CMS allows maemo developers more flexibility to go and work on the content, process that has already started. In the meantime we are trying to stablish clear roles and responsibilities, and surprise-surprise in June a documentation manager will (finally!) join the team. Ave. - Usability, layout CSS stuff: we are paying someone tbd to go through the current issues and leave a smooth site for your thumbs. - Graphics + look feel, hopefully we will have some time available from one of these tango-rock stars so we can work in nice useful visual information. We need to explain certain things with graphics and some extra beauty never harms. You should see and enjoy the changes starting last week and keeping the speed at least until the Summer holidays (people like Ferenc deserve). Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: A Pitch for making SAMBA Server a core part of the N800 OS
Hi, Having SMB/CIFS _client_ functionality probably would be useful. fyi SAMBA is in the (now official) roadmap: http://maemo.org/intro/roadmap.html We need to provide more details about the features mentioned in this roadmap. Where to start? File a feature request [1} if you want more details about a specific featured listed there (as roadmap, I would expect the interested parties in the community to take on the features under Wishlist). [1] https://maemo.org/bugzilla/enter_bug.cgi?product=websitecomponent=gener al (have you seen already how nice the bug reports look now?) :) Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: YouTube and Planet Maemo
Hi, with large pictures and it makes the articles quite hard to read. Eliminating the goofy icon representing people talking, and getting rid of the wasteful navigation column, would more than double the available space for the columns on the N800, not to mention a large- screen web browser. I agree the Planet needs still some tweaking to solve some details and work fine. Agreed also that the tablets are the default test case, a tough one compared to the average laptop or desktop computer. Said that, the maemo planet doesn't offer big differences in width and structure than other planets, starting with the original Planet GNOME. The average Wordpress / Blogger / etc post fits in the current planet. Examples of blog entries not fitting would be appreciated so we can agree whether it's the Planet's fault or just an excess of the blog author (who can do whatever she wants with her blog, true). Offer a full width of almost 800 pixels is not a warranty of usability either. In fact it is damn tough to read lines so wide. This is why many sites are offering fixed width at max 800px no matter that nowadays the screens can double that. Which is very useful for the tablets usability. I definitely would keep the hackergotchi. Not that sure about the navigation column, but not for the planet. It causes trouble as it is in other parts of the website like the deep pages of documentation. But perhaps it is just the behaviour of the navigation what needs to be fixed... There are sites like http://ruby-lang.org that do just great with a right column and fixed width. Perhaps what we need to do is keep the current template and work on the details to make it look and behave much better. btw you are invited to the discussion at the list where the web decisions are taken: Kill the vertical navigation? https://garage.maemo.org/pipermail/maemo2midgard-discussion/2007-May/000 131.html Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: Documenting maemo pearls (was Re: N800 Video playback)
Don't kill the messenger! But yeah, always happy to answer direct questions. Disadvantage is that it becomes lost in the list archive. This is an old problem communication science solved centuries ago: generally you have those generating information and those collecting it. Asking the sources to organize information is many times as useless as asking the documenters to generate new data. I keep thinking the right approach in our case is: - maemo.org should provide the right infrastructure to document easily (getting there). - the maemo team should make sure that all the essential information reaches the official documentation (still a while to get there). - the maemo community could help organizing themselves in wiki-based collaboration and pointing essential information missing in the official documentation (up to you, tell us where we can help). I keep insisting in a clear separation between official and community documentation. Don't get me wrong, I think the quality and usefulness of community docs can match and outsmart official documentation, in maemo and in any software project (in fact in *any* type of project). But think on the zillions of newcomers we want to welcome: most of them are looking for a single, comprehensive and reliable source of information, structured in a way that makes sense in order to find what I'm looking for. These are elements required in good quality official documentation, while these same elements can kill community workflow (generally quite spontaneous) if not handled properly. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: No more 770 bug activity?
Quim: Maybe you could put on the roadmap an item to better define the relationship and goals for at least the Maemo platform, but preferrably a general goal for the IT200X as well. No need to put this in the roadmap since it is our current ToDo. I'm willing to complete this task by June 1st. Hopefully that day we will show a revised picture that makes sense for everybody, including all the pieces of the puzzle we are discussing these days, and the wider context. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 3.2007.10-7 - Detailed change log?
Did you (or anyone else) manage to make any progress on a changelog for 3.2007.10-7? I have started the internal discussion with the aim of having a changelog linking to maemo's bugzilla being published together with the next IT OS release notes. And improve from that point in next releases. Still a proposal, but looking good. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
maemo in the wider picture (was RE: Intel's Internet Mobile Device)
I may be being over-dramatic Drama is a big gender itself, no need to overdo it. ;) The discussion about the maemo platform is getting increasingly interesting but we all need to assimilate a wider context in order to push it to higher levels. As an example, here is some context: http://foundation.gnome.org/ You see some familiar logos there. In fact what matters are not the logos in this web page, but what is behind thi space for collaboration. GNOME is just an example, there are other. Never underestimate the importance of this. Source code is important, but no more than the people creating it. If you evaluate the maemo project only looking at the source code you will miss part of the picture. Someone wrote few days ago about the somewhat closed community in which we're operating. Now this is perhaps too dramatic. I hope you agree that we are doing not-bad in terms of participation and collaboration in the upstream context, at several levels. Perhaps we just need more catchy t-shirts so you notice better. ;) Quim PS: btw, hi from Santa Clara CA, where something is going on: http://perkypants.org/blog/2007/04/16/major-gnome-announcement-next-thur sday/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: SoC: 5 preliminary slots
My proposal/plans are available at http://maemo.org/maemowiki/GeoClue Thanks! I know there's still six weeks until the official start and some students may actually have busy schedules until that point, but it can't hurt to start communicating early... These previous weeks are there *exactly* to start crating the infrastructure, get the students familiar with the project, the community and the tools. This way once the SoC projects officially start everybody and everything is in place, with some inertia already. Students and mentors, can you please get in touch create your garage projects? Maybe the Japanese/Chinese project can be hosted in the current garage project for CJK support, as you prefer. Quim ___ maemo-developers mailing list [EMAIL PROTECTED] https://maemo.org/mailman/listinfo/maemo-developers
RE: SoC: 5 preliminary slots
It looks like we are getting 4 slots, yes: - Ruby Maemo Bindings - GeoClue for Maemo - Smoove - Instant Desktop Migration Suite - Japanese/Chinese handwriting recognition on Maemo Time to sleep here, tomorrow we will know for sure. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
SoC: 5 preliminary slots
Google has allocated 5 preliminary slots for the maemo project. We might still end up getting less than these, but definitely not more. We need to move fast now to make sure that the top 5 ranked proposals are the ones we want to promote. Google will make final decisions at the end of Tuesday 10. Proposal for next steps below. Discuss as much as you want... today. I will apply changes in the (European) night. 1 - Keep the top 10 proposals and mark as Ineligible all the rest. 2 - Community mentors that haven't taken part at all in ranks/mentorship until now will be also removed. 3 - Some of these to 10 projects have currently a backup mentor temporary assigned. Last chance for community mentors to claim ownership of these. 4 - Community mentors make a second round of ranks to these 10 projects. Backup mentors (all Nokia employees) don't vote in this second round. I might add/take points as administrator, only in the case a community mentor has ranked 3 or more times (by accident or not). This way we will get the desired result: a proper rank of projects based on the community will with mentorship assigned in a way that community mentors have a preference but backup mentors can assist wherever the community has decided it is useful. The current top 10: Note that Google ranks projects with mentor on top of the rest even if they have less points. 1. Ruby Maemo Bindings - Student Michael M. Martin - Mentor Jay Phillips 2. GeoClue for Maemo - Jussi Kukkonen - Henri Bergius 3. Smoove - Instant Desktop Migration Suite - Paolo Durante - William Maddler 4. Japanese/Chinese handwriting recognition on Maemo - Mathieu Blondel - Makoto Sugano (backup) 5. Last.fm radio player - Alberto García - Xan López Saborido (backup) 6. Improve the phoneME JVM, to integrate well with Maemo and GPE enviroments - Clemens Eisserer - Johannes Eickhold 7. Dasher via Maemo Device as Keyboard for PC - Aaron Westerdale - Luca De Cicco 8. Geolocation-based Transit Maps - James Addison - Andrew J Turner 9. VPN Integration that Just Works - Kyle Ambroff - still no mentor 10. Enterprise-class cryptographic filesystem - Arnaud Jacques Elie Germis - still no mentor Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 5 preliminary slots
Some mentors have started moving piece, let's go ahead with the proposal. 1 - Keep the top 10 proposals and mark as Ineligible all the rest. Done. Courtesy email sent to the discarded proposals, trying tp summariza the reasons given by mentors not to support them. 2 - Community mentors that haven't taken part at all in ranks/mentorship until now will be also removed. Done. 3 - Some of these to 10 projects have currently a backup mentor temporary assigned. Last chance for community mentors to claim ownership of these. Taking note of the comments received, the changes will be done (if needed) once it's clear what are the top 5 projects. 4 - Community mentors make a second round of ranks to these 10 projects. Backup mentors (all Nokia employees) don't vote in this second round. Someone started already. The mentors with ranking rights are: Andrew J Turner Henri Bergius Jay Phillips Johannes Eickhold Luca De Cicco Robert McQueen William Maddler It would be great if you could go (again) through all of the 10 remaining proposals ranking them from +4 to -2. This way we will get more clearer differences between scores. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 5 preliminary slots
Are you asking to double vote? Yes, like in some democratic systems: first round with all candidates and final round concentrating in the most supported candidates. The difference here is that the second round doesn't start from scratch, since the previous ranks are still there. But still. Only some of you ranked all these top 10 and in this second round there is no backup mentor input (and some backup mentors voted in these proposals). For these reasons we might still see changes in the top 5. Specially the 5th position seems to be quite unclear. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 0xFFFF: GPL-licensed flasher for n770 and n800
The past week I released a gpl-licensed flasher for both Nokia Internet Tablets. I haven't tried it yet but only for the idea and the release: congratulations, cool. Flasher is one of those closed components with openness wheels currently moving. Good to see movement in the same direction. Today you have been faster and tomorrow we may end up sharing contributions and improvements. I'm planning to implement a GTK+ frontend for flashing and backuping the device in a user-friendly way. Yeah, good point. Quim PS: May I ask... any reason not to use garage.maemo.org? We want to keep improving this service and any feedback is appreciated. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: hunting for Linux developer
- MAEMO platform - porting applications to MAEMO No, I don't have the skills to apply. ;) This email hits the list precisely when I was thinking whether would be useful/acceptable to have a page in maemo.org for job opportunities around maemo. Nokia is offering jobs regularly but getting visibility for these positions available is more difficult than expected (at leats by me). In the meantime I wonder if maemo.org visitors are looking for a job matching those positions... Nokia is not the only one hiring. This email is a good example. If the maemo platform is successful we will see more of these. maemo contributors, potential employers and employees: what do you think? Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: H/W 3D on the N800
Can somebody from Nokia confirm that 3D is an unwanted feature on the N800 and that it will not be added soon? This is not a tendencious question, is it? :) 3D is not an unwanted feature, since (as a principle) we want to have all the features making the tablets excel in Internet and multimedia experiences. However, due to various factors the equation 3D + N800 + Soon = Uneasy. Specially if by soon you really mean soon. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: hunting for Linux developer
great idea as long as someone manages the list to remove obsolescent postings. I guess we could introduce something like a 1 month period for each entry. After that period the entry would be automatically unpublished. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
maemo.org homepage mockup
http://www.flickr.com/photos/tigert/447139716/ Feedback appreciated. This homepage needs to be useful first of all to you. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: No more 770 bug activity?
I'm not going to get into details about the packages mentioned, but as a general answer... So why on earth was it ever closed-source? As mentioned in my previous email, project management issues had a big weight on this kind of decisions. Objectively, when you are a huge company and you need to deliver quickly software matching commercial quality standards it is probably faster, cheaper and easier to deliver it as closed source. Open source is more efficient in the beta stage and in the mid term, agreed. The UI is different, it was decided to have it closed in order to protect it from changes and deviations out of the control of the project. Nowadays the history and context is a bit different, specially thanks to the success of the maemo, IT OS and tablets projects. The wheels are moving, as Kimmo says. Some things take some time, I insist. :) And now, back to the wheels. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: No more 770 bug activity?
Hi, Is there any chance to have a community maintained release? If I remember correctly some drivers are missing to get there, any chance to get the open sourced? From a Nokia 770 customer point of view, any solution around this device needs to come sooner than later, since devices get old quite fast nowadays. From a Nokia Corporation perspective open sourcing components might be a slow process even if all the parties involved have a clear and common wish opening a specific source code. If we are talking about hardware drivers, the process might be *really* slow. Therefore, there are little chances that the solution for 770 customers comes from Nokia opensourcing components, really. The current hacker edition looks like the best candidate to become a more continued solution. Some people here have got a deep look at it. What do you think? On the other hand, it would be useful for everybody to highlight what are the hot zones, what theoric solutions can be applied, which ones can be discarded and who is responsible of what. Or in other words: what 770 users are *really* missing today and how this could be brought to the device. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Final (?) list of SoC projects
SoC mentor? Read this through! http://maemo.org/maemowiki/GoogleSoC2007 updated with the latest information. We have received some projects after the deadline, I believe that redirected from other projects or Google's pool. I have marked two as uneligible since they contained no project proposals, only introduction of students willing to help (they have been pointed to maemo.org mailing lists and garage projects, where a lot of help is needed). We have some proposals that seem to overlap or be very similar, around location and PC-device transfers. I'd say the average quality of the proposals are good, some students have put a lot of effort in them already. The list of projects and some comments, in no special order. - Dasher via Maemo Device as Keyboard for PC This one might drop if it's confirmed that a Dasher port already exists. Any links? - IMAP-related enhancements to osso-email We have told this student that in fact most of the development hotness is currently happening around http://modest.garage.maemo.org/ , inviting him to refactor his proposal accordingly. - Japanese/Chinese handwriting recognition on Maemo This student requested mentorship to Makoto Sugano, who is Nokia employee but also maintainer in his free time of https://garage.maemo.org/projects/maemocjk/. The project looks good and it's well formulated. AFAIK there are no other mentors able to even read basic Chinese/Japanese. Makoto would be happy mentoring this project. Any objections? Note that Makoto's job in Nokia has nothing to do with Chinese/Japanese implementation or any kind of L10n/i18n. - Last.fm radio player Xan (Nokia employee and Last.fm fan) has requested mentorship of this project and I have reminded him the backup policy. If a community mentor wants to pick this one s/he will have preference. Otherwise we can keep Xan and then the rest of mentors value the appropiateness of the combo when ranking the project. The proposal itself is well formulated. - Improve the phoneME JVM, to integrate well with Maemo and GPE enviroments - Geolocation-based Transit Maps - 'Duality': Internet-based, PC-to-device-to-PC file transfer - Ocaml Maemo - WiFi /maemowiki/WiFi -based Localization - Application in Mono to synchronize gpe-calendar with google calendar - Easy wireless interaction of Maemo-devices and pc's - Smoove - Instant Desktop Migration Suite - Ruby Maemo Bindings - Placemarking program for Nokia 770 and N800 - DBAssistant - SQL Database builder and data entry *** SoC MENTORS *** NOW it's time to review the applications, rank them, and offer yourself to mentor your preferred. Deadline: this week (it can be done in 1-2 hours). Please post your comments in all the projects (public/private) unless you have really nothing to say. You should be active specially if you are applying as mentor of a project. As said in a previous email, we have approved all mentors without making any reliability check. But if you are not reliable to post some SoC comments it is reasonable to think that you might be not the perfect candidate for bigger SoC challenges. ;) We haven't discussed much the participation of the backup mentors in the comments and ranks. Is it worth to discuss now? I would say that it is good that you take part as well since you are experienced maemo developers. A way in between could be to let community mentors to push the preferred projects while concentrating the attention stopping the weakest options (duplicate work with existing projects, potential difficulties in the execution and so on). In practice this would mean that backup mentors wouldn't vote +4 and +2 as much as the rest of values (+1, -1, -2 and N/A). This is no strong policy and not even a strong recommendation, just a thought. Act according to your own beliefs. :) Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: 3.2007.10-7 - Detailed change log?
Would it be possible to provide a detailed change log for 3.2007.10-7, ideally cross-referenced with the public Bugzilla so that we (the users) known which of those bugs we have raised have been addressed? Good question. I will try to answer officially as soon as possible. I mean, the answer depends not only on the will to publish more details but also on some improvements in the way we currently work. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: Summer Of Code Proposal: Wifi Localization
Hi Guy, I have an idea for a project for the Google Summer of Code. It's not really mentioned on the ideas-page so I'll present it here first: The maemo ideas page has a mention to Location related projects. - is this project suitable for maemo? As mentioned, location is one of our preferred chapters. If your idea implies a development based on maemo on this topic, your proposal is on topic. Note that this doesn't mean any acceptance, since this will depend on the other projects presented and the cut made by Google. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: SoC proposal - dasher as bluetooth keyboard
A student has submitted a proposal about this: Dasher via Maemo Device as Keyboard for PC, by Aaron Westerdale FYI these are the other 3 project proposals received: - 'Duality': Internet-based, PC-to-device-to-PC file transfer, by Andrew Godwin - Improve the phoneME JVM, to integrate well with Maemo and GPE enviroments, by Clemens Eisserer - Geolocation-based Transit Maps, by James Addison I'll publish the abstracts as soon as normality comes back to the wikis. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: SoC proposal - dasher as bluetooth keyboard
Perhaps promoting this idea in the dasher list(s?) would help finding a student interested? PS: We got a second proposal. If the first one was about Java, the second one is about geolocation. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] RE: Multiple Choice Response Form (Re: How to learn DSP development for N800?)
Hi, beyond the DSP thing... I also know that the open source community is a group of grumpy people with questionable social skills, so you've been flamed to hell and back on this list Your perception. :) I find this list is keeping high standards in terms of quality of discussion. and you have lost interest in replying to the ungrateful crackpots writing here... ;-) It's not lack of interest. Some things just need some time. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Three hires around maemo
Nokia is hiring and the 3 job positions are related to the development platform. See http://desdeamericaconamor.org/blog/node/331 I don't feel like doing HR promotion in this list, but since many people subscribed here are potential job candidates... I tought you would like to know. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Maemo roadmap, SDK improvements...
Hi Sean, respect. I think on part of the challenge is the perception versus the intention. This is a very good point. We can improve clarifying our intentions and communicating them. One problem here is the novelty of the process in many senses: we are sharing a project and a context that is moving and evolving fast. This is part of the fun that makes all of us enjoy and share work and discussion. But it's not easy to find always a consistent and suitable combination of factors involving open source community dynamics, corporate software development, hardware design and manufacturing, third party developers, business results, gift economy, market competitors, knowledge sharing, NDAs, GPLs, EUSAs, APIs... and a lot of different stakeholders with a wide range of interests. We at Nokia try to do our best, and the maemo community is doing great. I hope small steps like this thread help us progressing in the right direction and establishing a clear and flourishing relationship around maemo, equally exciting for everyone. Thank you for the feedback in this thread. Keep it open as long as you want. It helps drawing our roadmap, and our intentions. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Kernel guide for maemo (and other devel docs)
This is a call to kernel lovers, http://maemo.org/platform/docs/howtos/howto_kernel_guide_bora.html Any suggestions to improve this documentation? If you see a clear gap please tell us. PS: If you know about a clear gap in our developer documentation, tell us as well. Yes, I know there has been a lot of feedback in this sense. Links to archived emails or bug reports are also welcome, if you don't mind. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] New list spin-off?
Thanks for the feedback. Still not 100 responses ;) but definitely we have a wider opinion now. New iteration: - No new list created. - Current lists are not renamed. - Flags in the subject are wiped out. - Reply-To is kept as it is. - maemo-developers is for... developers hacking either applications or the platform, plus any misc topic around the development platform. Community moderation is encouraged to ensure the list stays on topic. - maemo-users is for power users trying to use / tweak / install stuff that is not officially supported by Nokia but relies in the maemo platform. Community moderation is encouraged to ensure the list stays on topic. - Additional active lists with a specialized development focus hosted in maemo's Garage are advertised at http://maemo.org/community/mailing-lists.html - It is out of the scope of maemo.org to provide support to Internet Tablet pure users. There is the official documentation, there is Tableteer, there is also the unofficial but very useful http://www.internettablettalk.com/ forum. We reckon there is a gap here but our focus in maemo is development and innovation. We won't punish ;) pure end-users asking in maemo-users, but answering those questions is not a priority for the maemo community. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] New list spin-off?
New iteration: [EMAIL PROTECTED] Renamed maemo-developers@maemo.org, no change in subscribers. [EMAIL PROTECTED] New list, interested people need to join. [EMAIL PROTECTED] Renamed maemo-users@maemo.org, no change in subscribers. About the flags, if someone wants to come up with a schort schema, great. I've tried several option but they get either too abstract or too long. Question: aren't there ways to filter appropriately the emails without relying on the flags? If so we could get rid completely of them. What is true is that the current flags are difficulting subject readability in 800px width resolution screens. PS: Re-reading this thread and also http://www.maemopeople.org/index.php/keesj/2007/02/02/developers_develop ers_developers I have second thoughts about the convenience of this proposal. I mean, I think it definitely makes sense and will improve things here but if this is not a shared thought the better (and the easiest) is to leave the lists as they are. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] New list spin-off?
If you don't have dev or developer somewhere in those developer list names, they will be bothered with user questions, and those users will then be dissatisfied with being sent away. Descriptions aren't enough. I was waiting some kind of concept approval before going into wording. Let's see if this makes sense (at least to Ferenc, our dear server-side admin): [EMAIL PROTECTED] (renamed maemo-developers@maemo.org, no change in subscribers) [EMAIL PROTECTED] (new list, interested people need to join) [EMAIL PROTECTED] (renamed maemo-users@maemo.org, no change in subscribers) About the flags in the email subject, is this a problem? I can live with/without them, no strong opinion here. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Closing the N800 developer device program
fyi We will close the N800 developer device program in 24h. We will be still reading and processing requests until then. The less we know you the more you should explain has proven to be a useful principle. There are still few codes available, specially for the US. From that point we will just keep the channel open to support those of you having trouble, although at this point the online shops seem to be dealing with the issues case by case. Yes, there is still one open question at https://maemo.org/maemowiki/N800DeveloperDeviceProgram - we will answer that one, give us some time. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] New list spin-off?
Do you like the this idea, then? - platform (current maemo-developers) - applications (new list) - power users (current maemo-users) Pure end users are currently out of our scope, although we wouldn't stop them in the power users list if they find it and are brave to ask. Otherwise there is InternetTabletTalk today, let's see if other interactive spaces around the Nokia's Internet Tablets are created. The ruleset might be, then: - If what you're trying to do involves the platform, it's maemo-developers@ - If what you're trying to do involves scratchbox, it's maemo-appdev@ - If what you're trying to do involves hacks on the device (such as using xterm), it's maemo-users@ - Otherwise, it's [EMAIL PROTECTED] or whatever. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] New list spin-off?
This list is growing and sometimes (like this month) is difficult to follow. What about finding a specific development area that could be discussed in a separate list, leveraging the weight of this one? Contributors interested in that area could collaborate better. A list specialized in a specific topic would be also easier to join and follow for the [EMAIL PROTECTED] developer working on that topic. Please have your say. And now some numbers for the joy of statistics: looking at http://maemo.org/pipermail/maemo-developers/ we can see that on December there was an average of 8 mails a day, while this month we are getting almost 30 emails. Of course the N800 launch has a lot to do with this increase, but nevertheless the average in 2006 was 12,3 emails/day (17,2 if you don't check this list during the weekend) ;) -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] New list spin-off?
Summarizing the first round: - If developers don't see a clear need to create new lists there is no point creating them. The problem with this kind of discussions is that you get the opinions of the ones that are happy inside. It's more difficult to get opinions from those not reading the emails anymore, the ones that already unsubscribed and the ones that didn't join (i.e. because of the amount of traffic). Also, projects grow. Imagine Debian or GNOME with 2 mailing lists and then filtering. But yes, point taken. - Let's discuss this idea of separating platform / applications. It was the original thought, it makes sense. - Maemo is a community of developers, if end users end up here is because they don't have another mailing list where to get support. Nokia is not providing that space nowadays. The InternetTabletTalk web forum is doing a great work in this sense, though. We need to decide what we want to do with the end users among us as well. Until now we are getting mostly power users, who anyway enjoy discussing near to developers. But as the Internet Tablets are sold, more pure users are joining this community and surely many of them will want basic support and only basic support. What is the approach of the maemo community towards them? - There is an offer to discuss Python related topics at https://garage.maemo.org/mailman/listinfo/pymaemo-developers . It's up to you to officialize this or not. We at OSSO will follow the trend. - There have been other offers, it looks like we should keep them quiet by now. I definitely wouldn't make any distinction between 770 and N800, though. And an additional opinion. Perhaps one day will make sense to have a first experiment with the Graphics/UI people. Programmers and designers have generally different mindsets and priorities. Both need to know what the other group is doing but generally they can do with updated documentation i.e. in wiki pages, avoiding the internal discussion in the lists. One of the purposes of this proposal of creating specialized lists was to find a better way to interact with specialized developers here in the OSSO team. We have some brave Graphics/UI OSSO members in this list and they want to improve the communication with their counterparts in the community. Let us know if this try would make sense. -- Quim Gil Maemo team -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Tommi Komulainen Sent: 31 January, 2007 17:23 To: maemo-developers@maemo.org Subject: Re: [maemo-developers] New list spin-off? On Wed, 2007-01-31 at 15:22 +0100, ext Frantisek Dufka wrote: [EMAIL PROTECTED] wrote: I think more lists produce more confusion than single one. In fact I'd vote for joining maemo-users and developers as there is no really significant difference in topics posted to them. Developer questions get posted to maemo-users and vice versa and sometimes topics are duplicated since people don't read the other list. The original intention for maemo-developers was for discussing development of the platform itself (think gtk-devel-list) and maemo-users for developing applications to run on maemo (gtk-app-devel-list) We haven't really been pushing people to other lists, though. It may or may not have been a good idea. -- Tommi Komulainen [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] N800 codes at UK shop
Some of you had trouble at the UK shop (some don't, 50% according to our records). Hopefully this is a solution for the unfortunate: http://direct.nokia.com/countries.aspx?model=N800add=truecountry=GB It should work. Otherwise contact phone/mail support of the UK shop. At this point we believe all the online shops are aware of the N800 developer program and should be able to provide support and answers. They can solve problems with i.e. credit cards - we don't. Thank you again for your understanding. We are taking notes not to forget. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Warranty of discounted devices (was RE: anyone else troubles with the camera?)
Also do developer devices come with warranty? Definitely, they are full comercial packages with the same warranty, terms and conditions than the devices bought in any store at a full price. This is one of the reasons why we can't send devices from Nokia to [unsupported country], since all these small prints apply only to the countries where the device is sold. PS: please avoid crossposting between the users and developers lists - thank you. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Maemo roadmap, SDK improvements...
http://maemo.org/platform/docs/roadmap.html This page needs an update. I will help getting this page on shape. This update is also a good opportunity to discuss possible futures. Now it's also a good moment to review the SDK and see what improvements can be made. The more pragmatic and specific you could be here, the better. Thank you -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] USA shop trouble + update
Hi, Analyzing the sequence of emails in this list and my mailbox it looks like there was some trouble at the Nokia USA shop, although it seems that the customer support mechanism scaled up the issue and by now they are all aware and like able to solve problems (I need to confirm the latter, but the US is mostly in bed now). I have sent a summary of complaints to our contacts there, we will let you know about any relevant news. Since we maemo team are sending the codes, it is understandable that we get the complaints. However, please understand that we have no access at all to the shop machinery, nor we know what is going on when your credit card is not being accepted. Nokia USA support should still be your primary resource for getting the issues solved. Our indirect way to help you is getting in touch with the US shop management so they send the appropriate messages to the support lines your get in touch. We can help directly with the weirdest cases and rare exceptions, though. Just try hard first with their support channel, please. Hubert others, we have sent a US code to many non-US non-EU contributors around the globe. Yes, we know you can't get your N800 directly delivered at home. As explained the wiki page, you need to find out yourselves what to do next. We are not happy with this solution but it's the only realistic option we had. The alternative would be sending codes only to contributors living in countries where Nokia has online shops. We decided to send you the codes anyway, because you deserve them as much as the rest, regardless of where in the world you are actually contributing to this project. More questions are being answered in the updated http://maemo.org/maemowiki/N800DeveloperDeviceProgram We are about to close this program. We are still dealing with some worthy self-proposed contributors, some people needing EU US swapping codes and the support to issues encountered at the shop. The maemo coupon team (thanks Larry for the label) :) needs to move forward onto other things. -- Quim Gil Maemo team ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
