Alright,

 

While you all take a look at the artifacts for a vote - I wanted to talk about the future roadmap and our releases -

 

2.9.4g is very stable - do we want to release this at some point?

3.0.3 - chris looks to be pretty active on this. Chris, can you fill us in on what's the status of this branch?

4.0 - looks to be partially underway.

 

I want to try and maybe build a better release schedule and begin filling out what needs to be done so people can easily jump in and help out. I noticed the 4.0 status page in the wiki - that's excellent

 

~P    

Anyone have any thoughts on these items?

 

My 2 cents is that after we get 2.9.4 out the door, we quickly release a 2.9.4g (Digy - you're probably most familiar with 2.9.4g, is there any work that we should do to that to get it solid for a release?

 

I'm still unsure the status of 3.0.3 or 4.0, but I'm thinking for the next release in Q1 2012.

 

 

 

>
>
> While you all take a look at the artifacts for a vote - I wanted to talk about the future roadmap and our releases -
>
>
>
> 2.9.4g is very stable - do we want to release this at some point?
>
> 3.0.3 - chris looks to be pretty active on this. Chris, can you fill us in on what's the status of this branch?
>
> 4.0 - looks to be partially underway.
>
>
>
> I want to try and maybe build a better release schedule and begin filling out what needs to be done so people can easily jump in and help out. I noticed the 4.0 status page in the wiki - that's excellent
>
>
>
> ~P    

Regarding the 3.0.3 branch I started last week, I've put in a lot of late
nights and gotten far more done in a week and a half than I expected.  The
list of changes is very large, and fortunately, I've documented it in some
files that are in the branches root of certain projects.  I'll list what
changes have been made so far, and some of the concerns I have about them,
as well as what still needs to be done.  You can read them all in detail in
the files that are in the branch.

All changes in 3.0.3 have been ported to the Lucene.Net and
Lucene.Net.Test, except BooleanClause, LockStressTest, MMapDirectory,
NIOFSDirectory, DummyConcurrentLock, NamedThreadFactory, and
ThreadInterruptedException.

MMapDirectory and NIOFSDirectory have never been ported in the first place
for 2.9.4, so I'm not worried about those.  LockStressTest is a
command-line tool, porting it should be easy, but not essential to a 3.0.3
release, IMO.  DummyConcurrentLock also seems unnecessary (and
non-portable) for .NET, since it's based around Java's Lock class and is
only used to bypass locking, which can be done by passing new Object() to
the method.
NamedThreadFactory I'm unsure about.  It's used in ParallelMultiSearcher
(in which I've opted to use the TPL), and seems to be only used for
debugging, possibly testing.  Either way, I'm not sure it's necessary.
 Also, named threads would mean we probably would have to move the class
from the TPL, which greatly simplified the code and parallelization of it
all, as I can't see a way to Set names for a Task.  I suppose it might be
possible, as Tasks have unique Ids, and you could use a Dictionary to map
the thread's name to the ID in the factory, but you'd have to create a
helper function that would allow you to find a task by its name, which
seems more work than the resulting benefits.  VS2010 already has better
support for debugging tasks over threads (I used it when writing the
class), frankly, it's amazing how easy it was to debug.

Other than the above, the entire code base in the core dlls is at 3.0.3,
which is exciting, as I'm really hoping we can get Lucene.Net up to the
current version of Java's 3.x branch, and start working on a line-by-line
port of 4.0.  Tests need to be written for some of the collections I've
made that emulate Java's, to make sure they're even behaving the same way.
 The good news is that all of the existing tests pass as a whole, so it
seems to be working, though I'd like the peace of mind of having tests for
them (being HashMap<TKey, TValue>, WeakDictionary<TKey, TValue> and
IdentityCollection<TKey, TValue>, it's quite possible any one of them could
be completely wrong in how they were put together.)

I'd also like to finally formalize the way we use IDisposable in
Lucene.Net, by marking the Close functions as obsolete, moving the code
into Dispose, and eventually (or immediately) removing the Close functions.
 There's so much change to the API, that now would be a good time to make
that change if we wanted to.  I'm hesitant to move from a line-by-line port
of Lucene.Net completely, but rather having it be close as possible.  The
main reason I feel this way, is when I was porting the Shingle namespace of
Contrib.Analyzers, Troy has written it in a .Net way which different
GREATLY from java lucene, and it did make porting it considerably more
difficult; to keep the language to a minimum, I'm just going to say it was
a pain, a huge pain in fact.  I love the idea of moving to a more .NET
design, but I'd like to maintain a line-by-line port anyway, as I think
porting changes is far easier and quicker that way.  At this point, I'm
more interested in getting Lucene.Net to 4.0 and caught up to java, than I
am anything else, hence the extra amount of time I've put into this project
over the past week and a half.  Though this isn't really a place for this
discussion.

The larger area of difficult for the port, however, is the Contrib section.
 There are two major problems with it that is slowing me down.  First,
there are a lot of classes that are outdated.  I've found versions of code
that still have the Apache 1.1 License attached to it, which makes the code
quite old.  Also, it was almost impossible for me to port a lot of changes
in Contrib.Analyzers, since the code was so old and different from Java's
2.9.4.

Second, we had almost no unit tests ported for any of the classes, which
means they have to be ported from scratch.

Third, there are a lot of contrib projects that have never been ported over
from java.  That list includes: smartcn (I believe this is an intelligent
Chinese analyzer), benchmark, collation, db, lucli, memory, misc,
queryparser, remote, surround, swing, wikipedia, xml-query-parser.
 However, it should be noted that I'm not even sure which, if any, SHOULD
be ported or even CAN be ported.

The progress on 3.0.3 Contrib is going steady, however.  The entire
Analyzers project (except for smartcn) has been ported, as well as the test
for them, which all pass.  There were some minor exceptions, the
ThaiAnalyzer and hyphenation analyzers that could not be ported,
ThaiAnalyzer because it relies on BreakIterator, and there's no built-in
functionality to split a string by words based on a culture in .NET, and no
third party library I could find that easily does it, and Hyphenation,
because it relies on SAX xml processing, which is also missing from .NET.

The FastVectorHighlighter project has also had all 3.0.3 changes ported to
the project and it's Tests, as well, all passing.  All other projects in
contrib have yet to be touched/ported.

You can find some of my notes scattered about in // TODO comments, but most
centralized in the project directories:

src\core\FileDiffs.txt
src\core\ChangeNotes.txt
src\contrib\Analyzers\FileDiffs.txt
test\core\UpdatedTests.txt
test\contrib\analyzers\PortedTests.txt

If, and by if I mean when, you find porting errors, let me know and fix
them or have me fix them, or whatever you want to do.  The thin

+1 on the suggestion to move Close -> IDisposable; not being able to use
"using" is such a pain, and an eyesore on the code.
Although it will have to be done properly, and not just have Dispose call
Close (you should have proper protected virtual Dispose methods to take
inheritance into account, etc).
- Nick

----------------------------------------

From: "Christopher Currens" <[EMAIL PROTECTED]>

Sent: Monday, November 21, 2011 2:56 PM

To: [EMAIL PROTECTED]

Subject: Re: [Lucene.Net] Roadmap
Regarding the 3.0.3 branch I started last week, I've put in a lot of late

nights and gotten far more done in a week and a half than I expected.  The

list of changes is very large, and fortunately, I've documented it in some

files that are in the branches root of certain projects.  I'll list what

changes have been made so far, and some of the concerns I have about them,

as well as what still needs to be done.  You can read them all in detail
in

the files that are in the branch.
All changes in 3.0.3 have been ported to the Lucene.Net and

Lucene.Net.Test, except BooleanClause, LockStressTest, MMapDirectory,

NIOFSDirectory, DummyConcurrentLock, NamedThreadFactory, and

ThreadInterruptedException.
MMapDirectory and NIOFSDirectory have never been ported in the first place

for 2.9.4, so I'm not worried about those.  LockStressTest is a

command-line tool, porting it should be easy, but not essential to a 3.0.3

release, IMO.  DummyConcurrentLock also seems unnecessary (and

non-portable) for .NET, since it's based around Java's Lock class and is

only used to bypass locking, which can be done by passing new Object() to

the method.

NamedThreadFactory I'm unsure about.  It's used in ParallelMultiSearcher

(in which I've opted to use the TPL), and seems to be only used for

debugging, possibly testing.  Either way, I'm not sure it's necessary.

Also, named threads would mean we probably would have to move the class

from the TPL, which greatly simplified the code and parallelization of it

all, as I can't see a way to Set names for a Task.  I suppose it might be

possible, as Tasks have unique Ids, and you could use a Dictionary to map

the thread's name to the ID in the factory, but you'd have to create a

helper function that would allow you to find a task by its name, which

seems more work than the resulting benefits.  VS2010 already has better

support for debugging tasks over threads (I used it when writing the

class), frankly, it's amazing how easy it was to debug.
Other than the above, the entire code base in the core dlls is at 3.0.3,

which is exciting, as I'm really hoping we can get Lucene.Net up to the

current version of Java's 3.x branch, and start working on a line-by-line

port of 4.0.  Tests need to be written for some of the collections I've

made that emulate Java's, to make sure they're even behaving the same way.

The good news is that all of the existing tests pass as a whole, so it

seems to be working, though I'd like the peace of mind of having tests for

them (being HashMap<TKey, TValue>, WeakDictionary<TKey, TValue> and

IdentityCollection<TKey, TValue>, it's quite possible any one of them
could

be completely wrong in how they were put together.)
I'd also like to finally formalize the way we use IDisposable in

Lucene.Net, by marking the Close functions as obsolete, moving the code

into Dispose, and eventually (or immediately) removing the Close
functions.

There's so much change to the API, that now would be a good time to make

that change if we wanted to.  I'm hesitant to move from a line-by-line
port

of Lucene.Net completely, but rather having it be close as possible.  The

main reason I feel this way, is when I was porting the Shingle namespace
of

Contrib.Analyzers, Troy has written it in a .Net way which different

GREATLY from java lucene, and it did make porting it considerably more

difficult; to keep the language to a minimum, I'm just going to say it was

a pain, a huge pain in fact.  I love the idea of moving to a more .NET

design, but I'd like to maintain a line-by-line port anyway, as I think

porting changes is far easier and quicker that way.  At this point, I'm

more interested in getting Lucene.Net to 4.0 and caught up to java, than I

am anything else, hence the extra amount of time I've put into this
project

over the past week and a half.  Though this isn't really a place for this

discussion.
The larger area of difficult for the port, however, is the Contrib
section.

There are two major problems with it that is slowing me down.  First,

there are a lot of classes that are outdated.  I've found versions of code

that still have the Apache 1.1 License attached to it, which makes the
code

quite old.  Also, it was almost impossible for me to port a lot of changes

in Contrib.Analyzers, since the code was so old and different from Java's

2.9.4.
Second, we had almost no unit tests ported for any of the classes, which

means they have to be ported from scratch.
Third, there are a lot of contrib projects that have never been ported
over

from java.  That list includes: smartcn (I believe this is an intelligent

Chinese analyzer), benchmark, collation, db, lucli, memory, misc,

queryparser, remote, surround, swing, wikipedia, xml-query-parser.

However, it should be noted that I'm not even sure which, if any, SHOULD

be ported or even CAN be ported.
The progress on 3.0.3 Contrib is going steady, however.  The entire

Analyzers project (except for smartcn) has been ported, as well as the
test

for them, which all pass.  There were some minor exceptions, the

ThaiAnalyzer and hyphenation analyzers that could not be ported,

ThaiAnalyzer because it relies on BreakIterator, and there's no built-in

functionality to split a string by words based on a culture in .NET, and
no

third party library I could find that easily does it, and Hyphenation,

because it relies on SAX xml processing, which is a

Some of the Lucene classes have Dispose methods, well, ones that call Close
(and that Close method may or may not call base.Close(), if needed or not).
 Virtual dispose methods can be dangerous only in that they're easy to
implement wrong.  However, it shouldn't be too bad, at least with a
line-by-line port, as we would make the call to the base class whenever
Lucene does, and that would (should) give us the same behavior, implemented
properly.  I'm not aware of differences in the JVM, regarding inheritance
and base methods being called automatically, particularly Close methods.

Slightly unrelated, another annoyance is the use of Java Iterators vs C#
Enumerables.  A lot of our code is there simply because there are
Iterators, but it could be converted to Enumerables. The whole HasNext,
Next vs C#'s MoveNext(), Current is annoying, but it's used all over in the
base code, and would have to be changed there as well.  Either way, I would
like to push for that before 3.0.3 is relased.  IMO, small changes like
this still keep the code similar to the line-by-line port, in that it
doesn't add any difficulties in the porting process, but provides great
benefits to the users of the code, to have a .NET centric API.  I don't
think it would violate our project desciption we have listed on our
Incubator page, either.
Thanks,
Christopher

On Mon, Nov 21, 2011 at 12:03 PM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:

> +1 on the suggestion to move Close -> IDisposable; not being able to use
> "using" is such a pain, and an eyesore on the code.
>
>
> Although it will have to be done properly, and not just have Dispose call
> Close (you should have proper protected virtual Dispose methods to take
> inheritance into account, etc).
>
>
> - Nick
>
> ----------------------------------------
>
> From: "Christopher Currens" <[EMAIL PROTECTED]>
>
> Sent: Monday, November 21, 2011 2:56 PM
>
> To: [EMAIL PROTECTED]
>
> Subject: Re: [Lucene.Net] Roadmap
>
>
> Regarding the 3.0.3 branch I started last week, I've put in a lot of late
>
> nights and gotten far more done in a week and a half than I expected.  The
>
> list of changes is very large, and fortunately, I've documented it in some
>
> files that are in the branches root of certain projects.  I'll list what
>
> changes have been made so far, and some of the concerns I have about them,
>
> as well as what still needs to be done.  You can read them all in detail
> in
>
> the files that are in the branch.
>
>
> All changes in 3.0.3 have been ported to the Lucene.Net and
>
> Lucene.Net.Test, except BooleanClause, LockStressTest, MMapDirectory,
>
> NIOFSDirectory, DummyConcurrentLock, NamedThreadFactory, and
>
> ThreadInterruptedException.
>
>
> MMapDirectory and NIOFSDirectory have never been ported in the first place
>
> for 2.9.4, so I'm not worried about those.  LockStressTest is a
>
> command-line tool, porting it should be easy, but not essential to a 3.0.3
>
> release, IMO.  DummyConcurrentLock also seems unnecessary (and
>
> non-portable) for .NET, since it's based around Java's Lock class and is
>
> only used to bypass locking, which can be done by passing new Object() to
>
> the method.
>
> NamedThreadFactory I'm unsure about.  It's used in ParallelMultiSearcher
>
> (in which I've opted to use the TPL), and seems to be only used for
>
> debugging, possibly testing.  Either way, I'm not sure it's necessary.
>
> Also, named threads would mean we probably would have to move the class
>
> from the TPL, which greatly simplified the code and parallelization of it
>
> all, as I can't see a way to Set names for a Task.  I suppose it might be
>
> possible, as Tasks have unique Ids, and you could use a Dictionary to map
>
> the thread's name to the ID in the factory, but you'd have to create a
>
> helper function that would allow you to find a task by its name, which
>
> seems more work than the resulting benefits.  VS2010 already has better
>
> support for debugging tasks over threads (I used it when writing the

Hi Chris,

First of all, thank you for your great work on 3.0.3 branch.
I suppose you took 2.9.4 as a code base to make 3.0.3 port since some of
your problems are the same with those I faced in 2.9.4g branch.
(e.g,
Support/MemoryMappedDirectory.cs (but never used in core),
IDisposable,
introduction of some Action<T>s, Func<T>s ,
"foreach" instead of "GetEnumerator/MoveNext",
IEquatable<T>,
WeakDictionary<T>,
Set<T>    
etc.
)

Since I also used 3.0.3 as a reference, maybe we can use some of 2.9.4g's
code in 3.0.3 when necessary(I haven't had time to look into 3.0.3 deeply)

Just to ensure the coordination, maybe you should create a new issue in
JIRA, so that people send patches to that issue instead of directly
commiting.
@Prescott,
2.9.4g is not behind of 2.9.4 in bug fixes & features level. So, It is (I
think) ready for another release.(I use it in all my projects since long).
PS: Hearing the "pain" of porting codes that greatly differ from Java made
me just smile( sorry for that:( ). Be ready for responses that get beyond
the criticism between "With all due respect" & "Just my $0.02" paranthesis.

DIGY

-----Original Message-----
From: Christopher Currens [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 21, 2011 10:19 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Roadmap

Some of the Lucene classes have Dispose methods, well, ones that call Close
(and that Close method may or may not call base.Close(), if needed or not).
 Virtual dispose methods can be dangerous only in that they're easy to
implement wrong.  However, it shouldn't be too bad, at least with a
line-by-line port, as we would make the call to the base class whenever
Lucene does, and that would (should) give us the same behavior, implemented
properly.  I'm not aware of differences in the JVM, regarding inheritance
and base methods being called automatically, particularly Close methods.

Slightly unrelated, another annoyance is the use of Java Iterators vs C#
Enumerables.  A lot of our code is there simply because there are
Iterators, but it could be converted to Enumerables. The whole HasNext,
Next vs C#'s MoveNext(), Current is annoying, but it's used all over in the
base code, and would have to be changed there as well.  Either way, I would
like to push for that before 3.0.3 is relased.  IMO, small changes like
this still keep the code similar to the line-by-line port, in that it
doesn't add any difficulties in the porting process, but provides great
benefits to the users of the code, to have a .NET centric API.  I don't
think it would violate our project desciption we have listed on our
Incubator page, either.
Thanks,
Christopher

On Mon, Nov 21, 2011 at 12:03 PM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:

> +1 on the suggestion to move Close -> IDisposable; not being able to use
> "using" is such a pain, and an eyesore on the code.
>
>
> Although it will have to be done properly, and not just have Dispose call
> Close (you should have proper protected virtual Dispose methods to take
> inheritance into account, etc).
>
>
> - Nick
>
> ----------------------------------------
>
> From: "Christopher Currens" <[EMAIL PROTECTED]>
>
> Sent: Monday, November 21, 2011 2:56 PM
>
> To: [EMAIL PROTECTED]
>
> Subject: Re: [Lucene.Net] Roadmap
>
>
> Regarding the 3.0.3 branch I started last week, I've put in a lot of late
>
> nights and gotten far more done in a week and a half than I expected.  The
>
> list of changes is very large, and fortunately, I've documented it in some
>
> files that are in the branches root of certain projects.  I'll list what
>
> changes have been made so far, and some of the concerns I have about them,
>
> as well as what still needs to be done.  You can read them all in detail
> in
>
> the files that are in the branch.
>
>
> All changes in 3.0.3 have been ported to the Lucene.Net and
>
> Lucene.Net.Test, except BooleanClause, LockStressTest, MMapDirectory,
Checked by AVG - www.avg.com
Version: 2012.0.1872 / Virus Database: 2101/4630 - Release Date: 11/21/11

Digy,

I used 2.9.4 trunk as the base for the 3.0.3 branch, but I looked to the
code in 2.9.4g as a reference for many things, particularly the Support
classes.  We hit many of the same issues I'm sure, I moved some of the
anonymous classes into a base class where you could inject functions,
though not all could be replaced, nor did I replace all that could have
been.  Some of our code is different, I went for the option for
WeakDictionary to be completely generic, as in wrapping a generic
dictionary with WeakKey<T> instead of wrapping the already existing
WeakHashTable in support.  In hindsight, it may have just been easier to
convert the WeakHashTable to generic, but alas, I'm only realizing that
now.  There is a problem with my WeakDictionary, specifically the function
that determines when to clean/compact the dictionary and remove the dead
keys.  I need a better heuristic of deciding when to run the clean.  That's
a performance issue though.

Regarding the "pain of porting", I am a changed man.  It's nice, in a sad
way, to know that I'm not the only one who experienced those difficulties.
 I used to be in the camp that porting code that differed from java
wouldn't be difficult at all.  However, now I code corrected!  It threw me
a curve-ball, for sure.  I DO think a line-by-line port can definitely
include the things talked about below, ie the changes to Dispose and the
changes to IEnumerable<T>.  Those changes, I thing, can be made without a
heavy impact on the porting process.

There was one fairly large change I opted to use that differed quite a bit
from Java, however, and that was the use of the TPL in
ParallelMultiSearcher.  It was far easier to port this way, and I don't
think it affects the porting process too much.  Java uses a helper class
defined at the bottom of the source file that handles it, I'm simply using
a built-in one instead.  I just need to be careful about it, it would be
really easy to get carried away with it.
Thanks,
Christopher

On Mon, Nov 21, 2011 at 1:20 PM, Digy <[EMAIL PROTECTED]> wrote:

> Hi Chris,
>
> First of all, thank you for your great work on 3.0.3 branch.
> I suppose you took 2.9.4 as a code base to make 3.0.3 port since some of
> your problems are the same with those I faced in 2.9.4g branch.
> (e.g,
>        Support/MemoryMappedDirectory.cs (but never used in core),
>        IDisposable,
>        introduction of some Action<T>s, Func<T>s ,
>        "foreach" instead of "GetEnumerator/MoveNext",
>        IEquatable<T>,
>        WeakDictionary<T>,
>        Set<T>
>                etc.
> )
>
> Since I also used 3.0.3 as a reference, maybe we can use some of 2.9.4g's
> code in 3.0.3 when necessary(I haven't had time to look into 3.0.3 deeply)
>
> Just to ensure the coordination, maybe you should create a new issue in
> JIRA, so that people send patches to that issue instead of directly
> commiting.
>
>
> @Prescott,
> 2.9.4g is not behind of 2.9.4 in bug fixes & features level. So, It is (I
> think) ready for another release.(I use it in all my projects since long).
>
>
> PS: Hearing the "pain" of porting codes that greatly differ from Java made
> me just smile( sorry for that:( ). Be ready for responses that get beyond
> the criticism between "With all due respect" & "Just my $0.02" paranthesis.
>
> DIGY
>
> -----Original Message-----
> From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 21, 2011 10:19 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> Some of the Lucene classes have Dispose methods, well, ones that call Close
> (and that Close method may or may not call base.Close(), if needed or not).
>  Virtual dispose methods can be dangerous only in that they're easy to
> implement wrong.  However, it shouldn't be too bad, at least with a
> line-by-line port, as we would make the call to the base class whenever
> Lucene does, and that would (should) give us the same behavior, implemented

Chris,

Sorry, if you took my comments about "pain of porting" personally. That
wasn't my intension.

+1 for all your changes/divergences. I made/could have made them too.

DIGY

-----Original Message-----
From: Christopher Currens [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 21, 2011 11:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Roadmap

Digy,

I used 2.9.4 trunk as the base for the 3.0.3 branch, but I looked to the
code in 2.9.4g as a reference for many things, particularly the Support
classes.  We hit many of the same issues I'm sure, I moved some of the
anonymous classes into a base class where you could inject functions,
though not all could be replaced, nor did I replace all that could have
been.  Some of our code is different, I went for the option for
WeakDictionary to be completely generic, as in wrapping a generic
dictionary with WeakKey<T> instead of wrapping the already existing
WeakHashTable in support.  In hindsight, it may have just been easier to
convert the WeakHashTable to generic, but alas, I'm only realizing that
now.  There is a problem with my WeakDictionary, specifically the function
that determines when to clean/compact the dictionary and remove the dead
keys.  I need a better heuristic of deciding when to run the clean.  That's
a performance issue though.

Regarding the "pain of porting", I am a changed man.  It's nice, in a sad
way, to know that I'm not the only one who experienced those difficulties.
 I used to be in the camp that porting code that differed from java
wouldn't be difficult at all.  However, now I code corrected!  It threw me
a curve-ball, for sure.  I DO think a line-by-line port can definitely
include the things talked about below, ie the changes to Dispose and the
changes to IEnumerable<T>.  Those changes, I thing, can be made without a
heavy impact on the porting process.

There was one fairly large change I opted to use that differed quite a bit
from Java, however, and that was the use of the TPL in
ParallelMultiSearcher.  It was far easier to port this way, and I don't
think it affects the porting process too much.  Java uses a helper class
defined at the bottom of the source file that handles it, I'm simply using
a built-in one instead.  I just need to be careful about it, it would be
really easy to get carried away with it.
Thanks,
Christopher

On Mon, Nov 21, 2011 at 1:20 PM, Digy <[EMAIL PROTECTED]> wrote:

> Hi Chris,
>
> First of all, thank you for your great work on 3.0.3 branch.
> I suppose you took 2.9.4 as a code base to make 3.0.3 port since some of
> your problems are the same with those I faced in 2.9.4g branch.
> (e.g,
>        Support/MemoryMappedDirectory.cs (but never used in core),
>        IDisposable,
>        introduction of some Action<T>s, Func<T>s ,
>        "foreach" instead of "GetEnumerator/MoveNext",
>        IEquatable<T>,
>        WeakDictionary<T>,
>        Set<T>
>                etc.
> )
>
> Since I also used 3.0.3 as a reference, maybe we can use some of 2.9.4g's
> code in 3.0.3 when necessary(I haven't had time to look into 3.0.3 deeply)
>
> Just to ensure the coordination, maybe you should create a new issue in
> JIRA, so that people send patches to that issue instead of directly
> commiting.
>
>
> @Prescott,
> 2.9.4g is not behind of 2.9.4 in bug fixes & features level. So, It is (I
> think) ready for another release.(I use it in all my projects since long).
>
>
> PS: Hearing the "pain" of porting codes that greatly differ from Java made
> me just smile( sorry for that:( ). Be ready for responses that get beyond
> the criticism between "With all due respect" & "Just my $0.02"
paranthesis.
>
> DIGY
>
> -----Original Message-----
> From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 21, 2011 10:19 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> Some of the Lucene classes have Dispose methods, well, ones that call
Close
not).
implemented
the
would
call
late
to
it
be
map
line-by-line
The
this
Java's
intelligent
.NET.
thing
to
help
Checked by AVG - www.avg.com
Version: 2012.0.1872 / Virus Database: 2101/4630 - Release Date: 11/21/11

Digy,

No worries.  I wasn't taking them personally.  You've been doing this for a
lot longer than I have, but I didn't understand you pain until I had to go
through it personally. :P

Have you looked at Contrib in a while?  There's a lot of projects that are
in Java's Contrib that are not in Lucene.Net?  Is this because there are
some that can't easily (if at all) be ported over to .NET or just because
they've been neglected?  I'm trying to get a handle on what's important to
port and what isn't.  Figured someone with experience could help me with a
starting point over deciding where to start with everything that's missing.
Thanks,
Christopher

On Mon, Nov 21, 2011 at 2:13 PM, Digy <[EMAIL PROTECTED]> wrote:

>
> Chris,
>
> Sorry, if you took my comments about "pain of porting" personally. That
> wasn't my intension.
>
> +1 for all your changes/divergences. I made/could have made them too.
>
> DIGY
>
> -----Original Message-----
> From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 21, 2011 11:45 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> Digy,
>
> I used 2.9.4 trunk as the base for the 3.0.3 branch, but I looked to the
> code in 2.9.4g as a reference for many things, particularly the Support
> classes.  We hit many of the same issues I'm sure, I moved some of the
> anonymous classes into a base class where you could inject functions,
> though not all could be replaced, nor did I replace all that could have
> been.  Some of our code is different, I went for the option for
> WeakDictionary to be completely generic, as in wrapping a generic
> dictionary with WeakKey<T> instead of wrapping the already existing
> WeakHashTable in support.  In hindsight, it may have just been easier to
> convert the WeakHashTable to generic, but alas, I'm only realizing that
> now.  There is a problem with my WeakDictionary, specifically the function
> that determines when to clean/compact the dictionary and remove the dead
> keys.  I need a better heuristic of deciding when to run the clean.  That's
> a performance issue though.
>
> Regarding the "pain of porting", I am a changed man.  It's nice, in a sad
> way, to know that I'm not the only one who experienced those difficulties.
>  I used to be in the camp that porting code that differed from java
> wouldn't be difficult at all.  However, now I code corrected!  It threw me
> a curve-ball, for sure.  I DO think a line-by-line port can definitely
> include the things talked about below, ie the changes to Dispose and the
> changes to IEnumerable<T>.  Those changes, I thing, can be made without a
> heavy impact on the porting process.
>
> There was one fairly large change I opted to use that differed quite a bit
> from Java, however, and that was the use of the TPL in
> ParallelMultiSearcher.  It was far easier to port this way, and I don't
> think it affects the porting process too much.  Java uses a helper class
> defined at the bottom of the source file that handles it, I'm simply using
> a built-in one instead.  I just need to be careful about it, it would be
> really easy to get carried away with it.
>
>
> Thanks,
> Christopher
>
> On Mon, Nov 21, 2011 at 1:20 PM, Digy <[EMAIL PROTECTED]> wrote:
>
> > Hi Chris,
> >
> > First of all, thank you for your great work on 3.0.3 branch.
> > I suppose you took 2.9.4 as a code base to make 3.0.3 port since some of
> > your problems are the same with those I faced in 2.9.4g branch.
> > (e.g,
> >        Support/MemoryMappedDirectory.cs (but never used in core),
> >        IDisposable,
> >        introduction of some Action<T>s, Func<T>s ,
> >        "foreach" instead of "GetEnumerator/MoveNext",
> >        IEquatable<T>,
> >        WeakDictionary<T>,
> >        Set<T>
> >                etc.
> > )
> >
> > Since I also used 3.0.3 as a reference, maybe we can use some of 2.9.4g's
> > code in 3.0.3 when necessary(I haven't had time to look into 3.0.3
> deeply)
> >
> > Just to ensure the coordination, maybe you should create a new issue in

I am also not sure but, "they had been neglected" since people tried to cope
up with the core. Contribs was thought (At least I did) as a "nice to have"
feature but not "must". Only exception for this is FVH which I use in my
projects very often:) (IIRC, it is beyond 3.0.3)

DIGY

-----Original Message-----
From: Christopher Currens [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 22, 2011 12:23 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Roadmap

Digy,

No worries.  I wasn't taking them personally.  You've been doing this for a
lot longer than I have, but I didn't understand you pain until I had to go
through it personally. :P

Have you looked at Contrib in a while?  There's a lot of projects that are
in Java's Contrib that are not in Lucene.Net?  Is this because there are
some that can't easily (if at all) be ported over to .NET or just because
they've been neglected?  I'm trying to get a handle on what's important to
port and what isn't.  Figured someone with experience could help me with a
starting point over deciding where to start with everything that's missing.
Thanks,
Christopher

On Mon, Nov 21, 2011 at 2:13 PM, Digy <[EMAIL PROTECTED]> wrote:

>
> Chris,
>
> Sorry, if you took my comments about "pain of porting" personally. That
> wasn't my intension.
>
> +1 for all your changes/divergences. I made/could have made them too.
>
> DIGY
>
> -----Original Message-----
> From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 21, 2011 11:45 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> Digy,
>
> I used 2.9.4 trunk as the base for the 3.0.3 branch, but I looked to the
> code in 2.9.4g as a reference for many things, particularly the Support
> classes.  We hit many of the same issues I'm sure, I moved some of the
> anonymous classes into a base class where you could inject functions,
> though not all could be replaced, nor did I replace all that could have
> been.  Some of our code is different, I went for the option for
> WeakDictionary to be completely generic, as in wrapping a generic
> dictionary with WeakKey<T> instead of wrapping the already existing
> WeakHashTable in support.  In hindsight, it may have just been easier to
> convert the WeakHashTable to generic, but alas, I'm only realizing that
> now.  There is a problem with my WeakDictionary, specifically the function
> that determines when to clean/compact the dictionary and remove the dead
> keys.  I need a better heuristic of deciding when to run the clean.
That's
> a performance issue though.
>
> Regarding the "pain of porting", I am a changed man.  It's nice, in a sad
> way, to know that I'm not the only one who experienced those difficulties.
>  I used to be in the camp that porting code that differed from java
> wouldn't be difficult at all.  However, now I code corrected!  It threw me
> a curve-ball, for sure.  I DO think a line-by-line port can definitely
> include the things talked about below, ie the changes to Dispose and the
> changes to IEnumerable<T>.  Those changes, I thing, can be made without a
> heavy impact on the porting process.
>
> There was one fairly large change I opted to use that differed quite a bit
> from Java, however, and that was the use of the TPL in
> ParallelMultiSearcher.  It was far easier to port this way, and I don't
> think it affects the porting process too much.  Java uses a helper class
> defined at the bottom of the source file that handles it, I'm simply using
> a built-in one instead.  I just need to be careful about it, it would be
> really easy to get carried away with it.
>
>
> Thanks,
> Christopher
>
> On Mon, Nov 21, 2011 at 1:20 PM, Digy <[EMAIL PROTECTED]> wrote:
>
> > Hi Chris,
> >
> > First of all, thank you for your great work on 3.0.3 branch.
> > I suppose you took 2.9.4 as a code base to make 3.0.3 port since some of
> > your problems are the same with those I faced in 2.9.4g branch.
> > (e.g,
> >        Support/MemoryMappedDirectory.cs (but never used in core),
2.9.4g's
(I
beyond
inheritance
take
class
better
the
I've
code
think
I'm
ported
fix
in
the
to
11/21/11
Checked by AVG - www.avg.com
Version: 2012.0.1872 / Virus Database: 2101/4630 - Release Date: 11/21/11

So, if we're getting back to the line by line port discussion... I
think either side of this discussion is too extreme. For the case in
point Chris just mentioned (which I'm not really sure what part was so
difficult, as I ported that library in about 30 minutes from
scratch)... anything is a pain if it sticks out in the middle of doing
something completely different.

The only reason we are able to do this "line by line" is due to the
general similarity between Java and C#'s language syntax. If we were
porting Lucene to a completely different language, that had a totally
different syntax, the process would go like this:

- Look at the original code, understand it's intent
- Create similar code in the new language that expresses the same intent

When applying changes:

- Look at the original code diffs, understanding the intent of the change
- Look at the ported code, and apply the changed logic's meaning in
that language

So, is just a different thought process. In my opinion, it's a better
process because it forces the developer to actually think about the
code instead of blindly converting syntax (possibly slightly
incorrectly and introducing regressions). While there is a large
volume of unit tests in Lucene, they are unfortunately not really the
right tests and make porting much more difficult, because it's hard to
verify that your ported code behaves the same because you can't just
rely on the unit tests to verify your port. Therefore, it's safer to
follow a process that requires the developer to delve deeply into the
meaning of the code. Following a line-by-line process is convenient,
but doesn't focus on meaning, which I think is more important.

Thanks,
Troy

On Mon, Nov 21, 2011 at 2:23 PM, Christopher Currens
<[EMAIL PROTECTED]> wrote:
> Digy,
>
> No worries.  I wasn't taking them personally.  You've been doing this for a
> lot longer than I have, but I didn't understand you pain until I had to go
> through it personally. :P
>
> Have you looked at Contrib in a while?  There's a lot of projects that are
> in Java's Contrib that are not in Lucene.Net?  Is this because there are
> some that can't easily (if at all) be ported over to .NET or just because
> they've been neglected?  I'm trying to get a handle on what's important to
> port and what isn't.  Figured someone with experience could help me with a
> starting point over deciding where to start with everything that's missing.
>
>
> Thanks,
> Christopher
>
> On Mon, Nov 21, 2011 at 2:13 PM, Digy <[EMAIL PROTECTED]> wrote:
>
>>
>> Chris,
>>
>> Sorry, if you took my comments about "pain of porting" personally. That
>> wasn't my intension.
>>
>> +1 for all your changes/divergences. I made/could have made them too.
>>
>> DIGY
>>
>> -----Original Message-----
>> From: Christopher Currens [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, November 21, 2011 11:45 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [Lucene.Net] Roadmap
>>
>> Digy,
>>
>> I used 2.9.4 trunk as the base for the 3.0.3 branch, but I looked to the
>> code in 2.9.4g as a reference for many things, particularly the Support
>> classes.  We hit many of the same issues I'm sure, I moved some of the
>> anonymous classes into a base class where you could inject functions,
>> though not all could be replaced, nor did I replace all that could have
>> been.  Some of our code is different, I went for the option for
>> WeakDictionary to be completely generic, as in wrapping a generic
>> dictionary with WeakKey<T> instead of wrapping the already existing
>> WeakHashTable in support.  In hindsight, it may have just been easier to
>> convert the WeakHashTable to generic, but alas, I'm only realizing that
>> now.  There is a problem with my WeakDictionary, specifically the function
>> that determines when to clean/compact the dictionary and remove the dead
>> keys.  I need a better heuristic of deciding when to run the clean.  That's
>> a performance issue though.
>>
>> Regarding the "pain of porting", I am a changed man.  It's nice, in a sad

Troy,
I am not againt it if you can continue to understand and port so easyly.
No one here -I think- wants a java-tastes code.

DIGY

-----Original Message-----
From: Troy Howard [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 22, 2011 12:42 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Roadmap

So, if we're getting back to the line by line port discussion... I
think either side of this discussion is too extreme. For the case in
point Chris just mentioned (which I'm not really sure what part was so
difficult, as I ported that library in about 30 minutes from
scratch)... anything is a pain if it sticks out in the middle of doing
something completely different.

The only reason we are able to do this "line by line" is due to the
general similarity between Java and C#'s language syntax. If we were
porting Lucene to a completely different language, that had a totally
different syntax, the process would go like this:

- Look at the original code, understand it's intent
- Create similar code in the new language that expresses the same intent

When applying changes:

- Look at the original code diffs, understanding the intent of the change
- Look at the ported code, and apply the changed logic's meaning in
that language

So, is just a different thought process. In my opinion, it's a better
process because it forces the developer to actually think about the
code instead of blindly converting syntax (possibly slightly
incorrectly and introducing regressions). While there is a large
volume of unit tests in Lucene, they are unfortunately not really the
right tests and make porting much more difficult, because it's hard to
verify that your ported code behaves the same because you can't just
rely on the unit tests to verify your port. Therefore, it's safer to
follow a process that requires the developer to delve deeply into the
meaning of the code. Following a line-by-line process is convenient,
but doesn't focus on meaning, which I think is more important.

Thanks,
Troy

On Mon, Nov 21, 2011 at 2:23 PM, Christopher Currens
<[EMAIL PROTECTED]> wrote:
> Digy,
>
> No worries.  I wasn't taking them personally.  You've been doing this for a
> lot longer than I have, but I didn't understand you pain until I had to go
> through it personally. :P
>
> Have you looked at Contrib in a while?  There's a lot of projects that are
> in Java's Contrib that are not in Lucene.Net?  Is this because there are
> some that can't easily (if at all) be ported over to .NET or just because
> they've been neglected?  I'm trying to get a handle on what's important to
> port and what isn't.  Figured someone with experience could help me with a
> starting point over deciding where to start with everything that's missing.
>
>
> Thanks,
> Christopher
>
> On Mon, Nov 21, 2011 at 2:13 PM, Digy <[EMAIL PROTECTED]> wrote:
>
>>
>> Chris,
>>
>> Sorry, if you took my comments about "pain of porting" personally. That
>> wasn't my intension.
>>
>> +1 for all your changes/divergences. I made/could have made them too.
>>
>> DIGY
>>
>> -----Original Message-----
>> From: Christopher Currens [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, November 21, 2011 11:45 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [Lucene.Net] Roadmap
>>
>> Digy,
>>
>> I used 2.9.4 trunk as the base for the 3.0.3 branch, but I looked to the
>> code in 2.9.4g as a reference for many things, particularly the Support
>> classes.  We hit many of the same issues I'm sure, I moved some of the
>> anonymous classes into a base class where you could inject functions,
>> though not all could be replaced, nor did I replace all that could have
>> been.  Some of our code is different, I went for the option for
>> WeakDictionary to be completely generic, as in wrapping a generic
>> dictionary with WeakKey<T> instead of wrapping the already existing
>> WeakHashTable in support.  In hindsight, it may have just been easier to
>> convert the WeakHashTable to generic, but alas, I'm only realizing that

Checked by AVG - www.avg.com
Version: 2012.0.1872 / Virus Database: 2101/4630 - Release Date: 11/21/11

To clarify, it wasn't as much *difficult* as it was more *painful*.  Above,
I was inferring that it was more difficult that the rest of the code, which
by comparison was easier.  It wasn't painless to try and map where code
changes were from the java classes into the .Net version.  I prefer that
style more for its readability and the niceties of working with a .Net
style of Lucene, however as I said before, it slowed down significantly the
porting process.  I hope it didn't come across that I thought that it was
bad code, because it's probably the most readable code we have in the
Contrib at the moment.

I want to make it clear that my intention right now is to get Lucene.Net up
to date with Java.  When I read the Java code, I understand its intent, and
I make sure the ported code represents it.  That takes enough time as it
is, moving to try and figure out where the code went in Lucene.Net, since
it wasn't a 1-1 map, was a MINOR annoyance, especially when you compare it
to the issues I had dealing with the differences between the two languages,
generics especialy.  That being said, I don't have a problem with code
being converted in a .Net idiomatic way, in fact, I welcome it, if it still
allows the changes to be ported with minimal effort.  I feel at this point
in the project, there are some limitations to how far I'd like it to
diverge.

Anyway, my opinion, which may not be in agreement with the group as a
whole, is that it would be better to bring the codebase up to date, or at
least more up to date with java's, and then maintaining a version with a
complete .net-concentric API.  I feel this would beeasier, as porting
Java's Lucene SVN commits by the week would be a relatively small workload.

On Mon, Nov 21, 2011 at 2:41 PM, Troy Howard <[EMAIL PROTECTED]> wrote:

> So, if we're getting back to the line by line port discussion... I
> think either side of this discussion is too extreme. For the case in
> point Chris just mentioned (which I'm not really sure what part was so
> difficult, as I ported that library in about 30 minutes from
> scratch)... anything is a pain if it sticks out in the middle of doing
> something completely different.
>
> The only reason we are able to do this "line by line" is due to the
> general similarity between Java and C#'s language syntax. If we were
> porting Lucene to a completely different language, that had a totally
> different syntax, the process would go like this:
>
> - Look at the original code, understand it's intent
> - Create similar code in the new language that expresses the same intent
>
> When applying changes:
>
> - Look at the original code diffs, understanding the intent of the change
> - Look at the ported code, and apply the changed logic's meaning in
> that language
>
> So, is just a different thought process. In my opinion, it's a better
> process because it forces the developer to actually think about the
> code instead of blindly converting syntax (possibly slightly
> incorrectly and introducing regressions). While there is a large
> volume of unit tests in Lucene, they are unfortunately not really the
> right tests and make porting much more difficult, because it's hard to
> verify that your ported code behaves the same because you can't just
> rely on the unit tests to verify your port. Therefore, it's safer to
> follow a process that requires the developer to delve deeply into the
> meaning of the code. Following a line-by-line process is convenient,
> but doesn't focus on meaning, which I think is more important.
>
> Thanks,
> Troy
>
> On Mon, Nov 21, 2011 at 2:23 PM, Christopher Currens
> <[EMAIL PROTECTED]> wrote:
> > Digy,
> >
> > No worries.  I wasn't taking them personally.  You've been doing this
> for a
> > lot longer than I have, but I didn't understand you pain until I had to
> go
> > through it personally. :P
> >
> > Have you looked at Contrib in a while?  There's a lot of projects that
> are
> > in Java's Contrib that are not in Lucene.Net?  Is this because there are

My english isn't enough to understand this answer. I hope it is not related
with
employee-employer relationship as in the past.

DIGY

-----Original Message-----
From: Christopher Currens [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 22, 2011 1:08 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Roadmap

To clarify, it wasn't as much *difficult* as it was more *painful*.  Above,
I was inferring that it was more difficult that the rest of the code, which
by comparison was easier.  It wasn't painless to try and map where code
changes were from the java classes into the .Net version.  I prefer that
style more for its readability and the niceties of working with a .Net
style of Lucene, however as I said before, it slowed down significantly the
porting process.  I hope it didn't come across that I thought that it was
bad code, because it's probably the most readable code we have in the
Contrib at the moment.

I want to make it clear that my intention right now is to get Lucene.Net up
to date with Java.  When I read the Java code, I understand its intent, and
I make sure the ported code represents it.  That takes enough time as it
is, moving to try and figure out where the code went in Lucene.Net, since
it wasn't a 1-1 map, was a MINOR annoyance, especially when you compare it
to the issues I had dealing with the differences between the two languages,
generics especialy.  That being said, I don't have a problem with code
being converted in a .Net idiomatic way, in fact, I welcome it, if it still
allows the changes to be ported with minimal effort.  I feel at this point
in the project, there are some limitations to how far I'd like it to
diverge.

Anyway, my opinion, which may not be in agreement with the group as a
whole, is that it would be better to bring the codebase up to date, or at
least more up to date with java's, and then maintaining a version with a
complete .net-concentric API.  I feel this would beeasier, as porting
Java's Lucene SVN commits by the week would be a relatively small workload.

On Mon, Nov 21, 2011 at 2:41 PM, Troy Howard <[EMAIL PROTECTED]> wrote:

> So, if we're getting back to the line by line port discussion... I
> think either side of this discussion is too extreme. For the case in
> point Chris just mentioned (which I'm not really sure what part was so
> difficult, as I ported that library in about 30 minutes from
> scratch)... anything is a pain if it sticks out in the middle of doing
> something completely different.
>
> The only reason we are able to do this "line by line" is due to the
> general similarity between Java and C#'s language syntax. If we were
> porting Lucene to a completely different language, that had a totally
> different syntax, the process would go like this:
>
> - Look at the original code, understand it's intent
> - Create similar code in the new language that expresses the same intent
>
> When applying changes:
>
> - Look at the original code diffs, understanding the intent of the change
> - Look at the ported code, and apply the changed logic's meaning in
> that language
>
> So, is just a different thought process. In my opinion, it's a better
> process because it forces the developer to actually think about the
> code instead of blindly converting syntax (possibly slightly
> incorrectly and introducing regressions). While there is a large
> volume of unit tests in Lucene, they are unfortunately not really the
> right tests and make porting much more difficult, because it's hard to
> verify that your ported code behaves the same because you can't just
> rely on the unit tests to verify your port. Therefore, it's safer to
> follow a process that requires the developer to delve deeply into the
> meaning of the code. Following a line-by-line process is convenient,
> but doesn't focus on meaning, which I think is more important.
>
> Thanks,
> Troy
>
> On Mon, Nov 21, 2011 at 2:23 PM, Christopher Currens
> <[EMAIL PROTECTED]> wrote:
> > Digy,
> >
because
the
to
dead
the
class
be
to
to
Dispose
of
about
first
a
the
possible.
different
for
.NET,
test
there
and
Checked by AVG - www.avg.com
Version: 2012.0.1872 / Virus Database: 2101/4630 - Release Date: 11/21/11

Chris,

Now that you have spent some time dealing with the porting what is your view
on creating a fully automated porting tool?  

Scott  

> -----Original Message-----
> From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 21, 2011 5:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> Digy,
>
> No worries.  I wasn't taking them personally.  You've been
> doing this for a lot longer than I have, but I didn't
> understand you pain until I had to go through it personally. :P
>
> Have you looked at Contrib in a while?  There's a lot of
> projects that are in Java's Contrib that are not in
> Lucene.Net?  Is this because there are some that can't easily
> (if at all) be ported over to .NET or just because they've
> been neglected?  I'm trying to get a handle on what's
> important to port and what isn't.  Figured someone with
> experience could help me with a starting point over deciding
> where to start with everything that's missing.
>
>
> Thanks,
> Christopher
>
> On Mon, Nov 21, 2011 at 2:13 PM, Digy <[EMAIL PROTECTED]> wrote:
>
> >
> > Chris,
> >
> > Sorry, if you took my comments about "pain of porting" personally.
> > That wasn't my intension.
> >
> > +1 for all your changes/divergences. I made/could have made
> them too.
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 21, 2011 11:45 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Roadmap
> >
> > Digy,
> >
> > I used 2.9.4 trunk as the base for the 3.0.3 branch, but I
> looked to
> > the code in 2.9.4g as a reference for many things, particularly the
> > Support classes.  We hit many of the same issues I'm sure, I moved
> > some of the anonymous classes into a base class where you
> could inject
> > functions, though not all could be replaced, nor did I replace all
> > that could have been.  Some of our code is different, I
> went for the
> > option for WeakDictionary to be completely generic, as in
> wrapping a
> > generic dictionary with WeakKey<T> instead of wrapping the already
> > existing WeakHashTable in support.  In hindsight, it may have just
> > been easier to convert the WeakHashTable to generic, but alas, I'm
> > only realizing that now.  There is a problem with my
> WeakDictionary,
> > specifically the function that determines when to clean/compact the
> > dictionary and remove the dead keys.  I need a better heuristic of
> > deciding when to run the clean.  That's a performance issue though.
> >
> > Regarding the "pain of porting", I am a changed man.  It's
> nice, in a
> > sad way, to know that I'm not the only one who experienced
> those difficulties.
> >  I used to be in the camp that porting code that differed from java
> > wouldn't be difficult at all.  However, now I code corrected!  It
> > threw me a curve-ball, for sure.  I DO think a line-by-line
> port can
> > definitely include the things talked about below, ie the changes to
> > Dispose and the changes to IEnumerable<T>.  Those changes, I thing,
> > can be made without a heavy impact on the porting process.
> >
> > There was one fairly large change I opted to use that
> differed quite a
> > bit from Java, however, and that was the use of the TPL in
> > ParallelMultiSearcher.  It was far easier to port this way, and I
> > don't think it affects the porting process too much.  Java uses a
> > helper class defined at the bottom of the source file that
> handles it,
> > I'm simply using a built-in one instead.  I just need to be careful
> > about it, it would be really easy to get carried away with it.
> >
> >
> > Thanks,
> > Christopher
> >
> > On Mon, Nov 21, 2011 at 1:20 PM, Digy <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Chris,
> > >
> > > First of all, thank you for your great work on 3.0.3 branch.
> > > I suppose you took 2.9.4 as a code base to make 3.0.3 port since
> > > some of your problems are the same with those I faced in

Next to impossible/really, really hard.  There are just some things that
don't map quite right.  Sharpen is great, but it seems you need to code
written in a way that makes it easily convertible, and I don't see the
folks at Lucene changing their coding style to do that.

An example: 3.0.3 changes classes that inherited from util.Parameter, to
java enums.  Java enums are more similar to classes than they are in C#.
 They can have methods, fields, etc.  I wound up converting them into enums
with extension methods and/or static classes (usually to generate the
enum).  The way the code was written in Java, there's no way a automated
tool could figure that out on its own, unless you had some sort of way to
tell it what to do before hand.

I imagine porting it by hand is probably easier, though it would be nice if
there was a tool that would at least convert the syntax from Java to C#, as
well as changing the naming scheme to a .NET compatible one.  However, that
only really helps if you're porting classes from scratch.  It could, also,
hide bugs, since it's possible, however unlikely, something could port
perfectly, but not behave the same way.

A class that has many calls to string.Substring is a good example of this.
 If the name of the function is changed to the .Net version (.substring to
.Substring), it would compile no problems, but they are very different.
 C#'s signatures is Substring(int start, int count) while Java's is
Substring(int startIndex, int endIndex).  It may work hiding issues, it may
throw an exception, depending on the data.  A porting tool would probably
know many of the differences like this, so it's sorta a moot point, in that
this relies on the skills of the developer anyway.

I may be wrong, but I just don't see this being a fully automated process
ever.  I would love to have something automated that at least fixed syntax
errors, though this would only work on a line-by-line port.  (Slightly off
topic, I think we should always have a line-by-line port, even if our
primary goals become focusing on a fully .Net style port)  Either way, any
sort of manual or partly-automated process would still require a lot of
work to make sure things are ported correctly.  I also think it's most
manageable if it were a tool that did it on a file per file basis (instead
of project level like Sharpen), for easy review and testing.
Thanks,
Christopher

On Mon, Nov 21, 2011 at 3:30 PM, Scott Lombard <[EMAIL PROTECTED]>wrote:

> Chris,
>
> Now that you have spent some time dealing with the porting what is your
> view
> on creating a fully automated porting tool?
>
> Scott
>
> > -----Original Message-----
> > From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 21, 2011 5:23 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Roadmap
> >
> > Digy,
> >
> > No worries.  I wasn't taking them personally.  You've been
> > doing this for a lot longer than I have, but I didn't
> > understand you pain until I had to go through it personally. :P
> >
> > Have you looked at Contrib in a while?  There's a lot of
> > projects that are in Java's Contrib that are not in
> > Lucene.Net?  Is this because there are some that can't easily
> > (if at all) be ported over to .NET or just because they've
> > been neglected?  I'm trying to get a handle on what's
> > important to port and what isn't.  Figured someone with
> > experience could help me with a starting point over deciding
> > where to start with everything that's missing.
> >
> >
> > Thanks,
> > Christopher
> >
> > On Mon, Nov 21, 2011 at 2:13 PM, Digy <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Chris,
> > >
> > > Sorry, if you took my comments about "pain of porting" personally.
> > > That wasn't my intension.
> > >
> > > +1 for all your changes/divergences. I made/could have made
> > them too.
> > >
> > > DIGY
> > >
> > > -----Original Message-----
> > > From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, November 21, 2011 11:45 PM

While much of the content in this thread is valid and is important,
especially concerns, pain points, and implementation details... we've
gotten way off topic.

road map != implementation details. We should keep to a much a higher
level discussion to get this knocked out.

Lets outline the roadmap, put it in a wiki page.

Then discuss how to go about each major milestone in separate threads to
discuss implementation details. Or at least let the people who are going to
work on that particular milestone publish their intentions to keep everyone
else informed since we're currently in a do-ocracy like state.

And by all means, discuss the next immediate milestones first so people who
want to dive into that can proceed.

So what are the next two major milestones?  And from a higher level
perspective what are the major items that deem those milestones complete?

What would be the the next 3 ideal milestones after the first two? And what
would be the intentions for those milestones to accomplish?

- Michael

On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
[EMAIL PROTECTED]> wrote:

> Next to impossible/really, really hard.  There are just some things that
> don't map quite right.  Sharpen is great, but it seems you need to code
> written in a way that makes it easily convertible, and I don't see the
> folks at Lucene changing their coding style to do that.
>
> An example: 3.0.3 changes classes that inherited from util.Parameter, to
> java enums.  Java enums are more similar to classes than they are in C#.
>  They can have methods, fields, etc.  I wound up converting them into enums
> with extension methods and/or static classes (usually to generate the
> enum).  The way the code was written in Java, there's no way a automated
> tool could figure that out on its own, unless you had some sort of way to
> tell it what to do before hand.
>
> I imagine porting it by hand is probably easier, though it would be nice if
> there was a tool that would at least convert the syntax from Java to C#, as
> well as changing the naming scheme to a .NET compatible one.  However, that
> only really helps if you're porting classes from scratch.  It could, also,
> hide bugs, since it's possible, however unlikely, something could port
> perfectly, but not behave the same way.
>
> A class that has many calls to string.Substring is a good example of this.
>  If the name of the function is changed to the .Net version (.substring to
> .Substring), it would compile no problems, but they are very different.
>  C#'s signatures is Substring(int start, int count) while Java's is
> Substring(int startIndex, int endIndex).  It may work hiding issues, it may
> throw an exception, depending on the data.  A porting tool would probably
> know many of the differences like this, so it's sorta a moot point, in that
> this relies on the skills of the developer anyway.
>
> I may be wrong, but I just don't see this being a fully automated process
> ever.  I would love to have something automated that at least fixed syntax
> errors, though this would only work on a line-by-line port.  (Slightly off
> topic, I think we should always have a line-by-line port, even if our
> primary goals become focusing on a fully .Net style port)  Either way, any
> sort of manual or partly-automated process would still require a lot of
> work to make sure things are ported correctly.  I also think it's most
> manageable if it were a tool that did it on a file per file basis (instead
> of project level like Sharpen), for easy review and testing.
>
>
> Thanks,
> Christopher
>
> On Mon, Nov 21, 2011 at 3:30 PM, Scott Lombard <[EMAIL PROTECTED]
> >wrote:
>
> > Chris,
> >
> > Now that you have spent some time dealing with the porting what is your
> > view
> > on creating a fully automated porting tool?
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Christopher Currens [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, November 21, 2011 5:23 PM
> > > To: [EMAIL PROTECTED]

Mike,

You're right about putting together a higher level discussion.  Here are the
road map items I see.  I am interested in other have to say.

None of the items I have listed are contigent on the other so they can be
done in parallel or out of order.  
1) Complete the release of 2.9.4
2) Create and release 3.0.3

3) Graduate from the incubator
4) Document a porting process that the community can reference.
5) Port 4.0

Scott  

> -----Original Message-----
> From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 22, 2011 10:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> While much of the content in this thread is valid and is
> important, especially concerns, pain points, and
> implementation details... we've gotten way off topic.
>
> road map != implementation details. We should keep to a much
> a higher level discussion to get this knocked out.
>
> Lets outline the roadmap, put it in a wiki page.
>
> Then discuss how to go about each major milestone in separate
> threads to discuss implementation details. Or at least let
> the people who are going to work on that particular milestone
> publish their intentions to keep everyone else informed since
> we're currently in a do-ocracy like state.
>
> And by all means, discuss the next immediate milestones first
> so people who want to dive into that can proceed.
>
> So what are the next two major milestones?  And from a higher
> level perspective what are the major items that deem those
> milestones complete?
>
> What would be the the next 3 ideal milestones after the first
> two? And what would be the intentions for those milestones to
> accomplish?
>
> - Michael
>
>
>
> On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
> [EMAIL PROTECTED]> wrote:
>
> > Next to impossible/really, really hard.  There are just some things
> > that don't map quite right.  Sharpen is great, but it seems
> you need
> > to code written in a way that makes it easily convertible,
> and I don't
> > see the folks at Lucene changing their coding style to do that.
> >
> > An example: 3.0.3 changes classes that inherited from
> util.Parameter,
> > to java enums.  Java enums are more similar to classes than
> they are in C#.
> >  They can have methods, fields, etc.  I wound up converting
> them into
> > enums with extension methods and/or static classes (usually to
> > generate the enum).  The way the code was written in Java,
> there's no
> > way a automated tool could figure that out on its own,
> unless you had
> > some sort of way to tell it what to do before hand.
> >
> > I imagine porting it by hand is probably easier, though it would be
> > nice if there was a tool that would at least convert the
> syntax from
> > Java to C#, as well as changing the naming scheme to a .NET
> compatible
> > one.  However, that only really helps if you're porting
> classes from
> > scratch.  It could, also, hide bugs, since it's possible, however
> > unlikely, something could port perfectly, but not behave
> the same way.
> >
> > A class that has many calls to string.Substring is a good
> example of this.
> >  If the name of the function is changed to the .Net version
> > (.substring to .Substring), it would compile no problems,
> but they are very different.
> >  C#'s signatures is Substring(int start, int count) while Java's is
> > Substring(int startIndex, int endIndex).  It may work
> hiding issues,
> > it may throw an exception, depending on the data.  A porting tool
> > would probably know many of the differences like this, so
> it's sorta a
> > moot point, in that this relies on the skills of the
> developer anyway.
> >
> > I may be wrong, but I just don't see this being a fully automated
> > process ever.  I would love to have something automated
> that at least
> > fixed syntax errors, though this would only work on a line-by-line
> > port.  (Slightly off topic, I think we should always have a

Regarding the short term goals that Scott mentioned, I agree.  I think over
the past 9 months that we've been active, it's time we see what we need to
do to graduate from the incubator.  Also, 3.0.3 is actually close to a
release, *depending* on how we feel about the Contrib libraries, which I'll
discuss in a separate thread.

Scott didn't mention directly, but I think it would be good to port the 3.x
branch past 3.0.3.  Lucene has released 3.1, 3.2, 3.3, and 3.4 in addition
to 3.0.3.  Whether this means we release all those versions, or just port
up to 3.4 and just release it, that's something we'd all have to agree
upon.  I want to get a 3.x branch up to where Java's is.  Also, deciding if
porting 4.0 can happen at the same time as 3.x is worked on and how to go
about it, particularly how far we want to diverge from java.  Either way, I
think maintaining both 3.x and 4.x would be a good thing for the community
to have.
On Tue, Nov 22, 2011 at 8:56 AM, Scott Lombard <[EMAIL PROTECTED]>wrote:

> Mike,
>
> You're right about putting together a higher level discussion.  Here are
> the
> road map items I see.  I am interested in other have to say.
>
> None of the items I have listed are contigent on the other so they can be
> done in parallel or out of order.
>
>
> 1) Complete the release of 2.9.4
> 2) Create and release 3.0.3
>
> 3) Graduate from the incubator
> 4) Document a porting process that the community can reference.
> 5) Port 4.0
>
>
>
> Scott
>
> > -----Original Message-----
> > From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, November 22, 2011 10:28 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Roadmap
> >
> > While much of the content in this thread is valid and is
> > important, especially concerns, pain points, and
> > implementation details... we've gotten way off topic.
> >
> > road map != implementation details. We should keep to a much
> > a higher level discussion to get this knocked out.
> >
> > Lets outline the roadmap, put it in a wiki page.
> >
> > Then discuss how to go about each major milestone in separate
> > threads to discuss implementation details. Or at least let
> > the people who are going to work on that particular milestone
> > publish their intentions to keep everyone else informed since
> > we're currently in a do-ocracy like state.
> >
> > And by all means, discuss the next immediate milestones first
> > so people who want to dive into that can proceed.
> >
> > So what are the next two major milestones?  And from a higher
> > level perspective what are the major items that deem those
> > milestones complete?
> >
> > What would be the the next 3 ideal milestones after the first
> > two? And what would be the intentions for those milestones to
> > accomplish?
> >
> > - Michael
> >
> >
> >
> > On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
> > [EMAIL PROTECTED]> wrote:
> >
> > > Next to impossible/really, really hard.  There are just some things
> > > that don't map quite right.  Sharpen is great, but it seems
> > you need
> > > to code written in a way that makes it easily convertible,
> > and I don't
> > > see the folks at Lucene changing their coding style to do that.
> > >
> > > An example: 3.0.3 changes classes that inherited from
> > util.Parameter,
> > > to java enums.  Java enums are more similar to classes than
> > they are in C#.
> > >  They can have methods, fields, etc.  I wound up converting
> > them into
> > > enums with extension methods and/or static classes (usually to
> > > generate the enum).  The way the code was written in Java,
> > there's no
> > > way a automated tool could figure that out on its own,
> > unless you had
> > > some sort of way to tell it what to do before hand.
> > >
> > > I imagine porting it by hand is probably easier, though it would be
> > > nice if there was a tool that would at least convert the
> > syntax from
> > > Java to C#, as well as changing the naming scheme to a .NET

I'm taking a look at the 3.0.3 branch - it looks like you've ported just about everything - including the contrib. Is there any chunck I can convert over? I've got some spare time this weekend.

 

~P

 
----------------------------------------
> Date: Tue, 22 Nov 2011 09:42:03 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> Regarding the short term goals that Scott mentioned, I agree. I think over
> the past 9 months that we've been active, it's time we see what we need to
> do to graduate from the incubator. Also, 3.0.3 is actually close to a
> release, *depending* on how we feel about the Contrib libraries, which I'll
> discuss in a separate thread.
>
> Scott didn't mention directly, but I think it would be good to port the 3.x
> branch past 3.0.3. Lucene has released 3.1, 3.2, 3.3, and 3.4 in addition
> to 3.0.3. Whether this means we release all those versions, or just port
> up to 3.4 and just release it, that's something we'd all have to agree
> upon. I want to get a 3.x branch up to where Java's is. Also, deciding if
> porting 4.0 can happen at the same time as 3.x is worked on and how to go
> about it, particularly how far we want to diverge from java. Either way, I
> think maintaining both 3.x and 4.x would be a good thing for the community
> to have.
>
>
> On Tue, Nov 22, 2011 at 8:56 AM, Scott Lombard <[EMAIL PROTECTED]>wrote:
>
> > Mike,
> >
> > You're right about putting together a higher level discussion. Here are
> > the
> > road map items I see. I am interested in other have to say.
> >
> > None of the items I have listed are contigent on the other so they can be
> > done in parallel or out of order.
> >
> >
> > 1) Complete the release of 2.9.4
> > 2) Create and release 3.0.3
> >
> > 3) Graduate from the incubator
> > 4) Document a porting process that the community can reference.
> > 5) Port 4.0
> >
> >
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, November 22, 2011 10:28 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [Lucene.Net] Roadmap
> > >
> > > While much of the content in this thread is valid and is
> > > important, especially concerns, pain points, and
> > > implementation details... we've gotten way off topic.
> > >
> > > road map != implementation details. We should keep to a much
> > > a higher level discussion to get this knocked out.
> > >
> > > Lets outline the roadmap, put it in a wiki page.
> > >
> > > Then discuss how to go about each major milestone in separate
> > > threads to discuss implementation details. Or at least let
> > > the people who are going to work on that particular milestone
> > > publish their intentions to keep everyone else informed since
> > > we're currently in a do-ocracy like state.
> > >
> > > And by all means, discuss the next immediate milestones first
> > > so people who want to dive into that can proceed.
> > >
> > > So what are the next two major milestones? And from a higher
> > > level perspective what are the major items that deem those
> > > milestones complete?
> > >
> > > What would be the the next 3 ideal milestones after the first
> > > two? And what would be the intentions for those milestones to
> > > accomplish?
> > >
> > > - Michael
> > >
> > >
> > >
> > > On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > Next to impossible/really, really hard. There are just some things
> > > > that don't map quite right. Sharpen is great, but it seems
> > > you need
> > > > to code written in a way that makes it easily convertible,
> > > and I don't
> > > > see the folks at Lucene changing their coding style to do that.
> > > >
> > > > An example: 3.0.3 changes classes that inherited from
> > > util.Parameter,
> > > > to java enums. Java enums are more similar to classes than
> > > they are in C#.
> > > > They can have methods, fields, etc. I wound up converting

Something else we need to consider is that "topScore" and "TopScore" is perfectly valid for a function and field name in the same class, but it will never be CLS compliant, and VB wouldn't work with Lucene.Net as is.

 

----------------------------------------
> Date: Tue, 22 Nov 2011 09:42:03 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> Regarding the short term goals that Scott mentioned, I agree. I think over
> the past 9 months that we've been active, it's time we see what we need to
> do to graduate from the incubator. Also, 3.0.3 is actually close to a
> release, *depending* on how we feel about the Contrib libraries, which I'll
> discuss in a separate thread.
>
> Scott didn't mention directly, but I think it would be good to port the 3.x
> branch past 3.0.3. Lucene has released 3.1, 3.2, 3.3, and 3.4 in addition
> to 3.0.3. Whether this means we release all those versions, or just port
> up to 3.4 and just release it, that's something we'd all have to agree
> upon. I want to get a 3.x branch up to where Java's is. Also, deciding if
> porting 4.0 can happen at the same time as 3.x is worked on and how to go
> about it, particularly how far we want to diverge from java. Either way, I
> think maintaining both 3.x and 4.x would be a good thing for the community
> to have.
>
>
> On Tue, Nov 22, 2011 at 8:56 AM, Scott Lombard <[EMAIL PROTECTED]>wrote:
>
> > Mike,
> >
> > You're right about putting together a higher level discussion. Here are
> > the
> > road map items I see. I am interested in other have to say.
> >
> > None of the items I have listed are contigent on the other so they can be
> > done in parallel or out of order.
> >
> >
> > 1) Complete the release of 2.9.4
> > 2) Create and release 3.0.3
> >
> > 3) Graduate from the incubator
> > 4) Document a porting process that the community can reference.
> > 5) Port 4.0
> >
> >
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, November 22, 2011 10:28 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [Lucene.Net] Roadmap
> > >
> > > While much of the content in this thread is valid and is
> > > important, especially concerns, pain points, and
> > > implementation details... we've gotten way off topic.
> > >
> > > road map != implementation details. We should keep to a much
> > > a higher level discussion to get this knocked out.
> > >
> > > Lets outline the roadmap, put it in a wiki page.
> > >
> > > Then discuss how to go about each major milestone in separate
> > > threads to discuss implementation details. Or at least let
> > > the people who are going to work on that particular milestone
> > > publish their intentions to keep everyone else informed since
> > > we're currently in a do-ocracy like state.
> > >
> > > And by all means, discuss the next immediate milestones first
> > > so people who want to dive into that can proceed.
> > >
> > > So what are the next two major milestones? And from a higher
> > > level perspective what are the major items that deem those
> > > milestones complete?
> > >
> > > What would be the the next 3 ideal milestones after the first
> > > two? And what would be the intentions for those milestones to
> > > accomplish?
> > >
> > > - Michael
> > >
> > >
> > >
> > > On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > Next to impossible/really, really hard. There are just some things
> > > > that don't map quite right. Sharpen is great, but it seems
> > > you need
> > > > to code written in a way that makes it easily convertible,
> > > and I don't
> > > > see the folks at Lucene changing their coding style to do that.
> > > >
> > > > An example: 3.0.3 changes classes that inherited from
> > > util.Parameter,
> > > > to java enums. Java enums are more similar to classes than
> > > they are in C#.
> > > > They can have methods, fields, etc. I wound up converting

