incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: [VOTE] Merge lucene-4.0.0 branch to master
Date Wed, 24 Oct 2012 20:40:50 GMT
If there are no objections I'll merge in my blur client shell
submission, sound good?

Patrick

On Wed, Oct 24, 2012 at 11:27 AM, Aaron McCurry <amccurry@gmail.com> wrote:
> +1 on this solution.
>
> On Wed, Oct 24, 2012 at 2:24 PM, Patrick Hunt <phunt@apache.org> wrote:
>> Hi Gagan, I did find the cause, but not a good solution. Relying on
>> everyone to set their umask is going to be onerous. It would be great
>> if you could provide a proper solution - the one you suggested sounds
>> good.
>>
>> Regards,
>>
>> Patrick
>>
>> On Tue, Oct 23, 2012 at 11:53 PM, Gagan Juneja
>> <gagandeepjuneja@gmail.com> wrote:
>>> Oops! I missed Patrick's last post.
>>>
>>> On Wed, Oct 24, 2012 at 12:07 PM, Gagan Juneja <gagandeepjuneja@gmail.com>wrote:
>>>
>>>> I have simulated this issue on ubuntu box. I found that by default ubuntu
>>>> creates directory with *775 *permissions. And there is one property in
>>>> Hadoop Configuration named "dfs.datanode.data.dir.perm" and default value
>>>> for this is *755*. Somewhere in code permissions for data directories are
>>>> verified and it fails there and then.
>>>>
>>>> If we set this property in Configuration object with value *775,* all the
>>>> test cases are passing and build is Successful.
>>>>
>>>> We can set this in *startDfs* method of  *org.apache.blur.MiniCluster*class.
Please verify this, if problem got resolved at your end then I can
>>>> provide patch for this.
>>>>
>>>> Regards,
>>>> Gagan
>>>>
>>>>
>>>>
>>>> On Wed, Oct 24, 2012 at 4:32 AM, Patrick Hunt <phunt@apache.org> wrote:
>>>>
>>>>> Pushed a small cleanup to move all test file output into respective
>>>>> target directories and use absolute paths for test file locations.
>>>>>
>>>>> I thought this might fix the BlurClusterTest however that's not the case:
>>>>>
>>>>> Starting DataNode 0 with dfs.data.dir:
>>>>>
>>>>> /home/phunt/dev/blur/src/blur-core/target/tmp/cluster/dfs/data/data1,/home/phunt/dev/blur/src/blur-core/target/tmp/cluster/dfs/data/data2
>>>>> ERROR 20121023_15:58:10:010_PDT [main] datanode.DataNode: All
>>>>> directories in dfs.data.dir are invalid.
>>>>> ERROR 20121023_15:58:10:010_PDT [main] datanode.DataNode: All
>>>>> directories in dfs.data.dir are invalid.
>>>>> ERROR 20121023_15:58:10:010_PDT [main] blur.MiniCluster: error opening
>>>>> file system
>>>>> java.lang.NullPointerException
>>>>>         at
>>>>> org.apache.hadoop.hdfs.MiniDFSCluster.startDataNodes(MiniDFSCluster.java:422)
>>>>>         at
>>>>> org.apache.hadoop.hdfs.MiniDFSCluster.&lt;init&gt;(MiniDFSCluster.java:280)
>>>>>         at
>>>>> org.apache.hadoop.hdfs.MiniDFSCluster.&lt;init&gt;(MiniDFSCluster.java:124)
>>>>>
>>>>> Patrick
>>>>>
>>>>> On Tue, Oct 23, 2012 at 2:43 PM, Patrick Hunt <phunt@apache.org>
wrote:
>>>>> > I pushed a small cleanup to versioning in the poms.
>>>>> >
>>>>> > Patrick
>>>>> >
>>>>> > On Tue, Oct 23, 2012 at 2:38 PM, Patrick Hunt <phunt@apache.org>
wrote:
>>>>> >> I'll work on fixing the tmp issue, that's something I can handle.
;-)
>>>>> >> Everything should be in target.
>>>>> >>
>>>>> >> Patrick
>>>>> >>
>>>>> >> On Tue, Oct 23, 2012 at 2:37 PM, Aaron McCurry <amccurry@gmail.com>
>>>>> wrote:
>>>>> >>> Hmm, I will take a look at that one next.
>>>>> >>>
>>>>> >>> Aaron
>>>>> >>>
>>>>> >>> On Tue, Oct 23, 2012 at 5:20 PM, Patrick Hunt <phunt@apache.org>
>>>>> wrote:
>>>>> >>>> Thanks Aaron. The other failing test "BlurClusterTest"
is somehow due
>>>>> >>>> to the directory used. "./tmp/cluster". If I change
to
>>>>> >>>> "file://tmp/cluster" the test passes. Any ideas? Seems
somehow
>>>>> related
>>>>> >>>> to using relative paths?
>>>>> >>>>
>>>>> >>>> Patrick
>>>>> >>>>
>>>>> >>>> On Tue, Oct 23, 2012 at 2:13 PM, Aaron McCurry <amccurry@gmail.com>
>>>>> wrote:
>>>>> >>>>> Found it, the test did not setup the indexing options
correctly.  I
>>>>> >>>>> have committed a fix for the test.
>>>>> >>>>>
>>>>> >>>>> Aaron
>>>>> >>>>>
>>>>> >>>>> On Tue, Oct 23, 2012 at 5:08 PM, Aaron McCurry <amccurry@gmail.com>
>>>>> wrote:
>>>>> >>>>>> After cleaning up the test, I have gotten the
same NPE.  Strange
>>>>> >>>>>> behavior, still working on why.
>>>>> >>>>>>
>>>>> >>>>>> Aaron
>>>>> >>>>>>
>>>>> >>>>>> On Tue, Oct 23, 2012 at 3:06 PM, Patrick Hunt
<phunt@apache.org>
>>>>> wrote:
>>>>> >>>>>>> NP. here's the output. I'm on ubuntu 12.04.
1.6.0_26
>>>>> >>>>>>>
>>>>> >>>>>>> "mvn clean test" results in: (I also removed
the tmp directories
>>>>> >>>>>>> manually, btw, we should move this to mvn
target  dir)
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> -------------------------------------------------------------------------------
>>>>> >>>>>>> Test set: org.apache.blur.utils.TermDocIterableTest
>>>>> >>>>>>>
>>>>> -------------------------------------------------------------------------------
>>>>> >>>>>>> Tests run: 1, Failures: 0, Errors: 1, Skipped:
0, Time elapsed:
>>>>> 0.005
>>>>> >>>>>>> sec <<< FAILURE!
>>>>> >>>>>>> testTermDocIterable(org.apache.blur.utils.TermDocIterableTest)
>>>>>  Time
>>>>> >>>>>>> elapsed: 0.005 sec  <<< ERROR!
>>>>> >>>>>>> java.lang.NullPointerException
>>>>> >>>>>>>         at
>>>>> org.apache.blur.utils.TermDocIterable.getNext(TermDocIterable.java:82)
>>>>> >>>>>>>         at
>>>>> org.apache.blur.utils.TermDocIterable.access$000(TermDocIterable.java:29)
>>>>> >>>>>>>         at
>>>>> org.apache.blur.utils.TermDocIterable$1.<init>(TermDocIterable.java:48)
>>>>> >>>>>>>         at
>>>>> org.apache.blur.utils.TermDocIterable.iterator(TermDocIterable.java:47)
>>>>> >>>>>>>         at
>>>>> org.apache.blur.utils.TermDocIterableTest.testTermDocIterable(TermDocIterableTest.java:65)
>>>>> >>>>>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>> Method)
>>>>> >>>>>>>         at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>> >>>>>>>         at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> >>>>>>>         at java.lang.reflect.Method.invoke(Method.java:597)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
>>>>> >>>>>>>         at
>>>>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
>>>>> >>>>>>>         at
>>>>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
>>>>> >>>>>>>         at
>>>>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
>>>>> >>>>>>>         at
>>>>> org.junit.runners.ParentRunner.run(ParentRunner.java:236)
>>>>> >>>>>>>         at
>>>>> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53)
>>>>> >>>>>>>         at
>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123)
>>>>> >>>>>>>         at
>>>>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104)
>>>>> >>>>>>>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>> Method)
>>>>> >>>>>>>         at
>>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>>> >>>>>>>         at
>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>>> >>>>>>>         at java.lang.reflect.Method.invoke(Method.java:597)
>>>>> >>>>>>>         at
>>>>> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164)
>>>>> >>>>>>>         at
>>>>> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110)
>>>>> >>>>>>>         at
>>>>> org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175)
>>>>> >>>>>>>         at
>>>>> org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107)
>>>>> >>>>>>>         at
>>>>> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68)
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>> On Tue, Oct 23, 2012 at 12:02 PM, Aaron
McCurry <
>>>>> amccurry@gmail.com> wrote:
>>>>> >>>>>>>> Sorry, just missed that message.  Hmm,
I will look around and
>>>>> try to
>>>>> >>>>>>>> see if I can find something.  Thanks.
>>>>> >>>>>>>>
>>>>> >>>>>>>> Aaron
>>>>> >>>>>>>>
>>>>> >>>>>>>> On Tue, Oct 23, 2012 at 2:59 PM, Patrick
Hunt <phunt@apache.org>
>>>>> wrote:
>>>>> >>>>>>>>> this is null in termdocsitertest
>>>>> >>>>>>>>>
>>>>> >>>>>>>>>         DocsEnum termDocs = atomicReader.termDocsEnum(new
>>>>> Term("id",
>>>>> >>>>>>>>> Integer.toString(id)));
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> due to fields() being null in termDocsEnum
method
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> I don't see why yet though. Given
the segment file exists on the
>>>>> >>>>>>>>> filesystem, etc...
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Patrick
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> On Tue, Oct 23, 2012 at 11:50 AM,
Aaron McCurry <
>>>>> amccurry@gmail.com> wrote:
>>>>> >>>>>>>>>> Trying to reproduce on Ubuntu.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> On Tue, Oct 23, 2012 at 1:58
PM, Patrick Hunt <
>>>>> phunt@apache.org> wrote:
>>>>> >>>>>>>>>>> Hm, I just updated and I'm
seeing two errors (which is 1 less
>>>>> issue
>>>>> >>>>>>>>>>> than before):
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> testTermDocIterable(org.apache.blur.utils.TermDocIterableTest)
>>>>> >>>>>>>>>>>   org.apache.blur.thrift.BlurClusterTest:
>>>>> java.lang.NullPointerException
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Let me look and see if I
can at least determine what the
>>>>> underlying
>>>>> >>>>>>>>>>> problems are.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Patrick
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> On Tue, Oct 23, 2012 at
10:12 AM, Aaron McCurry <
>>>>> amccurry@gmail.com> wrote:
>>>>> >>>>>>>>>>>> I ran into some errors
with ZookeeperClusterStatusTest tests
>>>>> and have
>>>>> >>>>>>>>>>>> resolved the issues
I found.  All units tests pass on OSX, I
>>>>> have not
>>>>> >>>>>>>>>>>> had a chance to run
them on Linux yet.  I also fixed the
>>>>> nasty NPE
>>>>> >>>>>>>>>>>> exception on the BlurClusterTest
(it was affecting the
>>>>> functional
>>>>> >>>>>>>>>>>> tests as well).  I ran
a few burn-in tests on a VM running a
>>>>> 2
>>>>> >>>>>>>>>>>> controller + 3 shard
server Blur cluster.  The tests
>>>>> included loaded
>>>>> >>>>>>>>>>>> data as fast as possibly
while running searches against that
>>>>> data as
>>>>> >>>>>>>>>>>> fast as possible.  The
tests ran without issue (basically
>>>>> like they
>>>>> >>>>>>>>>>>> did before the upgrade
to Lucene 4).  I feel like the code
>>>>> is in a
>>>>> >>>>>>>>>>>> good state at this point.
 I'm going to merge this code to
