[maemo-developers] Why should I write apps for Maemo?

[From: Eero Tamminen]

Hi,

(standard disclaimer: below are my personal opinions)

ext Michael Cronenworth wrote:
> At most, the SDK should have been released two weeks ahead of the final 
> release.

Agree.


> With a little over a month now on the clock, people can only 
> begin to speculate as to how poor Nokia's release management is working. 

Releases are not based on calendar, but on them being ready, based
on testing results. (Hm. Is Maemo showing its Debian roots?)


> I, as a software developer, realize that unexpected issues can occur 
> causing unexpected delays,

I think it's mainly due to wanting something that doesn't have
any known regressions in any area from the previous release while
significantly[1] improving some areas.  And this requiring
somewhat unexpected amount of iterations.


As one example, when we optified some of the rootfs content to make
more space on it (for SSUs), we had to deal with the slowdowns coming
from those packages being now on eMMC (which is slower than rootfs
especially when the device is swapping).  This required quite a lot
of iteration on what to optify, SSU issues, policy & memory locking
finetuning, otherwise optimizing slow things etc.


Another example, which some might think funny, is Browser related.

Browser + Flash combination had some crashes which were fixed
(because UI restarts engine automatically, user might not even
have noticed these except as larger browsing slowdown).  However,
with the fixes single Browser engine instance could keep up so long
that several days of Browsing increased its memory usage a lot.
Which then caused performance issues...

Finding that this was one cause for longer term usage slowdowns took
quite a while, as did hunting down[2] and fixing these previously
unnoticeable[2] memory leak(s).


We also wanted to fix all the SGX related issues, but I think one
is going to be left after PR1.2 as it's not reproducible.  A lot
of other SGX issues that were eventually to some extent reproducible
by someone internally, either with specifically crafted test-case or
some already existing SW, have been already fixed in internal PR1.2
releases.


[1] While some things are obvious, improvements in some other areas
     aren't necessarily directly visible to (all) users, because many
     of the issues we've fixed (use-time, reliability etc), happen only
     in very specific conditions or use-cases.


 > -Is PR1.2 still going to be released?

Definitely.


	- Eero

[2] In case somebody hasn't hunted down Mozilla memory leaks,
     maybe mentioning these gives some light on it:
- Valgrind doesn't produce very useful results with it because of
   the JavaScript (and multiple Flashplayer) interpreters
- Browser is an application doing both largest number and largest
   total amount of allocations of the applications in the device and
   those are completely controlled by content on the www-pages
   and this content changes[2] from one page refresh to another.

[3] If testing would use just static browser content, it would
     miss new issues with latest real & live web content.  Non-
     changing test content can find just regressions.