Build Policies

With notes from Thursday April 6th 2006 and Thursday May 11th 2006 (Sprint) meetings incorporated

Full build breakages and policies in case of breakage have recently generated tensions between devs and release engineering. This is a quick summary of the problem and statement of possible solutions.

Statement of the Problem

Developing on internal and external libraries (wxPython, PyLucene, etc...) is difficult because developers need to compile debug and release on 3 platforms at once. Breaking the main Chandler build is not an option so Andi developed some years ago a 2 stages build system so that the build of libraries can be temporarily broken without blocking the Python development effort. Those 2 stages are called full build and quick build.

The problem now is that the "no build breakage tolerated" policy which is enforced (and rightly so) on quick builds has also been extended to full builds, making again development on libraries difficult.

There are good reasons for having a compiling and running full build (see this thread) having to do mostly with packagers picking up the whole source tree to port Chandler to exotic platforms. Having the full build constantly broken makes their work difficult.

We need to find a system so that libraries developers can continue to use the build machines as a facility to run builds on more machines they typically have and allows developers to do full builds from the source on their machines at any time.

Analysis

What packagers or other devs who want to build Chandler from source (i.e. without using the binary tarballs used in the quick build) really want is the set of source used to create the same binaries as the one used by the quick build.

This only means that devs need to be able to retrieve the sources used by the official Chandler quick build. This can be achieved in several ways using SVN techniques.

Some of the reasons for having 2 builds:

• Enable Python / Chandler developers not to be impacted by build issues of libraries
• Full builds are difficult to perform, quick builds insolate people from this
• We can't have library developers building all the flavors debug and release before commit (impractical)
• The full/quick build system has been designated to help library developers to commit and build

Possible Solutions

Solution from a build machine standpoint:

• Have a 3rd flavor of the build that does full build from the most recent source and make drop . This guarantees that the Chandler code is ran against the most recent libraries. The current full build picks up the tarball as long as the relver hasn't been edited (this is to avoid the full build tree to go red all the time).

So we would have:

• quick build : builds Chandler only and get the libraries from tarball binaries (compiled and tested)
• full build : builds everything from source but uses make install so Chandler is functionally tested against the old tarball
• lib build : builds everything from source but uses make drop so Chandler is functionally tested against those new libs

Looks like everyone agrees on this idea.

Debate is now on how the SVN tree should look like:

• Have a dev branch (Bear / Heikki) : lib build is built from a dev branch, branch is merged to trunk when lib builds go green, full build from this certified trunk
• Tag on the trunk (Philippe) : lib build is built from the trunk, when green it's tagged, full build from the tagged version
• Have build branch (Andi) : lib build is built from the trunk, this is merged to a clean build branch when green, full build from the build branch

Bug 5363 is tracking this issue.

Policies (draft)

• quick build break : full stop : no commit authorized anywhere as long as the tree is not restored to green
• full build break : high emergency : no commit authorized in the libraries as long as the tree is not restored to green
• lib build break : urgent : need immediate fix, as much as possible other lib devs wait one green cycle before committing again

Action Items

• Philippe : post on the chandler-dev list to bring up the SVN topology issue
• David : no more incremental update once tarball 39 landed (which should happen soon since John has a fix for the functional test breakage)
• Bear / Heikki : implement the lib build and SVN change in 0.7alpha3

---

bear: currently there is already a source tarball for external/ sub-projects and it uses the same relver as the binary tarball that is created. The internal/ sub-projects are not tagged at all but nothing prevents the devs from creating a tag when they bump the relver. The builds should be green as often as possible, so creating tags based on that may not be best - the dev who is responsible for the sub-project is the only one who knows when to push the sub-project - and that is done currently by them setting the relver.

wx SVN and Build:

• wx moving to external
• wx in its own SVN repository
• 2 branches : trunk (stable) and CVS (automatically from the CVS wx tree)
• CVS branch merge to the trunk done manually: weekly or when there's a known bug fix
• Reid, John, others will commit to the trunk only
• we do a build with the trunk with the current trunk of Chandler and run the unit and functional tests
• we may want to provide failure feedback to the wx community if possible
• when merge go red, no commit authorized before it gets green
• we'll create wx source tarballs as well as binary tarballs

• we need 3 of them: 1 Mac mini, 1 PC XP, 1 Linux Ubuntu
• need to check the power / cooling issue of the server room with Jared

External and Internal projects

• Proposes to use Dev branches and regular merges to the trunk
• We need a new set of Tinderboxes to support dev nuild (aka lib build) and trunk build (aka full builds)
• Looks less critical to do that now that wx will be isolated

Mac Intel binaries

• no gcj yet so it's stalled for the moment, gcj needs a new version of gcc to work
• hope that gcc 4.2.0 will solve some of those issues, ETA: 2007!

Post meeting note 5/30/06: Since the meeting, the gcj issue has been solved independently from OSAF by an Open Source contributor. Andi was able to compile, link and run Chandler successfully on Intel Mac. We decided to make the Intel Mac platform an officially supported platform as early as 0.7alpha3.

-- PhilippeBossut - 06 Apr 2006