[Chandler-dev] Build Policies meeting

[Andi Vajda]

On Fri, 7 Apr 2006, Alec Flett wrote:

> Philippe Bossut wrote:
>> We basically have 3 competing proposals: (note I'm talking only about the 
>> internal and external projects here, not chandler)
>>    1- Use 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
>>    2- Tag on the trunk (Philippe) : lib build is built from the trunk, when 
>> green it's tagged, full build from the tagged version
>>    3- Use 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
>> 
> I wasn't sure which one of these meant "spin wxPython off into a 3rd party 
> product much like PyICU/PyLucene/etc" - I'm guessing this is #3? That would 
> be my vote.

Actually, that was a 4th proposal I had made at the very end of the meeting 
that didn't get noted. There are several competing needs in our current build 
system setup:
   - release engineering wants a stable build
   - developers want an easy build
   - wxPython needs test automation because it is the most demanding from a
     cross platform standpoint and David can't be expected to manually test 6
     sets of binaries - soon to be 8 with the pending arrival of Intel Mac
     builds.

> I think the rest of the 3rd party libraries have demonstrated good practices 
> in terms of working on changes in isolation, and then rolling them into the 
> 'chandler' trunk via tarball. We don't have much of this confusion with 
> PyLucene/etc - Andi maintains those libraries and if he breaks them they 
> don't break the main chandler trunk until the tarball rolls.

PyLucene and PyICU don't introduce API changes that often but chandlerdb does 
it pretty much all the time. Whenever the chandlerdb API changes, the full 
build tboxes used to go orange from the time the new chandlerdb was checked in 
until the API changes are reflected in the chandler tree - basically, the time 
between the commit of the changes and the build and release of the 6 binaries 
followed by the commit of chandler/Makefile concretizing it.

Andi..