Yes, a lot of it is done.  Porting highlighter is partially done, not
committed, because it relies on the memory contrive package in java, which
I've also ported, but the tests fail.  The last contrib project I've worked
on was snowball.  If you look at the commit log, I've tried to mention what
contrive I worked on.  Those and highlighter/memory are all I've done, the
rest is up for grabs.

I just finished a 12 hour drive from Portland to San Francisco, so I don't
know how legible the above is.  I'll take another look at what I've done
and what needs to be done tomorrow or so, but I think its pretty accurate.

- Christopher
On Nov 23, 2011 10:53 PM, "Prescott Nasser" <[EMAIL PROTECTED]> wrote:

>
> Something else we need to consider is that "topScore" and "TopScore" is
> perfectly valid for a function and field name in the same class, but it
> will never be CLS compliant, and VB wouldn't work with Lucene.Net as is.
>
>
>
> ----------------------------------------
> > Date: Tue, 22 Nov 2011 09:42:03 -0800
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Roadmap
> >
> > Regarding the short term goals that Scott mentioned, I agree. I think
> over
> > the past 9 months that we've been active, it's time we see what we need
> to
> > do to graduate from the incubator. Also, 3.0.3 is actually close to a
> > release, *depending* on how we feel about the Contrib libraries, which
> I'll
> > discuss in a separate thread.
> >
> > Scott didn't mention directly, but I think it would be good to port the
> 3.x
> > branch past 3.0.3. Lucene has released 3.1, 3.2, 3.3, and 3.4 in addition
> > to 3.0.3. Whether this means we release all those versions, or just port
> > up to 3.4 and just release it, that's something we'd all have to agree
> > upon. I want to get a 3.x branch up to where Java's is. Also, deciding if
> > porting 4.0 can happen at the same time as 3.x is worked on and how to go
> > about it, particularly how far we want to diverge from java. Either way,
> I
> > think maintaining both 3.x and 4.x would be a good thing for the
> community
> > to have.
> >
> >
> > On Tue, Nov 22, 2011 at 8:56 AM, Scott Lombard <[EMAIL PROTECTED]
> >wrote:
> >
> > > Mike,
> > >
> > > You're right about putting together a higher level discussion. Here are
> > > the
> > > road map items I see. I am interested in other have to say.
> > >
> > > None of the items I have listed are contigent on the other so they can
> be
> > > done in parallel or out of order.
> > >
> > >
> > > 1) Complete the release of 2.9.4
> > > 2) Create and release 3.0.3
> > >
> > > 3) Graduate from the incubator
> > > 4) Document a porting process that the community can reference.
> > > 5) Port 4.0
> > >
> > >
> > >
> > > Scott
> > >
> > > > -----Original Message-----
> > > > From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, November 22, 2011 10:28 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: [Lucene.Net] Roadmap
> > > >
> > > > While much of the content in this thread is valid and is
> > > > important, especially concerns, pain points, and
> > > > implementation details... we've gotten way off topic.
> > > >
> > > > road map != implementation details. We should keep to a much
> > > > a higher level discussion to get this knocked out.
> > > >
> > > > Lets outline the roadmap, put it in a wiki page.
> > > >
> > > > Then discuss how to go about each major milestone in separate
> > > > threads to discuss implementation details. Or at least let
> > > > the people who are going to work on that particular milestone
> > > > publish their intentions to keep everyone else informed since
> > > > we're currently in a do-ocracy like state.
> > > >
> > > > And by all means, discuss the next immediate milestones first
> > > > so people who want to dive into that can proceed.
> > > >
> > > > So what are the next two major milestones? And from a higher
> > > > level perspective what are the major items that deem those

