Borrowing from the earlier Eclipse thread that wandered into Netbeans and QEMU, it may be useful to climb to the top of the stack and think about releasing a pre-cooked virtual machine (VM) for each "common enough" set of TS boards.
This is just the beginning of an idea, intended to stimulate conversation: I haven't implemented anything like this myself.
The VM would runs the board's Linux via QEMU, but could also have a full NetBeans environment installed that can either be accessed through the VM's display, or (as I would) remotely via X11 on the host (Linux/Cygwin). But even if a full NetBeans install isn't included, the relevant NetBeans plugins may be included to simplify NetBeans setup on the host system.
The VM could "own" the target system, using it as a distcc peer, as a test server, and could automatically place binaries there. (The target would not be in charge of the build.) All target access (at least for development purposes) would be through the VM.
In a shop with multiple developers working on the project, each developer would have at least one development VM running, and all the developer VMs could also participate in distcc, as well as any distributed or parallel automated testing.
The QEMU burden would be significant, but it would eliminate the need for cross-compilers, making it easier to maintain a consistent (identical) build environment not only on the target, but also on each developer's system.
I haven't yet looked at the NetBeans "Remote Development Host" capabilities, but I suspect that may be a good way for locally hosted NetBeans instances to work with the VMs and the target.
What I like best is that the VM is platform-independent: The same VM can run on Win7, Linux and Mac. At most, a second ARM-native VM (without QEMU) may be needed when developers start having ARM systems at their desks.
Ultimately, the goal is to maximally enable customer development with minimal support required.
Sane or insane?