Request for stable, automated build process

Bobby Martin bobbymartin2 at gmail.com
Thu May 1 18:29:40 CEST 2008


On Thu, May 1, 2008 at 11:18 AM, Thomas Wood <thomas at openedhand.com> wrote:

> On Thu, 2008-05-01 at 11:01 -0500, Bobby Martin wrote:
> > I sent this before to openmoko-devel and was greeted with a deafening
> > silence, so I'm resending to a broader audience.  As evidenced by a
> > recent post to openmoko-devel by saurabh gupta, one of the GSoC
> > selectees, this really is a problem.  The longer it's put off, the
> > more potential benefits (in the form of community contributors who
> > give up rather than improve OM) are lost.
>
>
> OpenMoko (the software stack) is constantly changing and being updated.
> It is still in the very early stages of development and does not have a
> definite design specification or vision yet. I think until there are
> more concrete plans for the software strategy, you cannot expect a
> stable platform.
>
> I'm not disagreeing with you here, just pointing out why these problems
> arise.
>
> Regards,
>
> Thomas
>

I understand that your answer may well be the reason things are as they are,
but I disagree strongly with the sentiment.

To my mind, the first step after you have an early prototype of a system
that works is to set up a continuous integration server that automatically
builds, runs automated tests, and labels appropriately.  Without that, any
work you do is shooting in the dark.  This is (of course) particularly true
for a distributed project, where you can't just yell over the wall to
someone that they broke the build.

I've been several places where they did almost everything wrong in terms of
software development, but if they have a good continuous integration server
and automated test harness, and a culture of quick response to breaking the
build, it can work anyway.  I've also been on several projects where the
developers were technically brilliant and wrote great code, but it turned
into an unmaintainable mess because we couldn't forsee the consequences in
hundreds of thousands of lines of code when we make a seemingly innocuous
change to a low level subsystem.

Bobby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20080501/c1bc9349/attachment.htm


More information about the openmoko-devel mailing list