StubToolkit must go!

[David DeHaven]

> So my thought here is that if we can run 30,000 tests in < 5 min by allowing nearly all of them to be run in the same VM, then that is probably better than running 3,000 tests in separate VMs for the sake of our pre-commit testing. For the nightly run, we can certainly run them all in their same VM so that the analysis phase of failures is much simpler.

This sounds fine, so long as at the pre-commit level we have the option of running the full test suite in the "slow and steady" mode to isolate test instances.


> Yes, this is part of our continuous integration plan -- whether JPRT or something like it is TBD. But the idea is that once we have our build/test humming along nicely with our pre-commit / nightly / release testing phases all ironed out, then what we'll do is change our workflow so that we don't do weekly integrations from team forests into master. Instead you'll submit your fix as a patch to a JPRT like system which will then integrate & build & test (pre-commit tests) on all platforms and then if it passes do an automatic integration. If it fails it kicks it out and sends you mail and you can fix up whatever wasn't working and resubmit. Of course there are times when you want a sandbox / team forest and in those cases you can still work on the side. But when you are ready to integrate to master, you end up sending your wad of patches to the system and it integrates & builds & tests just like everything else.
> 
> Hopefully this will streamline the process, reducing the pain for weekly integrations for each forest, reducing the number of forests we need to know about etc, and also reduce the time to get a patch that has been reasonably well tested to get into master so SQE can start hammering away at it.

That would be wonderful! Modifying JPRT to pull and build JavaFX artifacts would not quite be so wonderful, but luckily that's not my job ;)

-DrD-