Where do we stand with this?

I want to push to a 3.0.3 release, what items are still pending?

Itamar.

Agreed -
JIRA for 3.0.3 https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
We should evaluate all of these - fix them, mark as won't fix, or move them to another release version. I think the biggest hold up currently is: https://issues.apache.org/jira/browse/LUCENENET-484. Chris has made a huge dent, but there are two test cases that are still listed as failing (I can't even duplicate those failures to know where to start)
Also we should look at all the other jira tickets and make updates where appropriate
~P
> Date: Thu, 14 Jun 2012 13:21:04 +0300
> Subject: Releasing 3.0.3
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
>
> Where do we stand with this?
>
> I want to push to a 3.0.3 release, what items are still pending?
>
> Itamar.
     

Ok, and is the code in 100% compliance with the 3.0.3 Java code?

I'll be spending some time on fixing the index corruption issue, and it is
probably best for Chris to wrap up the work he has started

Anyone else on board to close some tickets?

On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

>
> Agreed -
> JIRA for 3.0.3
> https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
> We should evaluate all of these - fix them, mark as won't fix, or move
> them to another release version. I think the biggest hold up currently is:
> https://issues.apache.org/jira/browse/LUCENENET-484. Chris has made a
> huge dent, but there are two test cases that are still listed as failing (I
> can't even duplicate those failures to know where to start)
> Also we should look at all the other jira tickets and make updates where
> appropriate
> ~P
> > Date: Thu, 14 Jun 2012 13:21:04 +0300
> > Subject: Releasing 3.0.3
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> >
> > Where do we stand with this?
> >
> > I want to push to a 3.0.3 release, what items are still pending?
> >
> > Itamar.
>
>

I'm going to try and review some of them - looking at the 3.5 ticket atm. The code should be in compliance with 3.0.3. We might want to do some spot checking various parts of the code. I'm not sure about the tests. Also, we should probably run some code coverage tools to see how much coverage we have.
~P
> Date: Thu, 14 Jun 2012 18:37:12 +0300
> Subject: Re: Releasing 3.0.3
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
>
> Ok, and is the code in 100% compliance with the 3.0.3 Java code?
>
> I'll be spending some time on fixing the index corruption issue, and it is
> probably best for Chris to wrap up the work he has started
>
> Anyone else on board to close some tickets?
>
> On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:
>
> >
> > Agreed -
> > JIRA for 3.0.3
> > https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
> > We should evaluate all of these - fix them, mark as won't fix, or move
> > them to another release version. I think the biggest hold up currently is:
> > https://issues.apache.org/jira/browse/LUCENENET-484. Chris has made a
> > huge dent, but there are two test cases that are still listed as failing (I
> > can't even duplicate those failures to know where to start)
> > Also we should look at all the other jira tickets and make updates where
> > appropriate
> > ~P
> > > Date: Thu, 14 Jun 2012 13:21:04 +0300
> > > Subject: Releasing 3.0.3
> > > From: [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > >
> > > Where do we stand with this?
> > >
> > > I want to push to a 3.0.3 release, what items are still pending?
> > >
> > > Itamar.
> >
> >
     

I've been thinking about LUCENENET-493 (Make Lucene.Net culture
insensitive). It's easy to fix the code, and verify it on my machine
(running CurrentCulture=sv-SE), but there are no tests to confirm the
changes. I've been looking for ways to build test cases for different
cultures, like the overridden runBare method used originally in the java
code, but NUnit does not seem to have any such abilities within the
tests themselves.

1) It is possible to build NUnit addins that could execute every test
[with special annotation?] once for every culture. Resharper supports
NUnit addins, provided they are manually placed in the correct folder
under the resharper application folder.
2) We could rewrite culture sensitive tests into method that holds the
logic, and several test methods with [SetCulture("...")], but this
requires knowledge about what tests are culture sensitive. We could also
rewrite every method into a foreach-loop, executing the test logic with
every culture.
3) Change unit testing framework.

Any thoughts?