>>>>> master and
>>>>> >>>>>>>>>>>> create another branch
to begin modifying the RPC API.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Anyone have any objections?
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Aaron
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> On Mon, Oct 22, 2012
at 8:29 PM, Patrick Hunt <
>>>>> phunt@apache.org> wrote:
>>>>> >>>>>>>>>>>>> On Mon, Oct 22,
2012 at 5:23 PM, Aaron McCurry <
>>>>> amccurry@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>> Hmm.
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> On Mon, Oct
22, 2012 at 8:17 PM, Patrick Hunt <
>>>>> phunt@apache.org> wrote:
>>>>> >>>>>>>>>>>>>>> Sounds good
to me.
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Not sure
if anyone else is seeing this but the unit tests
>>>>> are not
>>>>> >>>>>>>>>>>>>>> passing
for me on ubuntu. I see one failure and two
>>>>> errors.
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Failed tests:
>>>>> >>>>>>>>>>>>>>>
>>>>>  testSafeModeSetInFuture(org.apache.blur.manager.clusterstatus.ZookeeperClusterStatusTest)
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Haven't seen
this.
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Tests in
error:
>>>>> >>>>>>>>>>>>>>>
>>>>> testTermDocIterable(org.apache.blur.utils.TermDocIterableTest)
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> This either.
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>   org.apache.blur.thrift.BlurClusterTest:
>>>>> java.lang.NullPointerException
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> I think I have
been seeing this one during some functional
>>>>> tests.
>>>>> >>>>>>>>>>>>>> Haven't figured
out the cause yet, but it seems like it's
>>>>> a nasty
>>>>> >>>>>>>>>>>>>> threading problem.
 Because when I drop the mutate threads
