So, maybe I am not understanding the real issue. When I run testing on some new
development, I do it in the branch or changelist that I am working on, and
record the results. If I feel like I need to adjust the test strategy, I do
that as a separate change on a separate branch/changelist that I can use to run
against the existing code.
I can checkout/copy (rsync is my friend) stuff to an appropriate place to do
longer term testing.
Is the real issue that communicating the "test stuff" (source etc.) really
requires a "submission" so that it can go over to the test servers because the
type of change that Patricia wants to test can't be tested in her local
environment? I'd guess it is because of the parallel discussion about modularity.
It seems like we have a "different" type of development model that the source
tree was designed to support vs what the test environment we have supports?
Gregg Wonderly
On 2/28/2011 9:08 AM, Dan Creswell wrote:
On 28 February 2011 14:50, Patricia Shanahan<[email protected]> wrote:
Dennis Reedy wrote:
On Feb 28, 2011, at 1247AM, Patricia Shanahan wrote:
How would you propose handling a case like outrigger.FastList?
It is package access only, so changing its interface to the rest of
outrigger did not affect any public API. Several classes needed to be
changed to handle the interface change.
If I understand your question correctly, I think it should be fairly
straightforward. Following module conventions, we would have a structure
that would look (something) like:
outrigger/src/main/java/org/apache/river/outrigger
outrigger/src/test/java/org/apache/river/outrigger
The test (or benchmark) code would be in the same package, just in a
different directory. You would be able to accommodate your package access
only requirement.
I don't see how that answers the problem of a possible intra-package
interface change that needs to be benchmarked *before* the changes to the
rest of the package that would be needed to integrate the class under test
with the rest of what would be its package if it wins the benchmark.
If I had initially named my new FastList implementation
"com.sun.jini.outrigger.FastList" I could not have compiled outrigger in its
presence. It is not a drop-in replacement for the old FastList.
If it had turned out to be slower than the existing FastList I would still
have wanted to preserve it, and the relevant benchmark, because of the
possibility that future java.util.concurrent changes would make it better.
On the other hand, I would not have done the changes to the rest of
outrigger.
So I think we're coming down to the new FastList implementation having to be
called something else for benchmarking purposes to avoid conflict with old
FastList. Or the new implementation needs to be an inner class of the
benchmark and that could live in the same package as original FastList. Of
course, still packaging and source organisation concerns to conquer.