Welcome to SF!

----------------------------------------
> Date: Thu, 24 Nov 2011 04:05:16 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Roadmap
>
> Yes, a lot of it is done. Porting highlighter is partially done, not
> committed, because it relies on the memory contrive package in java, which
> I've also ported, but the tests fail. The last contrib project I've worked
> on was snowball. If you look at the commit log, I've tried to mention what
> contrive I worked on. Those and highlighter/memory are all I've done, the
> rest is up for grabs.
>
> I just finished a 12 hour drive from Portland to San Francisco, so I don't
> know how legible the above is. I'll take another look at what I've done
> and what needs to be done tomorrow or so, but I think its pretty accurate.
>
> - Christopher
> On Nov 23, 2011 10:53 PM, "Prescott Nasser" <[EMAIL PROTECTED]> wrote:
>
> >
> > Something else we need to consider is that "topScore" and "TopScore" is
> > perfectly valid for a function and field name in the same class, but it
> > will never be CLS compliant, and VB wouldn't work with Lucene.Net as is.
> >
> >
> >
> > ----------------------------------------
> > > Date: Tue, 22 Nov 2011 09:42:03 -0800
> > > From: [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [Lucene.Net] Roadmap
> > >
> > > Regarding the short term goals that Scott mentioned, I agree. I think
> > over
> > > the past 9 months that we've been active, it's time we see what we need
> > to
> > > do to graduate from the incubator. Also, 3.0.3 is actually close to a
> > > release, *depending* on how we feel about the Contrib libraries, which
> > I'll
> > > discuss in a separate thread.
> > >
> > > Scott didn't mention directly, but I think it would be good to port the
> > 3.x
> > > branch past 3.0.3. Lucene has released 3.1, 3.2, 3.3, and 3.4 in addition
> > > to 3.0.3. Whether this means we release all those versions, or just port
> > > up to 3.4 and just release it, that's something we'd all have to agree
> > > upon. I want to get a 3.x branch up to where Java's is. Also, deciding if
> > > porting 4.0 can happen at the same time as 3.x is worked on and how to go
> > > about it, particularly how far we want to diverge from java. Either way,
> > I
> > > think maintaining both 3.x and 4.x would be a good thing for the
> > community
> > > to have.
> > >
> > >
> > > On Tue, Nov 22, 2011 at 8:56 AM, Scott Lombard <[EMAIL PROTECTED]
> > >wrote:
> > >
> > > > Mike,
> > > >
> > > > You're right about putting together a higher level discussion. Here are
> > > > the
> > > > road map items I see. I am interested in other have to say.
> > > >
> > > > None of the items I have listed are contigent on the other so they can
> > be
> > > > done in parallel or out of order.
> > > >
> > > >
> > > > 1) Complete the release of 2.9.4
> > > > 2) Create and release 3.0.3
> > > >
> > > > 3) Graduate from the incubator
> > > > 4) Document a porting process that the community can reference.
> > > > 5) Port 4.0
> > > >
> > > >
> > > >
> > > > Scott
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> > > > > Sent: Tuesday, November 22, 2011 10:28 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: [Lucene.Net] Roadmap
> > > > >
> > > > > While much of the content in this thread is valid and is
> > > > > important, especially concerns, pain points, and
> > > > > implementation details... we've gotten way off topic.
> > > > >
> > > > > road map != implementation details. We should keep to a much
> > > > > a higher level discussion to get this knocked out.
> > > > >
> > > > > Lets outline the roadmap, put it in a wiki page.
> > > > >
> > > > > Then discuss how to go about each major milestone in separate
> > > > > threads to discuss implementation details. Or at least let
> > > > > the people who are going to work on that particular milestone

