Request for stable, automated build process
Bobby Martin
bobbymartin2 at gmail.com
Thu May 1 18:01:38 CEST 2008
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.
--------------------------------------------------------------------------------
I really think OM is shortchanging themselves with the current build
process. As far as I can tell:
* there is no way to run a build that has a high probability of working
all the way through
* there is no way to identify the latest code that builds together
* there is no automated build process, nor even a stable script one can
follow to do a complete build from source on one's local machine
* it looks to me as if the code lives in at least three different kinds
of repositories: svn, GIT, and mtn
* I'm sure that there is a way to identify the code that went into a
particular snapshot found on the web, but I don't know what it is
* there is no way to identify which tasks definitely have someone
reliable working on them, which are open issues & need attention they're not
getting, and which have some casual developer looking at them
I have done several very minor programs for my neo, which I would have much
preferred to integrate into the real build process. However, when I've
tried the Mokomakefile process, it will run for hours and then die in some
obscure way. I spent a few hours over the course of several days debugging
that process on my Ubuntu machine at home, before I realized there were
version issues with the assembler that I didn't see any way to work around.
I have a debian installation that I run some web services on, and a build
there went farther, but finally failed as well. I see consistent complaints
from people who do have known good build environments that the build is
broken for days at a time.
I just don't have the energy to spend a dozen hours debugging a process that
will enable me to spend a few dozen hours doing development. I would think
that many other potential contributors fall in the same boat.
I think that a few procedures could dramatically increase the development
community's involvement in OM, resulting in faster bugfixes, more features
added sooner, and greater visibility into the project status:
*Automated build process*
The build process should be a no brainer. The process should document the
operating systems & versions supported, and the tools & versions needed. If
I run on one of those OSes, I should be able to download one script and kick
it off, and come back a day later and have a full build of the latest code
that compiles. I can then update the configuration to get the latest code
in specific areas if I want to.
To ensure that *anyone* who is a competent developer can run the build
script, ideally there would be a chroot filesystem tarball to fall back on
or a VM image for when you don't have the appropriate OS version available,
or otherwise have conflicts between the OM build process and other things
you may need on your system.
There should also be a test harness for developers to easily insert tests
for their code, and for which every bug (except those that require hardware
to test) must have a test inserted for the bug to be considered fixed. The
test harness should likewise be runnable trivially, with one simple command
(e.g. 'make test')
*Continuous integration* (CI)
Someone needs to set up a server that on a periodic basis (one or more times
per day) pulls the latest build process script, labels the code with
something like CI_CANDIDATE, configures the build script for that label and
runs it. If that process fails at any point, some set of interested parties
should receive an email (ideally, also the people who checked in changes
since the last working build would be emailed).
If the process succeeds, then the code labeled CI_CANDIDATE would be
relabeled something like GOOD_BUILD_2008_04_23 and the CI_CANDIDATE label
removed. Further, the test harness should be run, and if it passes a label
like TESTS_PASS_2008_04_23 should be added.
*Task tracking*
Maybe this is supposed to happen in bugzilla now, but it seems to me that we
need the kind of bug tracking I was discussing above - a full list of tasks,
priority (something as simple as High, Medium, Low would work fine), and a
way to see if it is *really* being worked or not. Having a project manager
who is an OM employee for every task would be helpful, since we could then
expect to get an answer if we email a query about the status.
*Documentation*
If the above were implemented, that documentation could be as simple as
telling people:
* the script location and how to configure what labels are used for each
subsystem
* the location to download the VM or chroot tarball if necessary
* the meaning of the continuous integration labels, and which ones to
look for
* perhaps the place to look for CI build statuses (most recent
successful build, etc)
* the location of the task tracker and the important fields (status,
priority, assignee(s), project manager)
Some or possibly even all of this may exist, but if so I couldn't find the
documentation. In particular, CI and a test harness make a HUGE difference
in the likelihood of success of a project, and the ease of contributing to
the project.
I realize that this would cost someone several days of effort, but the
payback wouldn't just be for the community, the developers at OM would
benefit, and the managers and executives would have much greater visibility
into the status of the project.
--
If it doesn't make you smile, you're doing something wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20080501/8f642fe5/attachment.htm
More information about the community
mailing list