I really think OM is shortchanging themselves with the current build process.&nbsp; As far as I can tell:<br><br>&nbsp;&nbsp;&nbsp; * there is no way to run a build that has a high probability of working all the way through<br>&nbsp;&nbsp;&nbsp; * there is no way to identify the latest code that builds together<br>

&nbsp;&nbsp;&nbsp; * there is no automated build process, nor even a stable script one can follow to do a complete build from source on one&#39;s local machine<br>
&nbsp;&nbsp;&nbsp; * it looks to me as if the code lives in at least three different kinds of repositories: svn, GIT, and mtn<br>
&nbsp;&nbsp;&nbsp; * I&#39;m sure that there is a way to identify the code that went into a particular snapshot found on the web, but I don&#39;t know what it is<br>&nbsp;&nbsp;&nbsp; * there is no way to identify which tasks definitely have someone reliable working on them, which are open issues &amp; need attention they&#39;re not getting, and which have some casual developer looking at them<br>
<br>I have done several very minor programs for my neo, which I would have much preferred to integrate into the real build process.&nbsp; However, when I&#39;ve tried the Mokomakefile process, it will run for hours and then die in some obscure way.&nbsp; 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&#39;t see any way to work around.&nbsp; I have a debian installation that I run some web services on, and a build there went farther, but finally failed as well.&nbsp; I see consistent complaints from people who do have known good build environments that the build is broken for days at a time.<br>
<br>I just don&#39;t have the energy to spend a dozen hours debugging a process that will enable me to spend a few dozen hours doing development.&nbsp; I would think that many other potential contributors fall in the same boat.<br>
<br>I think that a few procedures could dramatically increase the development community&#39;s involvement in OM, resulting in faster bugfixes, more features added sooner, and greater visibility into the project status:<br>
<br><br>*Automated build process*<br>The build process should be a no brainer.&nbsp; The process should document the operating systems &amp; versions supported, and the tools &amp; versions needed.&nbsp; 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.&nbsp; I can then update the configuration to get the latest code in specific areas if I want to.<br>
<br>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&#39;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.<br>
<br>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.&nbsp; The test harness should likewise be runnable trivially, with one simple command (e.g. &#39;make test&#39;)<br>
<br><br>*Continuous integration* (CI)<br>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.&nbsp; 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).<br>
<br>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.&nbsp; Further, the test harness should be run, and if it passes a label like TESTS_PASS_2008_04_23 should be added.<br>
<br><br>*Task tracking*<br>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.&nbsp; 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.<br>
<br><br>*Documentation*<br>If the above were implemented, that documentation could be as simple as telling people:<br>&nbsp; &nbsp; * the script location and how to configure what labels are used for each subsystem<br>&nbsp;&nbsp;&nbsp; * the location to download the VM or chroot tarball if necessary<br>
&nbsp;&nbsp;&nbsp; * the meaning of the continuous integration labels, and which ones to look for<br>&nbsp;&nbsp;&nbsp; * perhaps the place to look for CI build statuses (most recent successful build, etc)<br>&nbsp;&nbsp;&nbsp; * the location of the task tracker and the important fields (status, priority, assignee(s), project manager)<br clear="all">
<br>Some or possibly even all of this may exist, but if so I couldn&#39;t find the documentation.&nbsp; 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.<br>
<br>I realize that this would cost someone several days of effort, but the payback wouldn&#39;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.<br>
<br>-- <br>Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in any country. — Hermann Göring at the Nuremberg trials