Well, I'm technically in Berkeley  I'm hoping it gets sunny soon, though.
 I guess I can't complain though, it's warmer here and its not raining like
it is in Portland.:)

So, for the Contrib section, I've ported:

* Contrib.Analyzers
* Contrib.FastVectorHighlighter
* Contrib.Queries
* Contrib.Regex (there's an issue with one of the tests, it's been marked
as ignored, has to do with a differences in the regex engines)
* Contrib.Snowball

I updated Contrib.Core/Contrib.SimpleFacetedSearch to build, I couldn't
find anything to port for them, I think they're .NET specific.

So as a list of what needs to be done in contrib would be:

* make sure DistributedSearch builds and tests pass
* Port Similarity
* Port SpellChecker
* Port WordNet
* (optional) Port other contrib packages from java (some can't be easily
done)

For the branch as a whole, I want to implement the Dispose pattern properly
and change all classes that follow the Java iterator pattern, to
IEnumerable/IEnumerators.  The code would still be easy to port even after
these changes and it would be a big step in making the project fit in
better with everyday .NET development.  As it is, I've been using Extension
methods to "convert" a TermEnum to an actual enumerator, which is just a
wrapper class that implments IEnumerable<Term>, but it's a huge pain and
really, probably shouldn't have been implemented as an exact port to begin
with.  Either way, I'd like that to be changed.

