incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: [VOTE] Merge lucene-4.0.0 branch to master
Date Wed, 24 Oct 2012 20:45:19 GMT
+1

Sent from my iPhone

On Oct 24, 2012, at 4:40 PM, Patrick Hunt <phunt@apache.org> wrote:

> 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