OpenMoko & OE question

Werner Almesberger werner at
Mon Feb 19 05:52:31 CET 2007

Rod Whitby wrote:
> No problem - I assumed as much.  I'm just trying to be the "stay in step
> the the core team builds" counterpoint to Koen's (equally valid) "run as
> fast as you can to pure OE bleeding edge builds" work :-)

Yeah, both approaches have their merits, and they should even
converge. In any case, we need to have a bit of "buffering" from
external changes, or the butterfly effect will kill us.

> Excellent.  I hope you will use MokoMakefile as the top-level executor
> for that, so we know that the official QA builds can be easily
> reproduced by external devs on their own build machines.

It definitely looks like a good starting point. I haven't looked at
the details yet, but I like the idea. There seems to be a lot of
rather long path names and commands in there, though, and I wonder
if it wouldn't be possible to shorten them through the use of
variables. I'm also a big fan of wc -L never reporting a number
larger than 80 :-)

> MokoMakefile will have full configuration management internally, with
> versioned releases that match various significant versions of the
> OpenMoko SCM repo (i.e. I currently have both patches/openmoko-1004 and
> patches/openmoko-1041 dirs in the MokoMakefile SCM).

Very good.

> Is a debug v2 board included in the Phase 0 dev package?

Yep. It'll be optional for phase 1, though.

> No need to be sorry at all.  I take that attitude with OpenMoko that
> access at this stage of development to the source code means that we
> (external developers) should accept it in the state that it's in, report
> bugs, get them fixed, and not make a big fuss about any unpolished work.

Heh, yes, that's the general idea :-)

Thanks !

- Werner

 / Werner Almesberger, Buenos Aires, Argentina     werner at /

More information about the openmoko-devel mailing list