I also agree that getting the library to be CLS compliant is a good goal,
but only in terms of naming.  I don't think the rest of it is important, at
least at this point.  Off the top of my head, besides the example you
mentioned, ScoreDocs has a obsoleted public field topDocs and public
property TopDocs.

I supposed to be on vacation, so I'm trying to keep work I do to a minimum.
:)  If you want to make JIRA issues for this you can, otherwise I will do
it when I get back on Monday.
Thanks,
Christopher

On Thu, Nov 24, 2011 at 11:05 AM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

>
> Welcome to SF!
>
> ----------------------------------------
> > Date: Thu, 24 Nov 2011 04:05:16 -0800
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Lucene.Net] Roadmap
> >
> > Yes, a lot of it is done. Porting highlighter is partially done, not
> > committed, because it relies on the memory contrive package in java,
> which
> > I've also ported, but the tests fail. The last contrib project I've
> worked
> > on was snowball. If you look at the commit log, I've tried to mention
> what
> > contrive I worked on. Those and highlighter/memory are all I've done, the
> > rest is up for grabs.
> >
> > I just finished a 12 hour drive from Portland to San Francisco, so I
> don't
> > know how legible the above is. I'll take another look at what I've done
> > and what needs to be done tomorrow or so, but I think its pretty
> accurate.
> >
> > - Christopher
> > On Nov 23, 2011 10:53 PM, "Prescott Nasser" <[EMAIL PROTECTED]>
> wrote:
> >
> > >
> > > Something else we need to consider is that "topScore" and "TopScore" is
> > > perfectly valid for a function and field name in the same class, but it
> > > will never be CLS compliant, and VB wouldn't work with Lucene.Net as
> is.
> > >
> > >
> > >
> > > ----------------------------------------
> > > > Date: Tue, 22 Nov 2011 09:42:03 -0800
> > > > From: [EMAIL PROTECTED]
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: [Lucene.Net] Roadmap
> > > >
> > > > Regarding the short term goals that Scott mentioned, I agree. I think
> > > over
> > > > the past 9 months that we've been active, it's time we see what we
> need
> > > to
> > > > do to graduate from the incubator. Also, 3.0.3 is actually close to a
> > > > release, *depending* on how we feel about the Contrib libraries,
> which
> > > I'll
> > > > discuss in a separate thread.
> > > >
> > > > Scott didn't mention directly, but I think it would be good to port
> the

