Think the nub of the issue is two-fold: (1) Dealing with namespace clashes (see Patricia's FastList conflict discussion). (2) Partitioning of tests and fitting them efficiently into development or build/release cycles.
On 28 February 2011 15:29, Gregg Wonderly <[email protected]> wrote: > 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. >> >> >
