On Jul 21, 2006, at 3:20 AM, Jeff Genender wrote:
I find it very hard to believe that we are going to spend time to
setup
the TCK to run on sandbox/svkmerge/m2migration.
How does this differ from what you are doing today with the G
codebase?
Sorry, I do not understand what you are asking.
* * *
My understanding is that to get the TCK bits working and automated in
GBuild that we need to have a CI process that is publishing artifacts
and I do not believe that we want to spend time to setup that process
on this sandbox branch. I believe that we want to do this for
trunk. In fact we need to do that to get the OpenEJB2 build
automated, which is also required to get the G build automated.
I believe that setting this up for my m2migration branch would be an
intermediate step that benefits us very little and overall just slows
down the progress of getting the TCK up and running for the long run
using m2. If you mean to have me (or someone) run the TCK locally
I'm not sure that will fly either as I certainly don't have cycles on
my laptop to run the TCK for however many days it takes for the thing
to run, nor do I have the expertise at this moment to know how to fix
it if it breaks on something.
IIUC there is significant configuration involved to get everything up
and running, and significant time to actually run, therefor we could
easily burn a week or more to perform the intermediate setup and then
have to reburn that time to do it again.
The best option to get the TCK up and running fastest and in a
permanent state of continuous integration is to merge the work to the
trunk and then setup GBuild to use trunk to run tests against.
Its like we have just performed some major renovations on your house
and need the inspector to come and make sure that everything is up to
code... well, the inspector is not going to demand that the
renovations be applied to a mock house build out in your backyard
first before allowing them to be applied to your house proper.
--jason