Christopher,
I'd say there not that hard to get wrong, the pattern for correctly
implementing the IDisposable interface is well-established and has been
common practice since .NET 1.0:
http://msdn.microsoft.com/en-us/library/b1yfkh5e(v=VS.100).aspx
Additionally, I said protected virtual (as per the recommendation in the
link above).
Also agreed on the use of iterators everywhere.  Foreach is your friend.
What would be even better in some cases, using "yield return", as I'm sure
result sets don't need to be materialized everywhere as they are now.
- Nick

----------------------------------------

From: "Christopher Currens" <[EMAIL PROTECTED]>

Sent: Monday, November 21, 2011 3:18 PM

To: [EMAIL PROTECTED], [EMAIL PROTECTED]

Subject: Re: [Lucene.Net] Roadmap
Some of the Lucene classes have Dispose methods, well, ones that call Close
(and that Close method may or may not call base.Close(), if needed or not).
 Virtual dispose methods can be dangerous only in that they're easy to
implement wrong.  However, it shouldn't be too bad, at least with a
line-by-line port, as we would make the call to the base class whenever
Lucene does, and that would (should) give us the same behavior, implemented
properly.  I'm not aware of differences in the JVM, regarding inheritance
and base methods being called automatically, particularly Close methods.

Slightly unrelated, another annoyance is the use of Java Iterators vs C#
Enumerables.  A lot of our code is there simply because there are
Iterators, but it could be converted to Enumerables. The whole HasNext,
Next vs C#'s MoveNext(), Current is annoying, but it's used all over in the
base code, and would have to be changed there as well.  Either way, I would
like to push for that before 3.0.3 is relased.  IMO, small changes like
this still keep the code similar to the line-by-line port, in that it
doesn't add any difficulties in the porting process, but provides great
benefits to the users of the code, to have a .NET centric API.  I don't
think it would violate our project desciption we have listed on our
Incubator page, either.

