(Re it driving the MeeGo Handset ARM work)

Placement text is typical in UI under development and we've been able to make phonecalls and send SMS for a while now..

.. but let me try to phrase this correctly on what exactly 'drives the MeeGo Core+Handset ARM work' means - you ask good questions, hence you deserve a good answer - please read the links I refer to before answering, just to help you understand what's going on.

Let's start at the basic premise, MeeGo.com is a platform that gets released every six months - it's not an end-user product, but it's a platform that people can use to create end-user products with, with relative ease compared to making their own OS entirely. Bug fixes to features in the platform are delivered after release date as well.

Nokia N900 is a MeeGo reference device for MeeGo Core and Handset. This means in our daily work:

When a package submission/change is submitted into Trunk:Testing (the 'stage' for adding things to Trunk), QA is run using the reference devices to verify the change doesn't break anything on these.

Now, we have this roadmapping/requirements process, http://meego.com/developers/requirements - you can spot all the submitted requirements and their state here

For each of those requirements in platform these gets verified on both IA and ARM (provided they're not processor-specific). For the requirements belonging to Core and Handset, that means in practice, they get verified they're implemented on N900.

That means that N900 drives the MeeGo Core and Handset work on ARM - we need to have a implementation that satisfies platform requirements as we can't QA properly without those.

In addition to that, we find requirement gaps during implementation and in the QA results, feeding back into the requirements process.

So, when we have a platform requirement to provide a reference web browser, we need to have one that works on N900. QA results may say that audio needs to switch from ear piece to speakers based on if you're making a call or not, feeds back into the requirements process that we need an audio policy daemon.

If a reference implementation doesn't work well, people will naturally be wary of basing anything on top of it, so there is a sense of quality to be accomplished. Does it need to look good?

Naturally, but it needs to properly showcase platform ability, sell a platform, not an end-user product - so there's a difference in how much polish is needed.

I think the level of polish needed is high, of course - but in the end one reason for the cartoonish look is to make sure people customize the UI, themes, etc. The UI framework is very capable.