Heikki Toivonen wrote:
Ubuntu Gutsy Gibbon has been released, and Leoapard is just around the
corner. I have been thinking about what we'd need to do with them to
provide full support in the Tinderbox setup.
I'd really like to avoid adding four or more new machines (gutsy
full+quick, leopard full+quick, possible perf boxes). I am proposing
that we instead add only two: gutsy-full-linux and leopard-full-iosx.
These machines would do full builds with all the normal tests that full
builds do, and additionally do functional tests.
I believe the full builds would be pretty fast, since both of these
systems will be able to use several system packages, including system
python.
Full builds are just as fast as the quick build boxes when external is
stable, so the slow down would only occur if Robin or Andy have been busy :)
I also think we must do full builds rather than just make install
because of different system libraries we are currently depending on.
There is one major problem with this approach, due to the way our build
is set up where chandler/ can be out of sync with external/ and
internal/. We could either decide to live with the hopefully relatively
short breakages on these two Tboxes when external/ and internal/ change,
or do something about fixing this.
I don't know why I shouldn't be able to spend an afternoon, wrap my head
around the problem and come up with a solution that, at a minimum allows
for the Chandler side testing to continue even if the external side is
currrently failing.
One simple solution would be to break the tbox up into two distinct
steps, each with their own report sub-steps.
Additionally, I am proposing that we switch mana-linux (a quick build)
to produce only tarball releases, and the new gutsy to produce only .deb
releases.
That would speed up the distribution building step tremendously.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