Thanks,
Christopher
On Mon, Nov 21, 2011 at 12:03 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:

+1 on the suggestion to move Close -> IDisposable; not being able to use

"using" is such a pain, and an eyesore on the code.
Although it will have to be done properly, and not just have Dispose call

Close (you should have proper protected virtual Dispose methods to take

inheritance into account, etc).
- Nick
----------------------------------------
From: "Christopher Currens" <[EMAIL PROTECTED]>
Sent: Monday, November 21, 2011 2:56 PM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Roadmap
Regarding the 3.0.3 branch I started last week, I've put in a lot of late
nights and gotten far more done in a week and a half than I expected.  The
list of changes is very large, and fortunately, I've documented it in some
files that are in the branches root of certain projects.  I'll list what
changes have been made so far, and some of the concerns I have about them,
as well as what still needs to be done.  You can read them all in detail

in
the files that are in the branch.
All changes in 3.0.3 have been ported to the Lucene.Net and
Lucene.Net.Test, except BooleanClause, LockStressTest, MMapDirectory,
NIOFSDirectory, DummyConcurrentLock, NamedThreadFactory, and
ThreadInterruptedException.
MMapDirectory and NIOFSDirectory have never been ported in the first place
for 2.9.4, so I'm not worried about those.  LockStressTest is a
command-line tool, porting it should be easy, but not essential to a 3.0.3
release, IMO.  DummyConcurrentLock also seems unnecessary (and
non-portable) for .NET, since it's based around Java's Lock class and is
only used to bypass locking, which can be done by passing new Object() to
the method.
NamedThreadFactory I'm unsure about.  It's used in ParallelMultiSearcher
(in which I've opted to use the TPL), and seems to be only used for
debugging, possibly testing.  Either way, I'm not sure it's necessary.
Also, named threads would mean we probably would have to move the class
from the TPL, which greatly simplified the code and parallelization of it
all, as I can't see a way to Set names for a Task.  I suppose it might be
possible, as Tasks have unique Ids, and you could use a Dictionary to map
the thread's name to the ID in the factory, but you'd have to create a
helper function that would allow you to find a task by its name, which
seems more work than the resulting benefits.  VS2010 already has better
support for debugging tasks over threads (I used it when writing the
class), frankly, it's amazing how easy it was to debug.
Other than the above, the entire code base in the core dlls is at 3.0.3,
which is exciting, as I'm really hoping we can get Lucene.Net up to the
current version of Java's 3.x branch, and start working on a line-by-line
port of 4.0.  Tests need to be written for some of the collections I've
made that emulate Java's, to make sure they're even behaving the same way.
The good news is that all of the existing tests pass as a whole, so it
seems to be working, though I'd like the peace of mind of having tests for
them (being HashMap<TKey, TValue>, WeakDictionary<TKey, TValue> and
IdentityCollection<TKey, TValue>, it's quite possible any one of them

could
be completely wrong in how they were put together.)
I'd also like to finally formalize the way we use IDisposable in
Lucene.Net, by marking the Close functions as obsolete, moving the code
into Dispose, and eventually (or immediately) removing the Close

functions.
There's so much change to the API, that now would be a good time to make
that change if we wanted to.  I'm hesitant to move from a line-by-line

port
of Lucene.Net completely, but rat

My goal is to release 2.9.4 this month - it looks like we have no -1s from our dev list so in the next day or so I will put that to the general incubator list.

I'd then like to release 2.9.4g the first or second week of January.

My thoughts would be to try and have 3.0.3 ready by march and 4.0 in the middle of the year. Im not sure how aggressive people think that is.

With the 4.0 release we should be at or near parity with Java and ready to roll out of the incubator. We could do the 4 release and the graduation process at the same time as well

Sent from my Windows Phone
________________________________
From: Scott Lombard
Sent: 11/22/2011 8:56 AM
To: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Roadmap

Mike,

You're right about putting together a higher level discussion.  Here are the
road map items I see.  I am interested in other have to say.

None of the items I have listed are contigent on the other so they can be
done in parallel or out of order.
1) Complete the release of 2.9.4
2) Create and release 3.0.3