>>>>> back 1
>>>>> >>>>>>>>>>>>>> everything works
fine.  However the test was passing on
>>>>> OSX.
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Just me
or is this expected?
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Not expected.
 I'm going to setup a VM on computer to run
>>>>> tests in
>>>>> >>>>>>>>>>>>>> Linux as well.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Ok. Let me know
how it goes and I can try and debug it a
>>>>> bit, although
>>>>> >>>>>>>>>>>>> you're running much
faster than I can at this point. ;-)
>>>>> Definitely
>>>>> >>>>>>>>>>>>> let me know if you
can't reproduce it and I'll dig into it
>>>>> for sure.
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Patrick
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Patrick
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> On Sun,
Oct 21, 2012 at 10:38 AM, Aaron McCurry <
>>>>> amccurry@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>> We can
fix the jira issues.
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> On Sun,
Oct 21, 2012 at 1:36 PM, Garrett Barton
>>>>> >>>>>>>>>>>>>>>> <garrett.barton@gmail.com>
wrote:
>>>>> >>>>>>>>>>>>>>>>>
Sounds good to me Aaron, call it 0.2. Does that mess up
>>>>> Jira if you have
>>>>> >>>>>>>>>>>>>>>>>
things scheduled against releases?
>>>>> >>>>>>>>>>>>>>>>>
On Oct 21, 2012 9:44 AM, "Aaron McCurry" <
>>>>> amccurry@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>
Ok, I think it will be some time before all the
>>>>> changes for the new
>>>>> >>>>>>>>>>>>>>>>>>
api are in place and fully functional.  So perhaps we
>>>>> should merge the
>>>>> >>>>>>>>>>>>>>>>>>
lucene-4.0.0 branch into master and fix whatever bugs
>>>>> are found.  I
>>>>> >>>>>>>>>>>>>>>>>>
did some system testing yesterday and only found one
>>>>> big issue.  There
>>>>> >>>>>>>>>>>>>>>>>>
seems to be a threading problem with the BlurAnalyzer.
>>>>>  If a single
>>>>> >>>>>>>>>>>>>>>>>>
instance is in use across multiple threads some weird
>>>>> behaviors
>>>>> >>>>>>>>>>>>>>>>>>
happen.  Otherwise everything else seems to work,
>>>>> normally (I will
>>>>> >>>>>>>>>>>>>>>>>>
create a jira issue).
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>
If we do merge the lucene-4.0.0 branch, I feel like we
>>>>> should change
>>>>> >>>>>>>>>>>>>>>>>>
the version to 0.2.  The reason is, the indexes in
>>>>> 0.1.x are not going
>>>>> >>>>>>>>>>>>>>>>>>
to be backwards compatible (at least not with out some
>>>>> work).  Does
>>>>> >>>>>>>>>>>>>>>>>>
anyone have any strong feelings on this?
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>
Aaron
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>
On Sat, Oct 20, 2012 at 10:10 PM, Gagan Juneja
>>>>> >>>>>>>>>>>>>>>>>>
<gagandeepjuneja@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>
> I agree with Garrett. We can merge this branch to
>>>>> the place from where we
>>>>> >>>>>>>>>>>>>>>>>>
> cut it. Again as Garrett said If we want to keep
>>>>> only new api thing then
>>>>> >>>>>>>>>>>>>>>>>>
we
>>>>> >>>>>>>>>>>>>>>>>>
> can merge it to master as well.
>>>>> >>>>>>>>>>>>>>>>>>
>
>>>>> >>>>>>>>>>>>>>>>>>
> Regards,
>>>>> >>>>>>>>>>>>>>>>>>
> Gagan
>>>>> >>>>>>>>>>>>>>>>>>
>
>>>>> >>>>>>>>>>>>>>>>>>
> On Sat, Oct 20, 2012 at 9:50 PM, Garrett Barton <
>>>>> >>>>>>>>>>>>>>>>>>
garrett.barton@gmail.com>wrote:
>>>>> >>>>>>>>>>>>>>>>>>
>
>>>>> >>>>>>>>>>>>>>>>>>
>> I guess it depends on if your planning a 1.4
>>>>> release with lucene 4. If
>>>>> >>>>>>>>>>>>>>>>>>
yes
>>>>> >>>>>>>>>>>>>>>>>>
>> then merge and work towards making everything
>>>>> functional. If not then
>>>>> >>>>>>>>>>>>>>>>>>
leave
>>>>> >>>>>>>>>>>>>>>>>>
>> the 1.3.x in master for bug fixing or whatnot and
>>>>> merge this branch into
>>>>> >>>>>>>>>>>>>>>>>>
>> the new api one.
>>>>> >>>>>>>>>>>>>>>>>>
>> On Oct 20, 2012 11:03 AM, "Aaron McCurry" <
>>>>> amccurry@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>
>>
>>>>> >>>>>>>>>>>>>>>>>>
>> > I think that we can merge the lucene-4.0.0 branch
>>>>> back into the
>>>>> >>>>>>>>>>>>>>>>>>
>> > master, since tests and code are compiling.  I
>>>>> haven't done any
>>>>> >>>>>>>>>>>>>>>>>>
>> > functional testing yet, but if much of the RPC
>>>>> and internals are going
>>>>> >>>>>>>>>>>>>>>>>>
>> > to change I think that it may be a waste of time
>>>>> to test and fix
>>>>> >>>>>>>>>>>>>>>>>>
>> > everything that we are about to change.  What do
>>>>> others think?
>>>>> >>>>>>>>>>>>>>>>>>
>> >
>>>>> >>>>>>>>>>>>>>>>>>
>> > Aaron
>>>>> >>>>>>>>>>>>>>>>>>
>> >
>>>>> >>>>>>>>>>>>>>>>>>
>>
>>>>> >>>>>>>>>>>>>>>>>>
>>>>>
>>>>
>>>>

Mime
View raw message