[Chandler-dev] Re: wx build/merge/test thoughts
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
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
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