On 2/28/2011 9:33 AM, Dan Creswell wrote:
Think the nub of the issue is two-fold:
(1) Dealing with namespace clashes (see Patricia's FastList conflict
discussion).
Okay, but, when I am doing something to replace code/classes with the same name,
I most often do this in a branch that I will later reintegrate into the main
branch. Sometimes, I will do it in place in an active change-list that I may
not submit for some time. There have been times that I've just used the SCM to
preserve the changes, in place, by submitting them and then synching to the old
version and then submitting that older version over the top of my investigation.
Then, I go back later and revisit that idea without losing it, and provide
something that others could check out to look at.
I think there are lots of SCM based mechanisms that can be used to "hide" or
"manage" these name space based conflicts. Which of these things are people
most often using as their reason for being frustrated by testing capabilities?
1) We build this one thing and want to test two version from that single build.
2) Don't have space to have two copies.
3) Can't test locally, so have to submit something to get it into the offline
test facilities.
4) Something else I've missed.
(2) Partitioning of tests and fitting them efficiently into development or
build/release cycles.
This points back to 3) above I think. Does that mean that we are just not
"testing" the right branch? Shouldn't contributors largely be testing in
development branches and then the project integrating and accepting "approved"
changes into the production branch that are then tested one more time with a
broader integration suite?
In the discussions on the use of branches I didn't really note whether this was
something people liked or had experience with. Is there something about this
that seems not so attractive? Do many disparate changes can cause integration
to be a little more taxing, but that's just a fact of life in some cases where
you can't work together, or don't know about another party doing anything in
parallel with your work. I do like perforce's centralized store for this
reason, because it does make it possible to see where your coworkers are
tweaking things so you can expect conflicts or ask them about what things you
need to be aware of.
Gregg
On 28 February 2011 15:29, Gregg Wonderly <[email protected]
<mailto:[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]
<mailto:[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.
