OpenMoko & OE question
werner at openmoko.org
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 projects.openmoko.org MokoMakefile SCM).
> 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 :-)
/ Werner Almesberger, Buenos Aires, Argentina werner at almesberger.net /
More information about the openmoko-devel