Just wondering, did anyone bother to ask what exactly what kind of commitment exists regarding the MeeGo hardware adaptation for Nokia N900, instead of guessing?

Let me draw out some phases of a hardware adaptation:

1) Optionally adapt the OS to your chipset (ARM, X86, MIPS, whatever) . This was done initially by a cooperative effort by the same team currently bringing you MeeGo to N900 (ever wondered why we're called #meego-arm ?), the LF guys and the Intel OS&release guys with some help and guidance.

2) Upstream kernel changes to Linux kernel as this is a requirement for inclusion in MeeGo kernel. This means that when a change breaks MeeGo kernel, it gets noticed and fixed

3) Port any hardware support bits (BME, 3d accelerator drivers, WiFi firmware). Make scripts that fix issues/add features specific to the device that would be different from the base system.

4) Testing, testing, testing. A large bunch of test cases is getting written, problems found in hardware adaptation.

5) Feature completion. All the code is there matching hardware capabilities and has to be maintained.

From there on, things follow the 'seasons' of MeeGo, check out the typical release timeline

The most important phase is the Intrusive Change Phase, where our world may be turned upside down. This is where resources are needed the most. Kernel developers for instance.

Next up is feature development, where a hardware adaptation team is not really doing much if it's already feature complete.

Then there's stabilization, fix bugs... and so on.

What I'm saying is, people are both overestimating and sometimes underestimating what it takes to maintain a hardware adaptation in MeeGo.

Rest of MeeGo will get developed for sure, I mean, it is supposed to be the basis of a large bunch of devices, including Nokia's. A hardware adaptation is what, less than 3% of the code in any given MeeGo N900 image? Rest of this comes directly from the MeeGo project. Core, Handset, and so on. Taking binaries directly.

We're trying hard in MeeGo for N900 to open up for others to help contribute, though we have difficulties at times, but try to lessen them. We're trying to do the hard initial work and work out what it takes to maintain things - including open sourcing key pieces.

It'd be stupid if we spent ages on making a proper hardware adaptation and then just let it to rot after MeeGo 1.1. A lot of QA time spent, developer time. Consider our work momentum to keep the ball rolling in the future - and to keep having momentum by maintaining this work.

Now, will you go test the development images (yes, we uploaded a MeeGo image), report the bugs in the images, submit merge requests to our scripts and code in the hardware adaptation or contribute to MeeGo in general or even discuss the work and direction? By having as many contributors now as possible, the faster we get the work done, including these early contributors becoming experts in 'MeeGo on N900', making them capable of maintaining things in the future.

Many of you succeeded in building own MeeGo N900 images using .ks'es. Congratulations - that's first step any team members who has been doing MeeGo on N900 have had to do. Now, what's your next move?