3) Graduate from the incubator
4) Document a porting process that the community can reference.
5) Port 4.0

Scott

> -----Original Message-----
> From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 22, 2011 10:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Roadmap
>
> While much of the content in this thread is valid and is
> important, especially concerns, pain points, and
> implementation details... we've gotten way off topic.
>
> road map != implementation details. We should keep to a much
> a higher level discussion to get this knocked out.
>
> Lets outline the roadmap, put it in a wiki page.
>
> Then discuss how to go about each major milestone in separate
> threads to discuss implementation details. Or at least let
> the people who are going to work on that particular milestone
> publish their intentions to keep everyone else informed since
> we're currently in a do-ocracy like state.
>
> And by all means, discuss the next immediate milestones first
> so people who want to dive into that can proceed.
>
> So what are the next two major milestones?  And from a higher
> level perspective what are the major items that deem those
> milestones complete?
>
> What would be the the next 3 ideal milestones after the first
> two? And what would be the intentions for those milestones to
> accomplish?
>
> - Michael
>
>
>
> On Mon, Nov 21, 2011 at 7:28 PM, Christopher Currens <
> [EMAIL PROTECTED]> wrote:
>
> > Next to impossible/really, really hard.  There are just some things
> > that don't map quite right.  Sharpen is great, but it seems
> you need
> > to code written in a way that makes it easily convertible,
> and I don't
> > see the folks at Lucene changing their coding style to do that.
> >
> > An example: 3.0.3 changes classes that inherited from
> util.Parameter,
> > to java enums.  Java enums are more similar to classes than
> they are in C#.
> >  They can have methods, fields, etc.  I wound up converting
> them into
> > enums with extension methods and/or static classes (usually to
> > generate the enum).  The way the code was written in Java,
> there's no
> > way a automated tool could figure that out on its own,
> unless you had
> > some sort of way to tell it what to do before hand.
> >
> > I imagine porting it by hand is probably easier, though it would be
> > nice if there was a tool that would at least convert the
> syntax from
> > Java to C#, as well as changing the naming scheme to a .NET
> compatible
> > one.  However, that only really helps if you're porting
> classes from
> > scratch.  It could, also, hide bugs, since it's possible, however
> > unlikely, something could port perfectly, but not behave
> the same way.
> >
> > A class that has many calls to string.Substring is a good
> example of this.
> >  If the name of the function is changed to the .Net version
> > (.substring to .Substring), it would compile no problems,

other possible goals (these can be assigned to any milestone and pushed
back when needed)

*  Enhanced BCL support - interfaces, operator overloads, etc.
*  FxCop support - fix or suppress messages
*  Investigate CLSCompliance  - already partially done by prescott and many
thanks for that.
*  Enhance developer experience - provide updated demos and common
out-of-the box scenarios. i.e. use Attributes & Types to index POCOs, Auto
Complete (jquery/jquery ui, etc), basic website/app search.
Other thoughts. Maybe we should stagger major releases a bit more in order
to have smaller more manageable milestones and get bits into the hands of
people sooner and thus not putting so much pressure on major releases to
get it right the first time.

Work on core, release core as a CTP.  Work on bugs from CTP & Contrib,
release second 2nd CTP, then release Beta, Then RTW.
As for 4x
I'd suggest everyone look the Lucene trunk to gauge the work required and
new changes. A release by next summer would be too agressive even if it was
scaled to just simply porting without thinking about it.

Also 4x would be the best time to make breaking changes since the Java
version breaks changes significantly. This is the one version I would not
want to just get out the door in order to maintain parity with Java. I also
hope passing out of incubation would not depend on this version's release.

On Tue, Nov 22, 2011 at 12:44 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

> My goal is to release 2.9.4 this month - it looks like we have no -1s from
> our dev list so in the next day or so I will put that to the general
> incubator list.
>
> I'd then like to release 2.9.4g the first or second week of January.
>
> My thoughts would be to try and have 3.0.3 ready by march and 4.0 in the
> middle of the year. Im not sure how aggressive people think that is.
>
> With the 4.0 release we should be at or near parity with Java and ready to
> roll out of the incubator. We could do the 4 release and the graduation
> process at the same time as well
>
> Sent from my Windows Phone
> ________________________________
> From: Scott Lombard
> Sent: 11/22/2011 8:56 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Roadmap
>
> Mike,
>
> You're right about putting together a higher level discussion.  Here are
> the
> road map items I see.  I am interested in other have to say.
>
> None of the items I have listed are contigent on the other so they can be
> done in parallel or out of order.
>
>
> 1) Complete the release of 2.9.4
> 2) Create and release 3.0.3
>
> 3) Graduate from the incubator
> 4) Document a porting process that the community can reference.
> 5) Port 4.0
>
>
>
> Scott
>
> > -----Original Message-----
> > From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, November 22, 2011 10:28 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Roadmap
> >
> > While much of the content in this thread is valid and is
> > important, especially concerns, pain points, and
> > implementation details... we've gotten way off topic.
> >
> > road map != implementation details. We should keep to a much
> > a higher level discussion to get this knocked out.
> >
> > Lets outline the roadmap, put it in a wiki page.
> >
> > Then discuss how to go about each major milestone in separate
> > threads to discuss implementation details. Or at least let
> > the people who are going to work on that particular milestone
> > publish their intentions to keep everyone else informed since
> > we're currently in a do-ocracy like state.
> >
> > And by all means, discuss the next immediate milestones first
> > so people who want to dive into that can proceed.
> >
> > So what are the next two major milestones?  And from a higher
> > level perspective what are the major items that deem those
> > milestones complete?
> >
> > What would be the the next 3 ideal milestones after the first
> > two? And what would be the intentions for those milestones to

On 2011-11-22, Michael Herndon wrote:

> other possible goals (these can be assigned to any milestone and
> pushed back when needed)

In the same vain: sort out the build process in a way that doesn't
require the tools to be checked into svn.

Stefan

>
>
> In the same vain: sort out the build process in a way that doesn't
> require the tools to be checked into svn.
https://cwiki.apache.org/confluence/display/LUCENENET/Road+Map

Posting these under floating goals on wiki. I already have some ideas on
how this can be done, so I've linked the above goal to a planning page for
the build.  We'll revisit once the other major items are accomplished on
the planning page.

Edit as necessary =)

- Michael

On 2011-11-22, Prescott Nasser wrote:

> My goal is to release 2.9.4 this month - it looks like we have no -1s
> from our dev list so in the next day or so I will put that to the
> general incubator list.

Please remember to mention you need two more IPMC member votes.

> With the 4.0 release we should be at or near parity with Java and
> ready to roll out of the incubator. We could do the 4 release and the
> graduation process at the same time as well

For my personal taste this is way too late.  There is no reason why
you'd have to be on par with Java Lucene in order to leave the
incubator.

Stefan

> > My goal is to release 2.9.4 this month - it looks like we have no -1s
> > from our dev list so in the next day or so I will put that to the
> > general incubator list.
>
> Please remember to mention you need two more IPMC member votes.

 

I just sent that vote email out - do you want me to update? or do you mind just tossing it a +1?

 
>
> > With the 4.0 release we should be at or near parity with Java and
> > ready to roll out of the incubator. We could do the 4 release and the
> > graduation process at the same time as well
>
> For my personal taste this is way too late. There is no reason why
> you'd have to be on par with Java Lucene in order to leave the
> incubator.
>

 

No problem by me, just from what I saw there are a number of podlings that are in the incubator for a long time. I figured no harm in staying in. But also, it seems like first half of next year is too quick (from those who have already started working on it)

 

~P    

On 2011-11-23, Prescott Nasser wrote:

>>> My goal is to release 2.9.4 this month - it looks like we have no -1s
>>> from our dev list so in the next day or so I will put that to the
>>> general incubator list.

>> Please remember to mention you need two more IPMC member votes.

> I just sent that vote email out - do you want me to update? or do you
> mind just tossing it a +1?

I will follow up to it.

>>> With the 4.0 release we should be at or near parity with Java and
>>> ready to roll out of the incubator. We could do the 4 release and the
>>> graduation process at the same time as well

>> For my personal taste this is way too late. There is no reason why
>> you'd have to be on par with Java Lucene in order to leave the
>> incubator.

> No problem by me, just from what I saw there are a number of podlings
> that are in the incubator for a long time. I figured no harm in
> staying in. But also, it seems like first half of next year is too
> quick (from those who have already started working on it)

Oh, I didn't mean release 4.x earlier, I meant graduate earlier.  There
is no reason to defer graduation until 4.x is ready.

Stefan