[Chandler-dev] Re: wx build/merge/test thoughts

Alec Flett alecf at osafoundation.org
Fri Apr 21 15:39:41 PDT 2006

Heikki Toivonen wrote:
> However, it is starting to look to me that there is going to be so much
> machinery to deal with wx specifically that it would make more sense to
> create a completely new svn repository for wx. From Chandler's point of
> view it would become just another external library.


At this point, I don't see how wx is much different than a PyLucene or a 
PyICU, aside from its scope within chandler. They seem like great 
models. I think its really frustrating for chandler developers that the 
main tinderbox goes orange/red if something is changed in internal/wx 
that hasn't been rolled out to the trunk. That doesn't happen with 

I think as long as:
1) unit + functional tests on wx changes are run just before rolling a 
tarball and
2) tarballs are only rolled when the tree is already green

...then a bad wx landing shouldn't happen. I'm sure everyone can agree 
with that.

I think its up to wx people (i.e. robin, david, reid, john, etc) to 
decide what kind of process works best for them  in between tarballs - 
incremental updates, multiple branches, or what. If they're happy 
breaking their own tree for a day or so while they iron out platform 
differences, that's fine. Andi does a fine job of maintaining 
PyICU/PyLucene and for all I know he might do the same thing. Since he 
only rolls tarballs when things are working for chandler, it doesn't 
really matter what he does, and that system seems to work very well.

I don't know if we'll ever know for sure, but my impression is that the 
whole 36/39 debacle came about because wx got rolled while the 
functional tests were either broken or barely hobbling along, so we 
didn't realize wx caused more breakage until a lot of time had past. 
Thanks to Dan we have an ever-increasing number of tests, and thanks to 
Bear we have much better tinderbox stability, so hopefully going forward 
we'll only further reduce chances of us getting into that situation again.


More information about the chandler-dev mailing list