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.