On 2012-06-14 17:58, Prescott Nasser wrote:
> I'm going to try and review some of them - looking at the 3.5 ticket atm. The code should be in compliance with 3.0.3. We might want to do some spot checking various parts of the code. I'm not sure about the tests. Also, we should probably run some code coverage tools to see how much coverage we have.
> ~P
>> Date: Thu, 14 Jun 2012 18:37:12 +0300
>> Subject: Re: Releasing 3.0.3
>> From: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
>>
>> Ok, and is the code in 100% compliance with the 3.0.3 Java code?
>>
>> I'll be spending some time on fixing the index corruption issue, and it is
>> probably best for Chris to wrap up the work he has started
>>
>> Anyone else on board to close some tickets?
>>
>> On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser<[EMAIL PROTECTED]>wrote:
>>
>>> Agreed -
>>> JIRA for 3.0.3
>>> https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel
>>> We should evaluate all of these - fix them, mark as won't fix, or move
>>> them to another release version. I think the biggest hold up currently is:
>>> https://issues.apache.org/jira/browse/LUCENENET-484. Chris has made a
>>> huge dent, but there are two test cases that are still listed as failing (I
>>> can't even duplicate those failures to know where to start)
>>> Also we should look at all the other jira tickets and make updates where
>>> appropriate
>>> ~P
>>>> Date: Thu, 14 Jun 2012 13:21:04 +0300
>>>> Subject: Releasing 3.0.3
>>>> From: [EMAIL PROTECTED]
>>>> To: [EMAIL PROTECTED]
>>>>
>>>> Where do we stand with this?
>>>>
>>>> I want to push to a 3.0.3 release, what items are still pending?
>>>>
>>>> Itamar.
>>>
>

I can't guarantee that the code is 100% in compliance with java 3.0.3.  All
changes that could be ported have been ported in core and most contrib
projects.  There are a few things that should at least be discussed
regarding the compatibility in core:

Occur (BooleanClause) in java is converted to an enum, from static readonly
methods on a class.  The reason that was never ported was because we can't
override ToString() on an enum, even with extension methods and/or type
converters.  Currently, "MUST" evaluates to "+", SHOULD to "", and
"MUST_NOT" to "-".  I'd double check this, but I think that the ToString()
on occur is only used when creating string representations of a query.  So,
in theory, we could replace the usages in that location, and make the
conversion to enum.  This isn't a high-priority, especially since the
fields are static readonly, this likely doesn't affect performance much or
at all.

FuzzyQuery uses java.util.PriorityQueue<T> which doesn't exists in .NET.  I
think we wind up using a SortedList, which was just a temporary measure
that I wanted to make sure was fixed before release.  I've tried to
subclass from Util.PriorityQueue<T>, but it breaks a few tests.  The
current setup with SortedList works fine, but it's slower O(n) instead of
O(log n) I think for some actions, and it doesn't support duplicate
keys...which is bad.

SegmentInfos inherits from a thread-safe collection in java (Vector).  We
could have used SynchronizedCollection<T> and inherit from that, but I
chose not to.  I'm don't actually believe that lucene relies on the fact
that Vector is ThreadSafe; instead, handling synchronization on its own.
 However, it's worth checking into, even though there are no tests that
fail.  Perhaps try to write one?  IDK, there's a lot of multi-threaded
tests, and I've yet to see a failure that's related to this.  All
intermittent tests that currently fail, do so for other reasons.  Also, in
this class, there are a few places where it should be returning a read-only
HashSet, instead of returning a mutable one.

==================Open issues:

I wanted to talk about the issues that are assigned, but just haven't had
time.  I think we really need to triage what is actually important and
focus on that.  I think I'll briefly just comment on a few of these and I
hope to find out what you guys think of the open issues as well.

I think can be moved to 3.5:
========================LUCENENET- 439 - Correctly Rethrow exceptions in C#
LUCENENET- 436 - Refactor Deprecated Code inside of tests
LUCENENET- 435 - Fix the test suite for Lucene.Net Core (java lucene has
refactored a lot of their test suite.  I think this should be backlogged)
LUCENENET- 467 - .NETify the public API where appropriate
-- Some of this has already been done, but it's not critical to a release.
LUCENENET- 456 -  Create a Build Target that outputs compiled artifacts in
apache release format

These are of medium importance
========================LUCENENET- 446 - Make Lucene.Net CLS Compliant
-- The major issues with this have been more-or-less solved.  The basic
public API is almost completely CLS-compliant, except for usages of sbyte
in FieldCacheRangeFilter and VerifyingLockFactory.  Almost all classes can
be used in other languages.  There are 58 CLS naming issues, but most of
them deal with protected members.  If consumers were to use the library as
is without customization, it's not blocking.  However, it's not ideal to
leave these issues in the release.
LUCENENET- 337 - TokenAttribute for Selectively Including Tokens in Length
Norm
-- This is just a patch.  I'm actually not sure what it does, so I haven't
committed it to trunk because of that.

High priority: These should be fixed or looked over before releasing
========================LUCENENET- 484 - Some possibly major tests intermittently fail
-- Obviously, we should try and have a test suite that consistently passes.
 There are only two that fail now, I think.
LUCENENET- 493 - Make lucene.net culture insensitive (like the java version)
LUCENENET- 490 - QueryParser is culture-sensitive
lucene is culture insensitive, though, and until I do some tests, I don't
want to jump in and start changing things.  There are culture sensitive
tests in the test suite, but they don't run because of JUnit and NUnit
differences.
LUCENENET- 470 - Change Getxxx() and Setxxx() methods to .NET Properties
this should be updated.  I only put this in high priority, because the API
changes between 2.9 and 3.x are the perfect time to do this.  Almost all
obvious ones have been changed already.  There are a few others like
[typename].Size() that could probably be changed as well, but those would
have to be manually found.

Other's opinions and insights are appreciated.
Thanks,
Christopher

On Thu, Jun 14, 2012 at 8:58 AM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

Something like:

Thread.CurrentThread.CurrentCulture = cultureInfo;
Thread.CurrentThread.CurrentUICulture = cultureInfo;

And setting it back later when the test is done.

You can easily do this with an IDisposable like this:

using(new TemporaryCulture(culture)){
...
}

On Thu, Jun 14, 2012 at 9:10 PM, Simon Svensson <[EMAIL PROTECTED]> wrote:

> I've been thinking about LUCENENET-493 (Make Lucene.Net culture
> insensitive). It's easy to fix the code, and verify it on my machine
> (running CurrentCulture=sv-SE), but there are no tests to confirm the
> changes. I've been looking for ways to build test cases for different
> cultures, like the overridden runBare method used originally in the java
> code, but NUnit does not seem to have any such abilities within the tests
> themselves.
>
> 1) It is possible to build NUnit addins that could execute every test
> [with special annotation?] once for every culture. Resharper supports NUnit
> addins, provided they are manually placed in the correct folder under the
> resharper application folder.
> 2) We could rewrite culture sensitive tests into method that holds the
> logic, and several test methods with [SetCulture("...")], but this requires
> knowledge about what tests are culture sensitive. We could also rewrite
> every method into a foreach-loop, executing the test logic with every
> culture.
> 3) Change unit testing framework.
>
> Any thoughts?
>
>
> On 2012-06-14 17:58, Prescott Nasser wrote:
>
>> I'm going to try and review some of them - looking at the 3.5 ticket atm.
>> The code should be in compliance with 3.0.3. We might want to do some spot
>> checking various parts of the code. I'm not sure about the tests. Also, we
>> should probably run some code coverage tools to see how much coverage we
>> have.
>> ~P
>>
>>> Date: Thu, 14 Jun 2012 18:37:12 +0300
>>> Subject: Re: Releasing 3.0.3
>>> From: [EMAIL PROTECTED]
>>> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
>>>
>>> Ok, and is the code in 100% compliance with the 3.0.3 Java code?
>>>
>>> I'll be spending some time on fixing the index corruption issue, and it
>>> is
>>> probably best for Chris to wrap up the work he has started
>>>
>>> Anyone else on board to close some tickets?
>>>
>>> On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser<[EMAIL PROTECTED]>*
>>> *wrote:
>>>
>>>  Agreed -
>>>> JIRA for 3.0.3
>>>> https://issues.apache.org/**jira/browse/LUCENENET/**
>>>> fixforversion/12316215#**selectedTab=com.atlassian.**
>>>> jira.plugin.system.project%**3Aversion-issues-panel<https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel>
>>>> We should evaluate all of these - fix them, mark as won't fix, or move
>>>> them to another release version. I think the biggest hold up currently
>>>> is:
>>>> https://issues.apache.org/**jira/browse/LUCENENET-484<https://issues.apache.org/jira/browse/LUCENENET-484>.
>>>> Chris has made a
>>>> huge dent, but there are two test cases that are still listed as
>>>> failing (I
>>>> can't even duplicate those failures to know where to start)
>>>> Also we should look at all the other jira tickets and make updates where
>>>> appropriate
>>>> ~P
>>>>
>>>>> Date: Thu, 14 Jun 2012 13:21:04 +0300
>>>>> Subject: Releasing 3.0.3
>>>>> From: [EMAIL PROTECTED]
>>>>> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
>>>>>
>>>>> Where do we stand with this?
>>>>>
>>>>> I want to push to a 3.0.3 release, what items are still pending?
>>>>>
>>>>> Itamar.
>>>>>
>>>>
>>>>
>>
>
>

Sorry, misread your question

This can be easily done with xUnit, using Theories.

On Thu, Jun 14, 2012 at 9:26 PM, Itamar Syn-Hershko <[EMAIL PROTECTED]>wrote:

> Something like:
>
> Thread.CurrentThread.CurrentCulture = cultureInfo;
> Thread.CurrentThread.CurrentUICulture = cultureInfo;
>
> And setting it back later when the test is done.
>
> You can easily do this with an IDisposable like this:
>
> using(new TemporaryCulture(culture)){
> ...
> }
>
> On Thu, Jun 14, 2012 at 9:10 PM, Simon Svensson <[EMAIL PROTECTED]> wrote:
>
>> I've been thinking about LUCENENET-493 (Make Lucene.Net culture
>> insensitive). It's easy to fix the code, and verify it on my machine
>> (running CurrentCulture=sv-SE), but there are no tests to confirm the
>> changes. I've been looking for ways to build test cases for different
>> cultures, like the overridden runBare method used originally in the java
>> code, but NUnit does not seem to have any such abilities within the tests
>> themselves.
>>
>> 1) It is possible to build NUnit addins that could execute every test
>> [with special annotation?] once for every culture. Resharper supports NUnit
>> addins, provided they are manually placed in the correct folder under the
>> resharper application folder.
>> 2) We could rewrite culture sensitive tests into method that holds the
>> logic, and several test methods with [SetCulture("...")], but this requires
>> knowledge about what tests are culture sensitive. We could also rewrite
>> every method into a foreach-loop, executing the test logic with every
>> culture.
>> 3) Change unit testing framework.
>>
>> Any thoughts?
>>
>>
>> On 2012-06-14 17:58, Prescott Nasser wrote:
>>
>>> I'm going to try and review some of them - looking at the 3.5 ticket
>>> atm. The code should be in compliance with 3.0.3. We might want to do some
>>> spot checking various parts of the code. I'm not sure about the tests.
>>> Also, we should probably run some code coverage tools to see how much
>>> coverage we have.
>>> ~P
>>>
>>>> Date: Thu, 14 Jun 2012 18:37:12 +0300
>>>> Subject: Re: Releasing 3.0.3
>>>> From: [EMAIL PROTECTED]
>>>> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
>>>>
>>>> Ok, and is the code in 100% compliance with the 3.0.3 Java code?
>>>>
>>>> I'll be spending some time on fixing the index corruption issue, and it
>>>> is
>>>> probably best for Chris to wrap up the work he has started
>>>>
>>>> Anyone else on board to close some tickets?
>>>>
>>>> On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser<[EMAIL PROTECTED]>
>>>> **wrote:
>>>>
>>>>  Agreed -
>>>>> JIRA for 3.0.3
>>>>> https://issues.apache.org/**jira/browse/LUCENENET/**
>>>>> fixforversion/12316215#**selectedTab=com.atlassian.**
>>>>> jira.plugin.system.project%**3Aversion-issues-panel<https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel>
>>>>> We should evaluate all of these - fix them, mark as won't fix, or move
>>>>> them to another release version. I think the biggest hold up currently
>>>>> is:
>>>>> https://issues.apache.org/**jira/browse/LUCENENET-484<https://issues.apache.org/jira/browse/LUCENENET-484>.
>>>>> Chris has made a
>>>>> huge dent, but there are two test cases that are still listed as
>>>>> failing (I
>>>>> can't even duplicate those failures to know where to start)
>>>>> Also we should look at all the other jira tickets and make updates
>>>>> where
>>>>> appropriate
>>>>> ~P
>>>>>
>>>>>> Date: Thu, 14 Jun 2012 13:21:04 +0300
>>>>>> Subject: Releasing 3.0.3
>>>>>> From: [EMAIL PROTECTED]
>>>>>> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
>>>>>>
>>>>>> Where do we stand with this?
>>>>>>
>>>>>> I want to push to a 3.0.3 release, what items are still pending?
>>>>>>
>>>>>> Itamar.
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>

I don't have any ideas for this, but I looked around at them myself.
 You'll notice in TestQueryParser.cs, it inherits from LocalizedTestCase,
which is good.  It means that we should be able to identify fairly easily
which unit tests should be localized.  However, there is no automated way
to do this as in Java (as you mentioned correctly, using runBare).  I've
looked into it a bit, and while you can add attributes to NUnit that will
run a test under a different culture.  However, NUnit doesn't yet support
adding multiple cultures to a single test (MbUnit does support this
feature).

Out of the solutions you've suggested, I wouldn't want to change unit
testing frameworks at this point and I'm not sure if an NUnit addin would
work.  Rewriting it seems to be the best option, however we might decide to
do it.

Alternatively, we could try and add the functionality into NUnit and commit
it back to that project, which would be even better, as it would benefit
both projects.
Thanks,
Christopher

On Thu, Jun 14, 2012 at 11:10 AM, Simon Svensson <[EMAIL PROTECTED]> wrote:

> I've been thinking about LUCENENET-493 (Make Lucene.Net culture
> insensitive). It's easy to fix the code, and verify it on my machine
> (running CurrentCulture=sv-SE), but there are no tests to confirm the
> changes. I've been looking for ways to build test cases for different
> cultures, like the overridden runBare method used originally in the java
> code, but NUnit does not seem to have any such abilities within the tests
> themselves.
>
> 1) It is possible to build NUnit addins that could execute every test
> [with special annotation?] once for every culture. Resharper supports NUnit
> addins, provided they are manually placed in the correct folder under the
> resharper application folder.
> 2) We could rewrite culture sensitive tests into method that holds the
> logic, and several test methods with [SetCulture("...")], but this requires
> knowledge about what tests are culture sensitive. We could also rewrite
> every method into a foreach-loop, executing the test logic with every
> culture.
> 3) Change unit testing framework.
>
> Any thoughts?
>
>
> On 2012-06-14 17:58, Prescott Nasser wrote:
>
>> I'm going to try and review some of them - looking at the 3.5 ticket atm.
>> The code should be in compliance with 3.0.3. We might want to do some spot
>> checking various parts of the code. I'm not sure about the tests. Also, we
>> should probably run some code coverage tools to see how much coverage we
>> have.
>> ~P
>>
>>> Date: Thu, 14 Jun 2012 18:37:12 +0300
>>> Subject: Re: Releasing 3.0.3
>>> From: [EMAIL PROTECTED]
>>> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
>>>
>>> Ok, and is the code in 100% compliance with the 3.0.3 Java code?
>>>
>>> I'll be spending some time on fixing the index corruption issue, and it
>>> is
>>> probably best for Chris to wrap up the work he has started
>>>
>>> Anyone else on board to close some tickets?
>>>
>>> On Thu, Jun 14, 2012 at 6:19 PM, Prescott Nasser<[EMAIL PROTECTED]>*
>>> *wrote:
>>>
>>>  Agreed -
>>>> JIRA for 3.0.3
>>>> https://issues.apache.org/**jira/browse/LUCENENET/**
>>>> fixforversion/12316215#**selectedTab=com.atlassian.**
>>>> jira.plugin.system.project%**3Aversion-issues-panel<https://issues.apache.org/jira/browse/LUCENENET/fixforversion/12316215#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel>
>>>> We should evaluate all of these - fix them, mark as won't fix, or move
>>>> them to another release version. I think the biggest hold up currently
>>>> is:
>>>> https://issues.apache.org/**jira/browse/LUCENENET-484<https://issues.apache.org/jira/browse/LUCENENET-484>.
>>>> Chris has made a
>>>> huge dent, but there are two test cases that are still listed as
>>>> failing (I
>>>> can't even duplicate those failures to know where to start)
>>>> Also we should look at all the other jira tickets and make updates where
>>>> appropriate
>>>> ~P
>>>>
>>>>> Date: Thu, 14 Jun 2012 13:21:04 +0300