lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Aroush" <geo...@aroush.net>
Subject RE: [jira] Commented: (LUCENENET-249) Many bugs fix patch
Date Mon, 16 Nov 2009 05:35:04 GMT
Hi Andrei,

We can't just accept code without close review, so #1 is out.  Option #2, can help us, but
a better 3rd option is my suggestion that I made in the JIRA issue.  I believe you are in
a much better position to take advantage of #2 than we are.

Thanks.

-- George

-----Original Message-----
From: xzxz@mail.ru [mailto:xzxz@mail.ru] 
Sent: Sunday, November 15, 2009 9:20 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: [jira] Commented: (LUCENENET-249) Many bugs fix patch

Thanks, Digy
I got log messages from  TortoiseSVN. I 've got 52 revision from 
2009-11-06 up to now. Each has from 1 to 30 files changes. Uf... I can 
not handle it.
I see 2 possibilities:
1) Shortest way:
Test my code and if it is ok then  just replace the trunk Or
2) Longest way:
Use my code as a  clue to find out what has to be fixed in current trunk.
---------
Andrei

Digy wrote:
> Hi Andrei, You can see the commits and changes made to the code using svn.
> If you are using TortoiseSVN just use "Show Log".
>
> DIGY.
>
> -----Original Message-----
> From: xzxz@mail.ru [mailto:xzxz@mail.ru] 
> Sent: Sunday, November 15, 2009 3:04 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (LUCENENET-249) Many bugs fix patch
>
> Hi, Digy
>
> I was (and I am) quite sure it is hard to join current trunk and 
> proposed fixes. Sorry, but I don't know how to make smaller patches 
> (there so many changes - alfa code was too buggy)
>
> I think it would be easy if there is  a complete list of patches made 
> from first release of the 2.9.0 build 1 alfa (2009-10-26). Then it would 
> be possible  to check  if this patches are used in my patch.
> And, of course, I am ready to answer on questions.
> ----------
> Andrei
>
> Digy (JIRA) wrote:
>   
>>     [ https://issues.apache.org/jira/browse/LUCENENET-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778089#action_12778089
] 
>>
>> Digy commented on LUCENENET-249:
>> --------------------------------
>>
>> Hi Andrei,
>>
>> Thanks for your work but;
>>
>> -Some changes in your patch have already been committed to trunk, some others have
been solved in a different way.
>>
>> -There are places where the whole method is deleted and replaced with a new one.
This makes harder to understand the changes.
>>
>> -It is hard to use your patch unless we replace the trunk with your code.
>>
>> Can you post smaller patches addressing a specific issue?
>>
>> DIGY
>>
>>
>>
>>
>>
>>
>>
>>   
>>     
>>> Many bugs fix patch
>>> -------------------
>>>
>>>                 Key: LUCENENET-249
>>>                 URL: https://issues.apache.org/jira/browse/LUCENENET-249
>>>             Project: Lucene.Net
>>>          Issue Type: Bug
>>>            Reporter: Iliev Andrei
>>>         Attachments: comprehensive.patch, lucene2.9.0fixed.zip
>>>
>>>
>>> All  Nunit test are passed (actually, some tests fail if run the whole tests
but does not fail if runned individulally. probably it is related with Nunit itself),
>>> except for:
>>> 1)  Lucene.Net.Index.TestDeletionPolicy.TestKeepAllDeletionPolicy
>>> commits.Count=15 but was expected 14
>>> 2) Lucene.Net.QueryParsers.TestQueryParser.TestCJK:
>>> Shoud be yeasly fixed for Japanese people.
>>> 3)3 tests in  Lucene.Net.Search.Function.TestCustomScoreQuery
>>> -Lucene.Net.Search.Function.TestCustomScoreQuery.TestCustomScoreFloat:
>>> -Lucene.Net.Search.Function.TestCustomScoreQuery.TestCustomScoreInt:
>>> -Lucene.Net.Search.Function.TestCustomScoreQuery.TestCustomScoreShort:
>>> Slight difference with the expected scores.
>>> Some notes:
>>> 1) Added support  for java NIO  (I ported java ByteBuffer/CharBuffer) -> new
directory JavaSupport.
>>> 2) Added new classes in SupportClass.cs
>>> I think it is  time to put all support classes in files in separate directory
(ex. JavaSupport).  What do you think about it?
>>> 3) I found that some public methods in DateTools that accept long time argument,
 does not use it as milliseconds since January 1, 1970, 00:00:00 GMT (as it is stated in the
documentation).
>>> I think it  is not good (it diverges form java lucene). So I fixed it. 
>>>     
>>>       
>>   
>>     
>
>
>
>   



Mime
View raw message