After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a line-by-line port.  It ceases to be Lucene.

- Neal

-----Original Message-----
From: Scott Lombard [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 1:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

Those are pretty strong words -- I'd really like to know why I
shouldn't trust anything but a line-by-line port. Can you explain a
bit?

On Wed, Jun 29, 2011 at 3:47 PM, Granroth, Neal V.
<[EMAIL PROTECTED]> wrote:
> This is has been discussed many times.
> Lucene.NET is not valid, the code cannot be trusted, if it is not a line-by-line port.  It ceases to be Lucene.
>
> - Neal
>
> -----Original Message-----
> From: Scott Lombard [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 29, 2011 1:58 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
>
>
> After the large community response about moving the code base from .Net 2.0
> to Net 4.0 I am trying to figure out what is the need for a line-by-line
> port.  Starting with Digy's excellent work on the conversion to generics a
> priority of the 2.9.4g release is the 2 packages would not be
> interchangeable.  So faster turnaround from a java release won't matter to
> non line-by-line users they will have to wait until the updates are made to
> the non line-by-line code base.
>
>
>
> My question is there really a user base for the line-by-line port?  Anyone
> have a comment?
>
>
>
> Scott
>
>
>
>
>
>
>
>

As a Lucene.Net user I wouldn't care whether it is line-by-line port or not.

But as a contributer, I would prefer a parallel code that makes the life
easier for manual ports of new releases(until this process is automated)

PS: I presume no one thinks of functional or index-level incompatibility.

DIGY

-----Original Message-----
From: Granroth, Neal V. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 10:47 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-----Original Message-----
From: Scott Lombard [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 1:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

Others have done a much better , more through job of explaining the issues in previous discussions.  It would be best to re-read those.

One way to understand it, is if Lucene.NET cannot be compared to the reference source code (Lucene core "java Lucene") than it becomes nearly impossible to validate that Lucene.NET is functioning correctly, that bug fixes made in Lucene core have been implemented in Lucene.NET, etc.  The same goes for unit tests, if they cannot be compared with the ones from Lucene core line-by-line than there is no way to know that they perform the intended tests and run correctly.
- Neal
 

-----Original Message-----
From: Wyatt Barnett [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 2:57 PM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Those are pretty strong words -- I'd really like to know why I
shouldn't trust anything but a line-by-line port. Can you explain a
bit?

On Wed, Jun 29, 2011 at 3:47 PM, Granroth, Neal V.
<[EMAIL PROTECTED]> wrote:
> This is has been discussed many times.
> Lucene.NET is not valid, the code cannot be trusted, if it is not a line-by-line port.  It ceases to be Lucene.
>
> - Neal
>
> -----Original Message-----
> From: Scott Lombard [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 29, 2011 1:58 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
>
>
> After the large community response about moving the code base from .Net 2.0
> to Net 4.0 I am trying to figure out what is the need for a line-by-line
> port.  Starting with Digy's excellent work on the conversion to generics a
> priority of the 2.9.4g release is the 2 packages would not be
> interchangeable.  So faster turnaround from a java release won't matter to
> non line-by-line users they will have to wait until the updates are made to
> the non line-by-line code base.
>
>
>
> My question is there really a user base for the line-by-line port?  Anyone
> have a comment?
>
>
>
> Scott
>
>
>
>
>
>
>
>

For the sake of continued conversation, Scott could you define what you mean
by line-by-line port vs non-line-by-line port since technically your the
thread starter?

On Wed, Jun 29, 2011 at 3:58 PM, Digy <[EMAIL PROTECTED]> wrote:

> As a Lucene.Net user I wouldn't care whether it is line-by-line port or
> not.
>
> But as a contributer, I would prefer a parallel code that makes the life
> easier for manual ports of new releases(until this process is automated)
>
> PS: I presume no one thinks of functional or index-level incompatibility.
>
> DIGY
>
> -----Original Message-----
> From: Granroth, Neal V. [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 29, 2011 10:47 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> This is has been discussed many times.
> Lucene.NET is not valid, the code cannot be trusted, if it is not a
> line-by-line port.  It ceases to be Lucene.
>
> - Neal
>
> -----Original Message-----
> From: Scott Lombard [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 29, 2011 1:58 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
>
>
> After the large community response about moving the code base from .Net 2.0
> to Net 4.0 I am trying to figure out what is the need for a line-by-line
> port.  Starting with Digy's excellent work on the conversion to generics a
> priority of the 2.9.4g release is the 2 packages would not be
> interchangeable.  So faster turnaround from a java release won't matter to
> non line-by-line users they will have to wait until the updates are made to
> the non line-by-line code base.
>
>
>
> My question is there really a user base for the line-by-line port?  Anyone
> have a comment?
>
>
>
> Scott
>
>
>
>
>
>
>
>

When I look at the goals of Lucene.Net I am trying to understand what is
more important to Lucene.Net users, .NET functionality or a line-for-line
port.

.NET and Java are close but not the same.  In the past when give the choice
between a better .NET way or stay with the Java implementation the project
chose to keep the Java implementation.  If users don't care that it is a
line-for-line port then contributors will have more freedom to use a better
.NET way, while keeping functionality and index compatibility.  

As contributors we can figure out how to get from the Java to Lucene.Net.
This will probably be an automated tool, but the source that the tool
outputs wouldn't need to be highly polished or even compile.  The primary
purpose would be to simplify the process of get from Java to .NET for a
release.
Scott
> -----Original Message-----
> From: Michael Herndon [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 29, 2011 4:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> For the sake of continued conversation, Scott could you define what you
> mean
> by line-by-line port vs non-line-by-line port since technically your the
> thread starter?
>
>
>
>
>
>
>
> On Wed, Jun 29, 2011 at 3:58 PM, Digy <[EMAIL PROTECTED]> wrote:
>
> > As a Lucene.Net user I wouldn't care whether it is line-by-line port or
> > not.
> >
> > But as a contributer, I would prefer a parallel code that makes the life
> > easier for manual ports of new releases(until this process is automated)
> >
> > PS: I presume no one thinks of functional or index-level
> incompatibility.
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Granroth, Neal V. [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 29, 2011 10:47 PM
> > To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > This is has been discussed many times.
> > Lucene.NET is not valid, the code cannot be trusted, if it is not a
> > line-by-line port.  It ceases to be Lucene.
> >
> > - Neal
> >
> > -----Original Message-----
> > From: Scott Lombard [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, June 29, 2011 1:58 PM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> >
> >
> > After the large community response about moving the code base from .Net
> 2.0
> > to Net 4.0 I am trying to figure out what is the need for a line-by-line
> > port.  Starting with Digy's excellent work on the conversion to generics
> a
> > priority of the 2.9.4g release is the 2 packages would not be
> > interchangeable.  So faster turnaround from a java release won't matter
> to
> > non line-by-line users they will have to wait until the updates are made
> to
> > the non line-by-line code base.
> >
> >
> >
> > My question is there really a user base for the line-by-line port?
> Anyone
> > have a comment?
> >
> >
> >
> > Scott
> >
> >
> >
> >
> >
> >
> >
> >

Hi Scott,
Please avoid crossposting(as I do now). Since when I reply to your eMail, it
goes to one of the lists and thread is splitted into two.
It may be good for announcements but not for discussions.

DIGY

-----Original Message-----
From: Scott Lombard [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 9:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

I do not know if too much emphasis should be placed on "user" vs. "contributor".  The project needs to also consider those of us who use Lucene.NET source releases only.
It is much easier to locally patch/fix the source when I can compare it directly to Lucene core.

- Neal
 

-----Original Message-----
From: Digy [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 2:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

As a Lucene.Net user I wouldn't care whether it is line-by-line port or not.

But as a contributer, I would prefer a parallel code that makes the life
easier for manual ports of new releases(until this process is automated)

PS: I presume no one thinks of functional or index-level incompatibility.

DIGY

-----Original Message-----
From: Granroth, Neal V. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 10:47 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-----Original Message-----
From: Scott Lombard [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 1:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

 

  

 

> I do not know if too much emphasis should be placed on "user" vs.
"contributor".  
I am sorry for this misunderstanding.
What I tried to say with "contributor"(not "committer") was the "people that
works on Lucene.Net source code", not the ones who just consume it.

DIGY

-----Original Message-----
From: Granroth, Neal V. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 11:23 PM
To: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

I do not know if too much emphasis should be placed on "user" vs.
"contributor".  The project needs to also consider those of us who use
Lucene.NET source releases only.
It is much easier to locally patch/fix the source when I can compare it
directly to Lucene core.

- Neal
 

-----Original Message-----
From: Digy [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 2:58 PM
To: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

As a Lucene.Net user I wouldn't care whether it is line-by-line port or not.

But as a contributer, I would prefer a parallel code that makes the life
easier for manual ports of new releases(until this process is automated)

PS: I presume no one thinks of functional or index-level incompatibility.

DIGY

-----Original Message-----
From: Granroth, Neal V. [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 10:47 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-----Original Message-----
From: Scott Lombard [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 1:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net 2.0
to Net 4.0 I am trying to figure out what is the need for a line-by-line
port.  Starting with Digy's excellent work on the conversion to generics a
priority of the 2.9.4g release is the 2 packages would not be
interchangeable.  So faster turnaround from a java release won't matter to
non line-by-line users they will have to wait until the updates are made to
the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?  Anyone
have a comment?

 

Scott

For what it's worth, I've participated in a number of projects which have
been "ported" from Java to .Net with varying levels of "translation" into
the native style and functionalty of the .Net framework. The largest are
NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is that
a line-by-line port isn't as valuable as people would imagine.

Even if we discount the reality that a line-by-line port is really
unachievable due to various differences between the frameworks, keeping even
identical code in sync will always take some work: full automation on this
large of a project is infeasible. During manual effort, therefore, making
readable changes to the code is really not that much more work.

For update maintenance, porting over code from recent versions of both
projects to the .Net versions, and ".Nettifying" that code is little
trouble. Since both projects use source control, it's easy to see the
changes and translate them.

When it comes to debugging issues, in NTS or NHibernate, I go to the Java
sources, and even if the classes were largely rewritten to take advantage of
IEnumerable or generics or structures, running unit tests, tracing the code,
and seeing the output of each has always been straightforward.

Since I'm using .Net, I'd want the Lucene.Net project to be more .Net than a
line-by-line port of Java, in order to take advantage of the Framework as
well as provide a better code base for .Net developers to maintain. If large
.Net projects ported from Java do this, and have found considerable success,
it is, in my view, a well-proven practice and shouldn't be avoided due to
uncertainty of how the resulting code should work. Ultimately, that is what
unit tests are for, anyway.

Hi Rory,
I agree with you in theory. But collecting people to work on a project is
not easy as giving advise.
Till now, line-by-line port have seemed to be the best with a limited human
source.

Would you be willing to work on your approach and maintain newer Lucene.Net
releases?

DIGY

-----Original Message-----
From: Rory Plaire [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 30, 2011 1:06 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

For what it's worth, I've participated in a number of projects which have
been "ported" from Java to .Net with varying levels of "translation" into
the native style and functionalty of the .Net framework. The largest are
NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is that
a line-by-line port isn't as valuable as people would imagine.

Even if we discount the reality that a line-by-line port is really
unachievable due to various differences between the frameworks, keeping even
identical code in sync will always take some work: full automation on this
large of a project is infeasible. During manual effort, therefore, making
readable changes to the code is really not that much more work.

For update maintenance, porting over code from recent versions of both
projects to the .Net versions, and ".Nettifying" that code is little
trouble. Since both projects use source control, it's easy to see the
changes and translate them.

When it comes to debugging issues, in NTS or NHibernate, I go to the Java
sources, and even if the classes were largely rewritten to take advantage of
IEnumerable or generics or structures, running unit tests, tracing the code,
and seeing the output of each has always been straightforward.

Since I'm using .Net, I'd want the Lucene.Net project to be more .Net than a
line-by-line port of Java, in order to take advantage of the Framework as
well as provide a better code base for .Net developers to maintain. If large
.Net projects ported from Java do this, and have found considerable success,
it is, in my view, a well-proven practice and shouldn't be avoided due to
uncertainty of how the resulting code should work. Ultimately, that is what
unit tests are for, anyway.

I pretty much agree with Rory.

And as others have said, this issue has been discussed many times. What is
most important about the fact that it has been discussed many times is that
it has not been resolve, even though it has been discussed so many times.

That means that the both the developer community that contributes to the
project and the user community that uses the library have an interest in
*both*. I think we have enough interest and support from the community to
develop both of these at the same time.

Some key points:
- Being a useful index/search library is the goal of any implementation of
Lucene. Being useful is more important than being identical to one another.
Don't forget that Java Lucene has bugs, design problems, and may not always
be the best implementation of Lucene.
- Unit tests should validate the code's "correctness" in terms of
functionality/bugs
- The library can contain multiple APIs for the same tasks. Fluent? LINQ?
Just Like Java? Just like pylucene? All of the above?
- Implementation details between .NET and Java are *very* significant and
often account for a lot of the bugs that are Lucene.Net only. Our attempt to
be a "line-by-line" port is what is introducing bugs, not the the other way
around
- The only reason we are having this discussion is because C# and Java are
very similar languages. If this was a F# port or a VB.NET port, we wouldn't
even be discussing this. Instead we'd say "make it work the way that makes
the most sense in {{insert language here}}".
That said, DIGY has a very good point. Continued development on the library
is the most important part of the project's goals. A dead project helps no
one. If the current active contributors are writing a line-by-line port,
then that's what it will be. If they are writing a complete re-write, then
that is what it will be. Some might find it easier to write line-by-line,
but others might find that task daunting. The opposite is also true. It
depends on the person, how much time they have, and what they consider
"easy" or "manageable" or "worth doing".

As always, if you want the code base to be something specific, submit a
patch for that, and it will be. If not, then you need to convince someone
else to write that patch. And just so it's clear, *anyone* can write and
submit a patch and be a contributor, not just the project committers.

Thanks,
Troy

On Wed, Jun 29, 2011 at 3:06 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:

> For what it's worth, I've participated in a number of projects which have
> been "ported" from Java to .Net with varying levels of "translation" into
> the native style and functionalty of the .Net framework. The largest are
> NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is
> that
> a line-by-line port isn't as valuable as people would imagine.
>
> Even if we discount the reality that a line-by-line port is really
> unachievable due to various differences between the frameworks, keeping
> even
> identical code in sync will always take some work: full automation on this
> large of a project is infeasible. During manual effort, therefore, making
> readable changes to the code is really not that much more work.
>
> For update maintenance, porting over code from recent versions of both
> projects to the .Net versions, and ".Nettifying" that code is little
> trouble. Since both projects use source control, it's easy to see the
> changes and translate them.
>
> When it comes to debugging issues, in NTS or NHibernate, I go to the Java
> sources, and even if the classes were largely rewritten to take advantage
> of
> IEnumerable or generics or structures, running unit tests, tracing the
> code,
> and seeing the output of each has always been straightforward.
>
> Since I'm using .Net, I'd want the Lucene.Net project to be more .Net than
> a
> line-by-line port of Java, in order to take advantage of the Framework as
> well as provide a better code base for .Net developers to maintain. If
> large
> .Net projects ported from Java do this, and have found considerable

Of course I'd love to contribute. I'm hopeful I can spend even a few hours a
week doing this when (if...) my people adopt NHibernate.Search.

Troy, I'm going to defer to your sense that there is enough interest and
support from the community to maintain both code bases. It is hard, however,
to restrain my skepticism, which I relate in order to record a sort of
warning to consider. In a perfect world two code-bases could live
side-by-side and even benefit each other. In practice, however, I'm doubtful
that this can be symbiotic relationship. If people contribute more to one
than another, it creates an unhealthy uncertainty about the state of the
project. It also splits any potential future project resources who may be
ambivalent about translation vs. transliteration. Open source projects are
often fragile, and it's hard for me to keep from worrying if there would
need to be a sacrifice at some point to keep the project concentrated enough
to remain viable. While the model of open source is such that *anyone* can
contribute, this very mechanism can also lead to projects that are pulled
back and forth among contributor needs and interests, adding complexity and
instability which ultimately doom them.

-r
On Wed, Jun 29, 2011 at 3:47 PM, Troy Howard <[EMAIL PROTECTED]> wrote:

> I pretty much agree with Rory.
>
> And as others have said, this issue has been discussed many times. What is
> most important about the fact that it has been discussed many times is that
> it has not been resolve, even though it has been discussed so many times.
>
> That means that the both the developer community that contributes to the
> project and the user community that uses the library have an interest in
> *both*. I think we have enough interest and support from the community to
> develop both of these at the same time.
>
> Some key points:
> - Being a useful index/search library is the goal of any implementation of
> Lucene. Being useful is more important than being identical to one another.
> Don't forget that Java Lucene has bugs, design problems, and may not always
> be the best implementation of Lucene.
> - Unit tests should validate the code's "correctness" in terms of
> functionality/bugs
> - The library can contain multiple APIs for the same tasks. Fluent? LINQ?
> Just Like Java? Just like pylucene? All of the above?
> - Implementation details between .NET and Java are *very* significant and
> often account for a lot of the bugs that are Lucene.Net only. Our attempt
> to
> be a "line-by-line" port is what is introducing bugs, not the the other way
> around
> - The only reason we are having this discussion is because C# and Java are
> very similar languages. If this was a F# port or a VB.NET port, we
> wouldn't
> even be discussing this. Instead we'd say "make it work the way that makes
> the most sense in {{insert language here}}".
>
>
> That said, DIGY has a very good point. Continued development on the library
> is the most important part of the project's goals. A dead project helps no
> one. If the current active contributors are writing a line-by-line port,
> then that's what it will be. If they are writing a complete re-write, then
> that is what it will be. Some might find it easier to write line-by-line,
> but others might find that task daunting. The opposite is also true. It
> depends on the person, how much time they have, and what they consider
> "easy" or "manageable" or "worth doing".
>
> As always, if you want the code base to be something specific, submit a
> patch for that, and it will be. If not, then you need to convince someone
> else to write that patch. And just so it's clear, *anyone* can write and
> submit a patch and be a contributor, not just the project committers.
>
> Thanks,
> Troy
>
> On Wed, Jun 29, 2011 at 3:06 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:
>
> > For what it's worth, I've participated in a number of projects which have
> > been "ported" from Java to .Net with varying levels of "translation" into

Rory,

We'd love to have your contributions! Any time you can spend on it will be
deeply appreciated.

Also, I understand your skepticism, and I agree that this is a significant
concern.

Unfortunately, that's kind of the best we can do. It's the most fair way to
set project priorities; "Whoever contributes the most wins". This is, in one
sense, the basis of Apache's meritocracy (though many would probably
disagree with that characterization). Actions speak louder than words. We
cannot please everyone, and we cannot arbitrarily decide a direction to go
in and force others to contribute to that vision. We can discuss and be open
about all possibilities, but the contributions are the real force behind the
project direction.

We encourage anyone, from whatever perspective or opinion they may hold, to
*write the code* and submit it for inclusion. If the code looks good, works,
and we can generally agree as a PMC that we should use it, we'll commit it.
That is how the project direction will be shaped.

This is fair, because while we might say that "a lot of people want a
line-by-line port" or we might say that "a lot of people want a .NET
idiomatic port" and those people might vocalize that on the mailing lists,
in the end it's "Who is willing to write code and contribute it to the
project?" which determines the shape of the code base. If there really are a
lot or people on either side of a particular opinion, they will manifest
themselves by writing and contributing (or convincing others to do so) and
thus shaping the project.

Right now, we don't have enough contributions from either side of that
discussion to prove that there is a "strong interest" in either one. We have
generally agreed to "depart from Java", but have not yet discussed the form
of that, or to what degree we want to diverge. That means it's open to
interpretation, discussion, and suggestions. No one has submitted a huge
.NET style re-write, or even seriously discussed what that sufficiently that
someone could take action on it. DIGY, who is our most active contributor,
seems most comfortable (at the moment) with maintaining and improving a
"mostly line-by-line" port. Other than that, we have had relatively few
contributions to the core library.

It could be said that this is a result of a lack of vision or direction from
the committers who are organizing the project, but really, it's not for us
to decide what the community wants. Rather, the community tells us what it
wants by voting with their submitted patches.

Take myself for example... I really, really want to move to a very modern,
.NET idiomatic, fluent, LINQ enabled API, with everything based around
interfaces, generics, injected behaviours using Action/Func<T>, all data
streamable, and all memory correctly freed, everything threadsafe, etc. I
bet there are a lot of people like me out there. However, even though I
would really LIKE it to be that way, I have neither written, nor contributed
code that makes that happen, nor effectively convinced/organized others to
help write it. This is proven by the lack of submitted patches... (well,
Chris Currens' streaming contributions are marginally my fault, since I'm
his boss at work and encouraged/enabled him to work on it on the clock, and
discussed the design and implementation details which helped him to write
it, but I personally didn't write any of that code, and it's mostly his
design and personal passion that made it happen). So, when I actually sit
down and write the code for what I want Lucene.Net to be, or sit down and
write the emails to get other people fired up enough to take action, that's
when my opinion becomes influential to the project.

At the end of the day, what is important is to let the community know that
contributions and discussions of ALL KINDS are welcome. We don't want anyone
to say, "Well, I would help out Lucene.Net, but they are going a different
direction than I want to go, so I'll just keep my changes to myself" (or
worse, just not write any code at all).

In my opinion, we should be using our energy and brainpower to discuss how
we can achieve "this AND that" vs arguing over whether we should do "this OR
that". When you write your patches, try to think of how you can implement
something to support both. We don't need two side-by-side code bases, but
rather one code base that supports all major use cases. This is not easy to
do, but it's almost always possible.

We are a bunch of smart and talented folks. We can do it. It'll be awesome.

Thanks,
Troy
On Wed, Jun 29, 2011 at 5:47 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:

I don't think I'm as hard core on this as Neal, but remember: the
history of the Lucene.NET project is that all the intellectual work, all
the understanding of search, all the new features come from the Lucene
Java folks. Theirs is an immensely respected project, and I trust them
to add new features that will be well-tested and well-researched, and to
have a decent roadmap which I can trust they will execute on.

Now I know there's been an influx of capable developers to Lucene.NET
who are ready, willing and (I'm going to assume) able to add a lot more
value in a generic .NET implementation as they change it. But it'll take
a while before I trust a .NET dedicated framework which is significantly
diverged from Java in the way I do the line-by-line version. And at what
stage is it not just not a line-by-line port, but not a port at all?

At the same time, I recognise that if this project is going to continue,
and attract good developers, it has to change in this direction.

So that said, I can see why a line-by-line port might not be
sustainable. And most people don't need it. But most of us using Lucene
in production systems do need a system that we can trust and rely on. So
let me chime in with someone else's plea, to keep the general structure
close to Lucene, to keep the same general objects and inheritance
set-up, and to keep the same method names, even if you add other methods
and classes to provide additional functionality. ABSOLUTELY the same
file formats. End users benefit a lot from a high degree of similarity,
with good documentation and help being available from the Java
community.

Yours,
Moray
-------------------------------------
Moray McConnachie
Director of IT    +44 1865 261 600
Oxford Analytica  http://www.oxan.com

-----Original Message-----
From: Granroth, Neal V. [mailto:[EMAIL PROTECTED]]
Sent: 29 June 2011 20:47
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-----Original Message-----
From: Scott Lombard [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 1:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

 

After the large community response about moving the code base from .Net
2.0 to Net 4.0 I am trying to figure out what is the need for a
line-by-line port.  Starting with Digy's excellent work on the
conversion to generics a priority of the 2.9.4g release is the 2
packages would not be interchangeable.  So faster turnaround from a java
release won't matter to non line-by-line users they will have to wait
until the updates are made to the non line-by-line code base.  

 

My question is there really a user base for the line-by-line port?
Anyone have a comment?

 

Scott

 

  

 

---------------------------------------------------------
Disclaimer

This message and any attachments are confidential and/or privileged. If this has been sent to you in error, please do not use, retain or disclose them, and contact the sender as soon as possible.

Oxford Analytica Ltd
Registered in England: No. 1196703
5 Alfred Street, Oxford
United Kingdom, OX1 4EH
---------------------------------------------------------

Can I just plug in my bit and say I agree 100% with what Moray has outlined
below.

If we move away from the line by line port then over time we'll loose out on
the momentum that is Lucene and the improvements that they make.
It is only if the Lucene.NET community has expertise in search,  a  deep
knowledge of the project and the community can guarantee that the knowledge
will survive members coming and going should such a consideration be give.

When Lucene.NET has stood on it's feet for a number of years after it has
moved out of Apache incubation should consideration be given to abandoning a
line by line port.
By all means extend and wrap the libraries in .NET equivalents and .NET
goodness like LINQ (we do this internally in our company at the moment); but
leave the core of the project on a line by line port.

Just my tu-pence worth.

Kind Regards
Noel
-----Original Message-----
From: Moray McConnachie
Sent: Thursday, June 30, 2011 10:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

I don't think I'm as hard core on this as Neal, but remember: the
history of the Lucene.NET project is that all the intellectual work, all
the understanding of search, all the new features come from the Lucene
Java folks. Theirs is an immensely respected project, and I trust them
to add new features that will be well-tested and well-researched, and to
have a decent roadmap which I can trust they will execute on.

Now I know there's been an influx of capable developers to Lucene.NET
who are ready, willing and (I'm going to assume) able to add a lot more
value in a generic .NET implementation as they change it. But it'll take
a while before I trust a .NET dedicated framework which is significantly
diverged from Java in the way I do the line-by-line version. And at what
stage is it not just not a line-by-line port, but not a port at all?

At the same time, I recognise that if this project is going to continue,
and attract good developers, it has to change in this direction.

So that said, I can see why a line-by-line port might not be
sustainable. And most people don't need it. But most of us using Lucene
in production systems do need a system that we can trust and rely on. So
let me chime in with someone else's plea, to keep the general structure
close to Lucene, to keep the same general objects and inheritance
set-up, and to keep the same method names, even if you add other methods
and classes to provide additional functionality. ABSOLUTELY the same
file formats. End users benefit a lot from a high degree of similarity,
with good documentation and help being available from the Java
community.

Yours,
Moray
-------------------------------------
Moray McConnachie
Director of IT    +44 1865 261 600
Oxford Analytica  http://www.oxan.com

-----Original Message-----
From: Granroth, Neal V. [mailto:[EMAIL PROTECTED]]
Sent: 29 June 2011 20:47
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

This is has been discussed many times.
Lucene.NET is not valid, the code cannot be trusted, if it is not a
line-by-line port.  It ceases to be Lucene.

- Neal

-----Original Message-----
From: Scott Lombard [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 29, 2011 1:58 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

After the large community response about moving the code base from .Net
2.0 to Net 4.0 I am trying to figure out what is the need for a
line-by-line port.  Starting with Digy's excellent work on the
conversion to generics a priority of the 2.9.4g release is the 2
packages would not be interchangeable.  So faster turnaround from a java
release won't matter to non line-by-line users they will have to wait
until the updates are made to the non line-by-line code base.

My question is there really a user base for the line-by-line port?
Anyone have a comment?

Scott

Disclaimer

This message and any attachments are confidential and/or privileged. If this
has been sent to you in error, please do not use, retain or disclose them,
and contact the sender as soon as possible.

Oxford Analytica Ltd
Registered in England: No. 1196703
5 Alfred Street, Oxford
United Kingdom, OX1 4EH

I don't want to drag this out much longer, but I am curious with people who
hold the "line-by-line" sentiment - are you NHibernate users?

-r

On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght <[EMAIL PROTECTED]> wrote:

> Can I just plug in my bit and say I agree 100% with what Moray has outlined
> below.
>
> If we move away from the line by line port then over time we'll loose out
> on the momentum that is Lucene and the improvements that they make.
> It is only if the Lucene.NET community has expertise in search,  a  deep
> knowledge of the project and the community can guarantee that the knowledge
> will survive members coming and going should such a consideration be give.
>
> When Lucene.NET has stood on it's feet for a number of years after it has
> moved out of Apache incubation should consideration be given to abandoning a
> line by line port.
> By all means extend and wrap the libraries in .NET equivalents and .NET
> goodness like LINQ (we do this internally in our company at the moment); but
> leave the core of the project on a line by line port.
>
> Just my tu-pence worth.
>
> Kind Regards
> Noel
>
>
> -----Original Message----- From: Moray McConnachie
> Sent: Thursday, June 30, 2011 10:25 AM
>
> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
> Cc: lucene-net-dev@incubator.**apache.org<[EMAIL PROTECTED]>
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> I don't think I'm as hard core on this as Neal, but remember: the
> history of the Lucene.NET project is that all the intellectual work, all
> the understanding of search, all the new features come from the Lucene
> Java folks. Theirs is an immensely respected project, and I trust them
> to add new features that will be well-tested and well-researched, and to
> have a decent roadmap which I can trust they will execute on.
>
> Now I know there's been an influx of capable developers to Lucene.NET
> who are ready, willing and (I'm going to assume) able to add a lot more
> value in a generic .NET implementation as they change it. But it'll take
> a while before I trust a .NET dedicated framework which is significantly
> diverged from Java in the way I do the line-by-line version. And at what
> stage is it not just not a line-by-line port, but not a port at all?
>
> At the same time, I recognise that if this project is going to continue,
> and attract good developers, it has to change in this direction.
>
> So that said, I can see why a line-by-line port might not be
> sustainable. And most people don't need it. But most of us using Lucene
> in production systems do need a system that we can trust and rely on. So
> let me chime in with someone else's plea, to keep the general structure
> close to Lucene, to keep the same general objects and inheritance
> set-up, and to keep the same method names, even if you add other methods
> and classes to provide additional functionality. ABSOLUTELY the same
> file formats. End users benefit a lot from a high degree of similarity,
> with good documentation and help being available from the Java
> community.
>
> Yours,
> Moray
> ------------------------------**-------
> Moray McConnachie
> Director of IT    +44 1865 261 600
> Oxford Analytica  http://www.oxan.com
>
> -----Original Message-----
> From: Granroth, Neal V. [mailto:neal.granroth@**thermofisher.com<[EMAIL PROTECTED]>
> ]
> Sent: 29 June 2011 20:47
> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
> Cc: lucene-net-dev@incubator.**apache.org<[EMAIL PROTECTED]>
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> This is has been discussed many times.
> Lucene.NET is not valid, the code cannot be trusted, if it is not a
> line-by-line port.  It ceases to be Lucene.
>
> - Neal
>
> -----Original Message-----
> From: Scott Lombard [mailto:lombardenator@gmail.**com<[EMAIL PROTECTED]>
> ]
> Sent: Wednesday, June 29, 2011 1:58 PM

As someone from the nhibernate project
We stopped following hibernate a while ago, and haven't regretted it
We have mire features, less bugs and better code base

Sent from my Windows Phone From: Rory Plaire
Sent: Thursday, June 30, 2011 19:58
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
I don't want to drag this out much longer, but I am curious with people who
hold the "line-by-line" sentiment - are you NHibernate users?

-r

On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght <[EMAIL PROTECTED]> wrote:

> Can I just plug in my bit and say I agree 100% with what Moray has outlined
> below.
>
> If we move away from the line by line port then over time we'll loose out
> on the momentum that is Lucene and the improvements that they make.
> It is only if the Lucene.NET community has expertise in search,  a  deep
> knowledge of the project and the community can guarantee that the knowledge
> will survive members coming and going should such a consideration be give.
>
> When Lucene.NET has stood on it's feet for a number of years after it has
> moved out of Apache incubation should consideration be given to abandoning a
> line by line port.
> By all means extend and wrap the libraries in .NET equivalents and .NET
> goodness like LINQ (we do this internally in our company at the moment); but
> leave the core of the project on a line by line port.
>
> Just my tu-pence worth.
>
> Kind Regards
> Noel
>
>
> -----Original Message----- From: Moray McConnachie
> Sent: Thursday, June 30, 2011 10:25 AM
>
> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
> Cc: lucene-net-dev@incubator.**apache.org<[EMAIL PROTECTED]>
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> I don't think I'm as hard core on this as Neal, but remember: the
> history of the Lucene.NET project is that all the intellectual work, all
> the understanding of search, all the new features come from the Lucene
> Java folks. Theirs is an immensely respected project, and I trust them
> to add new features that will be well-tested and well-researched, and to
> have a decent roadmap which I can trust they will execute on.
>
> Now I know there's been an influx of capable developers to Lucene.NET
> who are ready, willing and (I'm going to assume) able to add a lot more
> value in a generic .NET implementation as they change it. But it'll take
> a while before I trust a .NET dedicated framework which is significantly
> diverged from Java in the way I do the line-by-line version. And at what
> stage is it not just not a line-by-line port, but not a port at all?
>
> At the same time, I recognise that if this project is going to continue,
> and attract good developers, it has to change in this direction.
>
> So that said, I can see why a line-by-line port might not be
> sustainable. And most people don't need it. But most of us using Lucene
> in production systems do need a system that we can trust and rely on. So
> let me chime in with someone else's plea, to keep the general structure
> close to Lucene, to keep the same general objects and inheritance
> set-up, and to keep the same method names, even if you add other methods
> and classes to provide additional functionality. ABSOLUTELY the same
> file formats. End users benefit a lot from a high degree of similarity,
> with good documentation and help being available from the Java
> community.
>
> Yours,
> Moray
> ------------------------------**-------
> Moray McConnachie
> Director of IT    +44 1865 261 600
> Oxford Analytica  http://www.oxan.com
>
> -----Original Message-----
> From: Granroth, Neal V. [mailto:neal.granroth@**thermofisher.com<[EMAIL PROTECTED]>
> ]
> Sent: 29 June 2011 20:47
> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
> Cc: lucene-net-dev@incubator.**apache.org<[EMAIL PROTECTED]>
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

NHibernate has a much bigger community and more active devs afaict.
The proposed changes as I understand them are not about changing class
structure or APIs, but merely touch hunks of code and rewrite them to
use better .NET practices (yield, generics, LINQ etc). In conjunction
with a move to .NET 4.0 this would increase readability, improve GC and
boost performance.
IMO this doesn't have to be a line-by-line port in order to make porting
of patches easy - what digy seem to be really worried about (and he's
right). As long as the meaning of the code is clear, it shouldn't be a
real problem to apply Java patches to the .NET codebase. And as long as
the test suite keeps being thorough, there's really nothing to fear of.
On 30/06/2011 20:15, Ayende Rahien wrote:

> As someone from the nhibernate project
> We stopped following hibernate a while ago, and haven't regretted it
> We have mire features, less bugs and better code base

Although there are a lot of people using Lucene.Net, this is our
contribution report for the past 5 years.

https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|lin&versionId=-1&issue
Status=all&selectedProjectId=12310290&reportKey=com.sourcelabs.jira.plugin.r
eport.contributions%3Acontributionreport&Next=Next
DIGY

-----Original Message-----
From: Ayende Rahien [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 30, 2011 8:16 PM
To: Rory Plaire; [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

As someone from the nhibernate project
We stopped following hibernate a while ago, and haven't regretted it
We have mire features, less bugs and better code base

Sent from my Windows Phone From: Rory Plaire
Sent: Thursday, June 30, 2011 19:58
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
I don't want to drag this out much longer, but I am curious with people who
hold the "line-by-line" sentiment - are you NHibernate users?

-r

On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght <[EMAIL PROTECTED]> wrote:

> Can I just plug in my bit and say I agree 100% with what Moray has
outlined
> below.
>
> If we move away from the line by line port then over time we'll loose out
> on the momentum that is Lucene and the improvements that they make.
> It is only if the Lucene.NET community has expertise in search,  a  deep
> knowledge of the project and the community can guarantee that the
knowledge
> will survive members coming and going should such a consideration be give.
>
> When Lucene.NET has stood on it's feet for a number of years after it has
> moved out of Apache incubation should consideration be given to abandoning
a
> line by line port.
> By all means extend and wrap the libraries in .NET equivalents and .NET
> goodness like LINQ (we do this internally in our company at the moment);
but
> leave the core of the project on a line by line port.
>
> Just my tu-pence worth.
>
> Kind Regards
> Noel
>
>
> -----Original Message----- From: Moray McConnachie
> Sent: Thursday, June 30, 2011 10:25 AM
>
> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
> Cc:
lucene-net-dev@incubator.**apache.org<[EMAIL PROTECTED]>
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> I don't think I'm as hard core on this as Neal, but remember: the
> history of the Lucene.NET project is that all the intellectual work, all
> the understanding of search, all the new features come from the Lucene
> Java folks. Theirs is an immensely respected project, and I trust them
> to add new features that will be well-tested and well-researched, and to
> have a decent roadmap which I can trust they will execute on.
>
> Now I know there's been an influx of capable developers to Lucene.NET
> who are ready, willing and (I'm going to assume) able to add a lot more
> value in a generic .NET implementation as they change it. But it'll take
> a while before I trust a .NET dedicated framework which is significantly
> diverged from Java in the way I do the line-by-line version. And at what
> stage is it not just not a line-by-line port, but not a port at all?
>
> At the same time, I recognise that if this project is going to continue,
> and attract good developers, it has to change in this direction.
>
> So that said, I can see why a line-by-line port might not be
> sustainable. And most people don't need it. But most of us using Lucene
> in production systems do need a system that we can trust and rely on. So
> let me chime in with someone else's plea, to keep the general structure
> close to Lucene, to keep the same general objects and inheritance
> set-up, and to keep the same method names, even if you add other methods
> and classes to provide additional functionality. ABSOLUTELY the same
> file formats. End users benefit a lot from a high degree of similarity,
[mailto:neal.granroth@**thermofisher.com<[EMAIL PROTECTED]>
lucene-net-dev@incubator.**apache.org<[EMAIL PROTECTED]>
[mailto:lombardenator@gmail.**com<[EMAIL PROTECTED]>

I'd say that is all the more reasons that we need to work smarter and not
harder. I'd also say thats a good reason to make sure we build consensus
rather than just saying whoever commits code wins.

And its a damn good reason to focus on the effort of growing the number of
contributors and lowing the barrier to submitting patches, breaking things
down into pieces that people would feel confident to work on without
being overwhelmed by the complexity of Lucene.Net.

There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
internals and index formats are significantly different including nixing the
current vint file format and using byte[] array slices for Terms instead of
char[].

So while porting 1 to 1 while require less knowledge or thought, its most
likely going to require more hours of work. And Its definitely not going to
guarantee the stability of the code or that its great code.

I'd have to say that its not as stable as most would believe at the moment.

Most of the tests avoid anything that remotely looks like it knows about the
DRY principle and there is a static constructor in the core test case that
throws an exception if it doesn't find an environment variable "TEMP" which
will fail 90% of the tests and nunit will be unable to give you a clear
reason why.  Just to name a few issues I came across working towards getting
Lucene.Net into CI.  I haven't even started really digging in under the
covers of the code yet.

So my suggestion is to chew on this a bit more and build consensus, avoid
fracturing people into sides.  Be open to reservations and concerns that
others have and continue to address them.

- Michael
On Thu, Jun 30, 2011 at 2:10 PM, Digy <[EMAIL PROTECTED]> wrote:

> Although there are a lot of people using Lucene.Net, this is our
> contribution report for the past 5 years.
>
>
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
>
> AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|lin&versionId=-1&issue
>
> Status=all&selectedProjectId=12310290&reportKey=com.sourcelabs.jira.plugin.r
> eport.contributions%3Acontributionreport&Next=Next
>
>
> DIGY
>
> -----Original Message-----
> From: Ayende Rahien [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 8:16 PM
> To: Rory Plaire; [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> As someone from the nhibernate project
> We stopped following hibernate a while ago, and haven't regretted it
> We have mire features, less bugs and better code base
>
> Sent from my Windows Phone From: Rory Plaire
> Sent: Thursday, June 30, 2011 19:58
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> I don't want to drag this out much longer, but I am curious with people who
> hold the "line-by-line" sentiment - are you NHibernate users?
>
> -r
>
> On Thu, Jun 30, 2011 at 2:39 AM, Noel Lysaght <[EMAIL PROTECTED]>
> wrote:
>
> > Can I just plug in my bit and say I agree 100% with what Moray has
> outlined
> > below.
> >
> > If we move away from the line by line port then over time we'll loose out
> > on the momentum that is Lucene and the improvements that they make.
> > It is only if the Lucene.NET community has expertise in search,  a  deep
> > knowledge of the project and the community can guarantee that the
> knowledge
> > will survive members coming and going should such a consideration be
> give.
> >
> > When Lucene.NET has stood on it's feet for a number of years after it has
> > moved out of Apache incubation should consideration be given to
> abandoning
> a
> > line by line port.
> > By all means extend and wrap the libraries in .NET equivalents and .NET
> > goodness like LINQ (we do this internally in our company at the moment);
> but
> > leave the core of the project on a line by line port.
> >
> > Just my tu-pence worth.
> >
> > Kind Regards
> > Noel
> >
> >
> > -----Original Message----- From: Moray McConnachie

Michael,

I agree with everything you said. My point in saying "whoever commits code
wins" was to illustrate the reality of how and why the project has the
current form.

Building consensus is difficult. It is an essential first step before we can
do something like make a list of bit-sized pieces of work that others can
work on.

This is why my real message of "Let's find a way to accommodate both" is so
important. It allows us to build consensus, so that we can settle on a
direction and structure our work.

Until we accomplish that, it really is "whoever commits code wins", and that
is an unhealthy and unmaintainable way to operate.

>From a technical perspective, your statements about the unit tests are
completely accurate. They really need a LOT of reworking. That's the very
first step before making any significant changes. Part of the problem is
that the tests themselves are not well written. The other part is that the
Lucene object model was not designed for testability, and it makes writing
good tests more difficult, and certain tests might not be possible. It will
be difficult to write good unit tests without re-structuring. The biggest
issue is the use of abstract classes with base behaviour vs interfaces or
fully abstracted classes. Makes mocking tough. This is the direction I was
going when I started the Lucere project. I'd like to start in on that work
after the 2.9.4g release.

Thanks,
Troy
On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon <
[EMAIL PROTECTED]> wrote:

> I'd say that is all the more reasons that we need to work smarter and not
> harder. I'd also say thats a good reason to make sure we build consensus
> rather than just saying whoever commits code wins.
>
> And its a damn good reason to focus on the effort of growing the number of
> contributors and lowing the barrier to submitting patches, breaking things
> down into pieces that people would feel confident to work on without
> being overwhelmed by the complexity of Lucene.Net.
>
> There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
> internals and index formats are significantly different including nixing
> the
> current vint file format and using byte[] array slices for Terms instead of
> char[].
>
> So while porting 1 to 1 while require less knowledge or thought, its most
> likely going to require more hours of work. And Its definitely not going to
> guarantee the stability of the code or that its great code.
>
> I'd have to say that its not as stable as most would believe at the moment.
>
> Most of the tests avoid anything that remotely looks like it knows about
> the
> DRY principle and there is a static constructor in the core test case that
> throws an exception if it doesn't find an environment variable "TEMP" which
> will fail 90% of the tests and nunit will be unable to give you a clear
> reason why.  Just to name a few issues I came across working towards
> getting
> Lucene.Net into CI.  I haven't even started really digging in under the
> covers of the code yet.
>
> So my suggestion is to chew on this a bit more and build consensus, avoid
> fracturing people into sides.  Be open to reservations and concerns that
> others have and continue to address them.
>
> - Michael
>
>
> On Thu, Jun 30, 2011 at 2:10 PM, Digy <[EMAIL PROTECTED]> wrote:
>
> > Although there are a lot of people using Lucene.Net, this is our
> > contribution report for the past 5 years.
> >
> >
> >
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
> >
> >
> AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|lin&versionId=-1&issue
> >
> >
> Status=all&selectedProjectId=12310290&reportKey=com.sourcelabs.jira.plugin.r
> > eport.contributions%3Acontributionreport&Next=Next
> >
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Ayende Rahien [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 30, 2011 8:16 PM
> > To: Rory Plaire; [EMAIL PROTECTED]
> > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Michael,
You interpret the report as "whoever commits code wins"? But when I look at it, I see "a lof of talk, no work". .Net community is not interested in contributing.
I really don't understand what hinders people to work on Lucene.Net. As I did for 2.9.4g, grab the code, do whatever you want on it and submit back. If it doesn't fit to the project's direction it can still find a place in contrib or in branch. All of the approaches can live side by side happily in the Lucene.Net repository.

Troy,
I also don't understand why do you wait for 2.9.4g? It is a *branch* and has nothing to do with the trunk. It need not be an offical release and can live in branch as a PoC.
As a result, I got bored to listen to "this should be done that way". What I want to see is "I did it that way, should we continue with this".

DIGY
-----Original Message-----
From: Troy Howard [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 30, 2011 10:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Michael,

I agree with everything you said. My point in saying "whoever commits code
wins" was to illustrate the reality of how and why the project has the
current form.

Building consensus is difficult. It is an essential first step before we can
do something like make a list of bit-sized pieces of work that others can
work on.

This is why my real message of "Let's find a way to accommodate both" is so
important. It allows us to build consensus, so that we can settle on a
direction and structure our work.

Until we accomplish that, it really is "whoever commits code wins", and that
is an unhealthy and unmaintainable way to operate.

>From a technical perspective, your statements about the unit tests are
completely accurate. They really need a LOT of reworking. That's the very
first step before making any significant changes. Part of the problem is
that the tests themselves are not well written. The other part is that the
Lucene object model was not designed for testability, and it makes writing
good tests more difficult, and certain tests might not be possible. It will
be difficult to write good unit tests without re-structuring. The biggest
issue is the use of abstract classes with base behaviour vs interfaces or
fully abstracted classes. Makes mocking tough. This is the direction I was
going when I started the Lucere project. I'd like to start in on that work
after the 2.9.4g release.

Thanks,
Troy
On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon <
[EMAIL PROTECTED]> wrote:

> I'd say that is all the more reasons that we need to work smarter and not
> harder. I'd also say thats a good reason to make sure we build consensus
> rather than just saying whoever commits code wins.
>
> And its a damn good reason to focus on the effort of growing the number of
> contributors and lowing the barrier to submitting patches, breaking things
> down into pieces that people would feel confident to work on without
> being overwhelmed by the complexity of Lucene.Net.
>
> There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
> internals and index formats are significantly different including nixing
> the
> current vint file format and using byte[] array slices for Terms instead of
> char[].
>
> So while porting 1 to 1 while require less knowledge or thought, its most
> likely going to require more hours of work. And Its definitely not going to
> guarantee the stability of the code or that its great code.
>
> I'd have to say that its not as stable as most would believe at the moment.
>
> Most of the tests avoid anything that remotely looks like it knows about
> the
> DRY principle and there is a static constructor in the core test case that
> throws an exception if it doesn't find an environment variable "TEMP" which
> will fail 90% of the tests and nunit will be unable to give you a clear
> reason why.  Just to name a few issues I came across working towards
> getting
> Lucene.Net into CI.  I haven't even started really digging in under the

@Troy,

I've already started working towards fixing unit testing issues, and
prototyping some things that sure DRY up the testing just so that I can get
the tests running on mono.

Those changes are currently in a private git repo, however since we don't
have a CI, I'm need to make some time to manually test those on at least 3
different Os (windowx, osx, and ubuntu) before putting those back into the
2.9.4g branch.

The reason being I need those in working order so that I can do a write up
on pulling those from source and at least running the build script to
compile everything and run the tests for you.  I don't know about everyone
else, but thats a starting point I look for when I go to work on something
or commit something back.

They should make their way back sometime this month.  I think the next thing
I'll do is put my money where my mouth is, spend time break down the rest of
the CI tasks, then seeing how much stuff I can get documented into the wiki.
 The simple faceted search is a decent starting template.

@Digy I agree with the talk, no work.

Though coming from the outside in, I still cringe when I make any commits at
the moment. (even that little .gitnore file)  A) I don't to want to commit
anything  thats going to piss alot of people off, B) I don't want to spend
time/waste time on modifications that are going to be rejected.  C) it took
a good deal of going through things before I felt comfortable to even making
a commit.   D) yes I know I just need to get over it and so does everyone
else (hence the obsession with the unit tests at the moment).

and I think a key to relaying people to get over it, including myself, is to
make the point you had more clear across the board:

*"If it doesn't fit to the project's direction it can still find a place in
contrib or in branch. All of the approaches can live side by side happily in
the Lucene.Net repository." * +1  because that makes feel there is more
leadway to experiment and any decent effort will at least go somewhere to
live and not be wasted.

On Thu, Jun 30, 2011 at 4:19 PM, Digy <[EMAIL PROTECTED]> wrote:

> Michael,
> You interpret the report as "whoever commits code wins"? But when I look at
> it, I see "a lof of talk, no work". .Net community is not interested in
> contributing.
> I really don't understand what hinders people to work on Lucene.Net. As I
> did for 2.9.4g, grab the code, do whatever you want on it and submit back.
> If it doesn't fit to the project's direction it can still find a place in
> contrib or in branch. All of the approaches can live side by side happily in
> the Lucene.Net repository.
>
> Troy,
> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> has nothing to do with the trunk. It need not be an offical release and can
> live in branch as a PoC.
>
>
> As a result, I got bored to listen to "this should be done that way". What
> I want to see is "I did it that way, should we continue with this".
>
> DIGY
>
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Michael,
>
> I agree with everything you said. My point in saying "whoever commits code
> wins" was to illustrate the reality of how and why the project has the
> current form.
>
> Building consensus is difficult. It is an essential first step before we
> can
> do something like make a list of bit-sized pieces of work that others can
> work on.
>
> This is why my real message of "Let's find a way to accommodate both" is so
> important. It allows us to build consensus, so that we can settle on a
> direction and structure our work.
>
> Until we accomplish that, it really is "whoever commits code wins", and
> that
> is an unhealthy and unmaintainable way to operate.
>
> From a technical perspective, your statements about the unit tests are
> completely accurate. They really need a LOT of reworking. That's the very

Ok I think I asked the wrong question.  I am trying to figure out where to
put my time.  I was thinking about working on the automated porting system,
but when I saw the response to the .NET 4.0 discussions I started to
question if that is the right direction.  The community seemed to be more
interested in the .NET features.  

The complexity of the automated tool is going to become very high and will
probably end up with a line-for-line style port.  So I keep asking my self
is the automated tool worth it.  I don't think it is.  

I like the method has been Digy is using for porting the code.  So I guess
for me the real question is Digy where did you see 2.9.4g going next and
what do you need help on?  

Scott
> -----Original Message-----
> From: Digy [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 4:20 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Michael,
> You interpret the report as "whoever commits code wins"? But when I look
> at it, I see "a lof of talk, no work". .Net community is not interested in
> contributing.
> I really don't understand what hinders people to work on Lucene.Net. As I
> did for 2.9.4g, grab the code, do whatever you want on it and submit back.
> If it doesn't fit to the project's direction it can still find a place in
> contrib or in branch. All of the approaches can live side by side happily
> in the Lucene.Net repository.
>
> Troy,
> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> has nothing to do with the trunk. It need not be an offical release and
> can live in branch as a PoC.
>
>
> As a result, I got bored to listen to "this should be done that way". What
> I want to see is "I did it that way, should we continue with this".
>
> DIGY
>
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Michael,
>
> I agree with everything you said. My point in saying "whoever commits code
> wins" was to illustrate the reality of how and why the project has the
> current form.
>
> Building consensus is difficult. It is an essential first step before we
> can
> do something like make a list of bit-sized pieces of work that others can
> work on.
>
> This is why my real message of "Let's find a way to accommodate both" is
> so
> important. It allows us to build consensus, so that we can settle on a
> direction and structure our work.
>
> Until we accomplish that, it really is "whoever commits code wins", and
> that
> is an unhealthy and unmaintainable way to operate.
>
> From a technical perspective, your statements about the unit tests are
> completely accurate. They really need a LOT of reworking. That's the very
> first step before making any significant changes. Part of the problem is
> that the tests themselves are not well written. The other part is that the
> Lucene object model was not designed for testability, and it makes writing
> good tests more difficult, and certain tests might not be possible. It
> will
> be difficult to write good unit tests without re-structuring. The biggest
> issue is the use of abstract classes with base behaviour vs interfaces or
> fully abstracted classes. Makes mocking tough. This is the direction I was
> going when I started the Lucere project. I'd like to start in on that work
> after the 2.9.4g release.
>
> Thanks,
> Troy
>
>
> On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon <
> [EMAIL PROTECTED]> wrote:
>
> > I'd say that is all the more reasons that we need to work smarter and
> not
> > harder. I'd also say thats a good reason to make sure we build consensus
> > rather than just saying whoever commits code wins.
> >
> > And its a damn good reason to focus on the effort of growing the number
> of
> > contributors and lowing the barrier to submitting patches, breaking

> A) I don't to want to commit anything  thats going to piss alot of people
off,
> B) I don't want to spend time/waste time on modifications that are going
to be rejected.  

What I've learnt from "Apache Way" is creating a JIRA issue if you are
hesitant.
If no one answers in a reasonable time(mostly), then commit.

DIGY

-----Original Message-----
From: Michael Herndon [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 30, 2011 11:58 PM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

@Troy,

I've already started working towards fixing unit testing issues, and
prototyping some things that sure DRY up the testing just so that I can get
the tests running on mono.

Those changes are currently in a private git repo, however since we don't
have a CI, I'm need to make some time to manually test those on at least 3
different Os (windowx, osx, and ubuntu) before putting those back into the
2.9.4g branch.

The reason being I need those in working order so that I can do a write up
on pulling those from source and at least running the build script to
compile everything and run the tests for you.  I don't know about everyone
else, but thats a starting point I look for when I go to work on something
or commit something back.

They should make their way back sometime this month.  I think the next thing
I'll do is put my money where my mouth is, spend time break down the rest of
the CI tasks, then seeing how much stuff I can get documented into the wiki.
 The simple faceted search is a decent starting template.

@Digy I agree with the talk, no work.

Though coming from the outside in, I still cringe when I make any commits at
the moment. (even that little .gitnore file)  A) I don't to want to commit
anything  thats going to piss alot of people off, B) I don't want to spend
time/waste time on modifications that are going to be rejected.  C) it took
a good deal of going through things before I felt comfortable to even making
a commit.   D) yes I know I just need to get over it and so does everyone
else (hence the obsession with the unit tests at the moment).

and I think a key to relaying people to get over it, including myself, is to
make the point you had more clear across the board:

*"If it doesn't fit to the project's direction it can still find a place in
contrib or in branch. All of the approaches can live side by side happily in
the Lucene.Net repository." * +1  because that makes feel there is more
leadway to experiment and any decent effort will at least go somewhere to
live and not be wasted.

On Thu, Jun 30, 2011 at 4:19 PM, Digy <[EMAIL PROTECTED]> wrote:

> Michael,
> You interpret the report as "whoever commits code wins"? But when I look
at
> it, I see "a lof of talk, no work". .Net community is not interested in
> contributing.
> I really don't understand what hinders people to work on Lucene.Net. As I
> did for 2.9.4g, grab the code, do whatever you want on it and submit back.
> If it doesn't fit to the project's direction it can still find a place in
> contrib or in branch. All of the approaches can live side by side happily
in
> the Lucene.Net repository.
>
> Troy,
> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> has nothing to do with the trunk. It need not be an offical release and
can
> live in branch as a PoC.
>
>
> As a result, I got bored to listen to "this should be done that way". What
> I want to see is "I did it that way, should we continue with this".
>
> DIGY
>
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Michael,
>
> I agree with everything you said. My point in saying "whoever commits code
> wins" was to illustrate the reality of how and why the project has the
> current form.
>
> Building consensus is difficult. It is an essential first step before we
so
will
not
most
avoid
https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|lin&versionId=-1&issue
Status=all&selectedProjectId=12310290&reportKey=com.sourcelabs.jira.plugin.r
people
loose
it
and
Lucene.NET
on.
wait

DIGY - Re: Why do I wait.. That's mostly because I intend to make some deep
changes, which would make merging the 2.9.4g branch back to trunk difficult.
So, it's easier to merge those changes first. Also, I won't have enough time
to make my changes until a little way in the future, but probably do have
the time to put together another release, so I'll do that first because it
fits with my work/life schedule.

Thanks,
Troy
On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:

> Michael,
> You interpret the report as "whoever commits code wins"? But when I look at
> it, I see "a lof of talk, no work". .Net community is not interested in
> contributing.
> I really don't understand what hinders people to work on Lucene.Net. As I
> did for 2.9.4g, grab the code, do whatever you want on it and submit back.
> If it doesn't fit to the project's direction it can still find a place in
> contrib or in branch. All of the approaches can live side by side happily in
> the Lucene.Net repository.
>
> Troy,
> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> has nothing to do with the trunk. It need not be an offical release and can
> live in branch as a PoC.
>
>
> As a result, I got bored to listen to "this should be done that way". What
> I want to see is "I did it that way, should we continue with this".
>
> DIGY
>
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Michael,
>
> I agree with everything you said. My point in saying "whoever commits code
> wins" was to illustrate the reality of how and why the project has the
> current form.
>
> Building consensus is difficult. It is an essential first step before we
> can
> do something like make a list of bit-sized pieces of work that others can
> work on.
>
> This is why my real message of "Let's find a way to accommodate both" is so
> important. It allows us to build consensus, so that we can settle on a
> direction and structure our work.
>
> Until we accomplish that, it really is "whoever commits code wins", and
> that
> is an unhealthy and unmaintainable way to operate.
>
> From a technical perspective, your statements about the unit tests are
> completely accurate. They really need a LOT of reworking. That's the very
> first step before making any significant changes. Part of the problem is
> that the tests themselves are not well written. The other part is that the
> Lucene object model was not designed for testability, and it makes writing
> good tests more difficult, and certain tests might not be possible. It will
> be difficult to write good unit tests without re-structuring. The biggest
> issue is the use of abstract classes with base behaviour vs interfaces or
> fully abstracted classes. Makes mocking tough. This is the direction I was
> going when I started the Lucere project. I'd like to start in on that work
> after the 2.9.4g release.
>
> Thanks,
> Troy
>
>
> On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon <
> [EMAIL PROTECTED]> wrote:
>
> > I'd say that is all the more reasons that we need to work smarter and not
> > harder. I'd also say thats a good reason to make sure we build consensus
> > rather than just saying whoever commits code wins.
> >
> > And its a damn good reason to focus on the effort of growing the number
> of
> > contributors and lowing the barrier to submitting patches, breaking
> things
> > down into pieces that people would feel confident to work on without
> > being overwhelmed by the complexity of Lucene.Net.
> >
> > There is a pretty big gap between Lucene 2.9.x to Lucene 4.0 and the
> > internals and index formats are significantly different including nixing
> > the
> > current vint file format and using byte[] array slices for Terms instead
> of
> > char[].
> >
> > So while porting 1 to 1 while require less knowledge or thought, its most

Scott -

The idea of the automated port is still worth doing. Perhaps it makes sense
for someone more passionate about the line-by-line idea to do that work?

I would say, focus on what makes sense to you. Being productive, regardless
of the specific direction, is what will be most valuable. Once you start,
others will join and momentum will build. That is how these things work.

I like DIGY's approach too, but the problem with it is that it is a
never-ending manual task. The theory behind the automated port is that it
may reduce the manual work. It is complicated, but once it's built and
works, it will save a lot of future development hours. If it's built in a
sufficiently general manner, it could be useful for other project like
Lucene.Net that want to automate a port from Java to C#.

It might make sense for that to be a separate project from Lucene.Net
though.

-T
On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard <[EMAIL PROTECTED]>wrote:

> Ok I think I asked the wrong question.  I am trying to figure out where to
> put my time.  I was thinking about working on the automated porting system,
> but when I saw the response to the .NET 4.0 discussions I started to
> question if that is the right direction.  The community seemed to be more
> interested in the .NET features.
>
> The complexity of the automated tool is going to become very high and will
> probably end up with a line-for-line style port.  So I keep asking my self
> is the automated tool worth it.  I don't think it is.
>
> I like the method has been Digy is using for porting the code.  So I guess
> for me the real question is Digy where did you see 2.9.4g going next and
> what do you need help on?
>
> Scott
>
>
>
>
> > -----Original Message-----
> > From: Digy [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 30, 2011 4:20 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > Michael,
> > You interpret the report as "whoever commits code wins"? But when I look
> > at it, I see "a lof of talk, no work". .Net community is not interested
> in
> > contributing.
> > I really don't understand what hinders people to work on Lucene.Net. As I
> > did for 2.9.4g, grab the code, do whatever you want on it and submit
> back.
> > If it doesn't fit to the project's direction it can still find a place in
> > contrib or in branch. All of the approaches can live side by side happily
> > in the Lucene.Net repository.
> >
> > Troy,
> > I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> > has nothing to do with the trunk. It need not be an offical release and
> > can live in branch as a PoC.
> >
> >
> > As a result, I got bored to listen to "this should be done that way".
> What
> > I want to see is "I did it that way, should we continue with this".
> >
> > DIGY
> >
> >
> >
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 30, 2011 10:47 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > Michael,
> >
> > I agree with everything you said. My point in saying "whoever commits
> code
> > wins" was to illustrate the reality of how and why the project has the
> > current form.
> >
> > Building consensus is difficult. It is an essential first step before we
> > can
> > do something like make a list of bit-sized pieces of work that others can
> > work on.
> >
> > This is why my real message of "Let's find a way to accommodate both" is
> > so
> > important. It allows us to build consensus, so that we can settle on a
> > direction and structure our work.
> >
> > Until we accomplish that, it really is "whoever commits code wins", and
> > that
> > is an unhealthy and unmaintainable way to operate.
> >
> > From a technical perspective, your statements about the unit tests are
> > completely accurate. They really need a LOT of reworking. That's the very
>

Michael -

If you bring those changes from git into a branch in SVN, we can help with
it. It doesn't have to be complete to be committed. :)

Regarding A (angering people)/B (being rejected)/C (feeling comfortable)/D
(getting over it)...

a) Making progress is more important than keeping everyone happy
b) Our goal is to accept things, not reject them. That said, if something
gets rejected due to quality issues, don't be afraid of that, it's a
learning experience for everyone, and it's a good thing. We can work
together to get to something everyone is happy with and learn in the
process.
c) Commit to a branch. Merge when things are right. No one expects branches
to build or be finished. It's OK. I get worried when I merge to trunk or
when I make a release. But I don't do that until I'm pretty sure it's all
legit.
d) Best way to get over it is to start doing it

I know you probably already realize all of this, but I wanted to respond, so
that, in case anyone else out there is struggling with the same set of
fears, they can see that fears that prevent action are more problematic than
any action they might take without those fears.

Thanks,
Troy
On Thu, Jun 30, 2011 at 1:57 PM, Michael Herndon <
[EMAIL PROTECTED]> wrote:

> @Troy,
>
> I've already started working towards fixing unit testing issues, and
> prototyping some things that sure DRY up the testing just so that I can get
> the tests running on mono.
>
> Those changes are currently in a private git repo, however since we don't
> have a CI, I'm need to make some time to manually test those on at least 3
> different Os (windowx, osx, and ubuntu) before putting those back into the
> 2.9.4g branch.
>
> The reason being I need those in working order so that I can do a write up
> on pulling those from source and at least running the build script to
> compile everything and run the tests for you.  I don't know about everyone
> else, but thats a starting point I look for when I go to work on something
> or commit something back.
>
> They should make their way back sometime this month.  I think the next
> thing
> I'll do is put my money where my mouth is, spend time break down the rest
> of
> the CI tasks, then seeing how much stuff I can get documented into the
> wiki.
>  The simple faceted search is a decent starting template.
>
> @Digy I agree with the talk, no work.
>
> Though coming from the outside in, I still cringe when I make any commits
> at
> the moment. (even that little .gitnore file)  A) I don't to want to commit
> anything  thats going to piss alot of people off, B) I don't want to spend
> time/waste time on modifications that are going to be rejected.  C) it took
> a good deal of going through things before I felt comfortable to even
> making
> a commit.   D) yes I know I just need to get over it and so does everyone
> else (hence the obsession with the unit tests at the moment).
>
> and I think a key to relaying people to get over it, including myself, is
> to
> make the point you had more clear across the board:
>
> *"If it doesn't fit to the project's direction it can still find a place in
> contrib or in branch. All of the approaches can live side by side happily
> in
> the Lucene.Net repository." * +1  because that makes feel there is more
> leadway to experiment and any decent effort will at least go somewhere to
> live and not be wasted.
>
> On Thu, Jun 30, 2011 at 4:19 PM, Digy <[EMAIL PROTECTED]> wrote:
>
> > Michael,
> > You interpret the report as "whoever commits code wins"? But when I look
> at
> > it, I see "a lof of talk, no work". .Net community is not interested in
> > contributing.
> > I really don't understand what hinders people to work on Lucene.Net. As I
> > did for 2.9.4g, grab the code, do whatever you want on it and submit
> back.
> > If it doesn't fit to the project's direction it can still find a place in
> > contrib or in branch. All of the approaches can live side by side happily
> in
> > the Lucene.Net repository.
> >
> > Troy,

> Ok I think I asked the wrong question
Yes, you started the flame war :)

* What I realy hate in code is the AnonymousXXXX classes inhereted from JLCA
which make the code impossible to read.
I changed a few in 2.9.4g with replacing the single abstract method with
Func<> or Action<>

like in FilterCache<T>
from:
protected abstract object MergeDeletes(IndexReader reader, object value);
to:
Func<IndexReader, object, object> MergeDeletes;

but there are zillions of those with more than 1 abstract method. I still
think of how to replace them with something suitable without diverging much
from Java.
* I am also not satisfied with return parameters like ICollection<>,
IList<>, IEnumerator<> etc.
These should be standardized some way.
* Support.Set<T> & Support.Dictionary<K, V> classes are just fast solutions
to the problem
"java's collections return null when an item does not exist in the
collection whereas .NET throws exception". A better way may be used.

* missing IEquatable<T>'s

* making Iterators as real .NET Enumerators

etc. etc. etc.
It seems to be a never ending story.
DIGY
-----Original Message-----
From: Scott Lombard [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 01, 2011 12:13 AM
To: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Ok I think I asked the wrong question.  I am trying to figure out where to
put my time.  I was thinking about working on the automated porting system,
but when I saw the response to the .NET 4.0 discussions I started to
question if that is the right direction.  The community seemed to be more
interested in the .NET features.  

The complexity of the automated tool is going to become very high and will
probably end up with a line-for-line style port.  So I keep asking my self
is the automated tool worth it.  I don't think it is.  

I like the method has been Digy is using for porting the code.  So I guess
for me the real question is Digy where did you see 2.9.4g going next and
what do you need help on?  

Scott
> -----Original Message-----
> From: Digy [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 4:20 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Michael,
> You interpret the report as "whoever commits code wins"? But when I look
> at it, I see "a lof of talk, no work". .Net community is not interested in
> contributing.
> I really don't understand what hinders people to work on Lucene.Net. As I
> did for 2.9.4g, grab the code, do whatever you want on it and submit back.
> If it doesn't fit to the project's direction it can still find a place in
> contrib or in branch. All of the approaches can live side by side happily
> in the Lucene.Net repository.
>
> Troy,
> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> has nothing to do with the trunk. It need not be an offical release and
> can live in branch as a PoC.
>
>
> As a result, I got bored to listen to "this should be done that way". What
> I want to see is "I did it that way, should we continue with this".
>
> DIGY
>
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Michael,
>
> I agree with everything you said. My point in saying "whoever commits code
> wins" was to illustrate the reality of how and why the project has the
> current form.
>
> Building consensus is difficult. It is an essential first step before we
> can
> do something like make a list of bit-sized pieces of work that others can
> work on.
>
> This is why my real message of "Let's find a way to accommodate both" is
> so
> important. It allows us to build consensus, so that we can settle on a
> direction and structure our work.
>
> Until we accomplish that, it really is "whoever commits code wins", and

I can not say I like this approach, but till we find an automated way(with good results), it seems to be the only way we can use.

DIGY

-----Original Message-----
From: Troy Howard [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 01, 2011 12:43 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Scott -

The idea of the automated port is still worth doing. Perhaps it makes sense
for someone more passionate about the line-by-line idea to do that work?

I would say, focus on what makes sense to you. Being productive, regardless
of the specific direction, is what will be most valuable. Once you start,
others will join and momentum will build. That is how these things work.

I like DIGY's approach too, but the problem with it is that it is a
never-ending manual task. The theory behind the automated port is that it
may reduce the manual work. It is complicated, but once it's built and
works, it will save a lot of future development hours. If it's built in a
sufficiently general manner, it could be useful for other project like
Lucene.Net that want to automate a port from Java to C#.

It might make sense for that to be a separate project from Lucene.Net
though.

-T
On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard <[EMAIL PROTECTED]>wrote:

> Ok I think I asked the wrong question.  I am trying to figure out where to
> put my time.  I was thinking about working on the automated porting system,
> but when I saw the response to the .NET 4.0 discussions I started to
> question if that is the right direction.  The community seemed to be more
> interested in the .NET features.
>
> The complexity of the automated tool is going to become very high and will
> probably end up with a line-for-line style port.  So I keep asking my self
> is the automated tool worth it.  I don't think it is.
>
> I like the method has been Digy is using for porting the code.  So I guess
> for me the real question is Digy where did you see 2.9.4g going next and
> what do you need help on?
>
> Scott
>
>
>
>
> > -----Original Message-----
> > From: Digy [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 30, 2011 4:20 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > Michael,
> > You interpret the report as "whoever commits code wins"? But when I look
> > at it, I see "a lof of talk, no work". .Net community is not interested
> in
> > contributing.
> > I really don't understand what hinders people to work on Lucene.Net. As I
> > did for 2.9.4g, grab the code, do whatever you want on it and submit
> back.
> > If it doesn't fit to the project's direction it can still find a place in
> > contrib or in branch. All of the approaches can live side by side happily
> > in the Lucene.Net repository.
> >
> > Troy,
> > I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> > has nothing to do with the trunk. It need not be an offical release and
> > can live in branch as a PoC.
> >
> >
> > As a result, I got bored to listen to "this should be done that way".
> What
> > I want to see is "I did it that way, should we continue with this".
> >
> > DIGY
> >
> >
> >
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 30, 2011 10:47 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > Michael,
> >
> > I agree with everything you said. My point in saying "whoever commits
> code
> > wins" was to illustrate the reality of how and why the project has the
> > current form.
> >
> > Building consensus is difficult. It is an essential first step before we
> > can
> > do something like make a list of bit-sized pieces of work that others can
> > work on.
> >
> > This is why my real message of "Let's find a way to accommodate both" is
> > so
> > important. It allows us to build consensus, so that we can settle on a

So, veering towards action - are there concrete tasks written up anywhere
for the unit tests? If a poor schlep like me wanted to dig in and start to
improve them, where would I get the understanding of what is good and what
needs help?

-r

On Thu, Jun 30, 2011 at 3:29 PM, Digy <[EMAIL PROTECTED]> wrote:

> I can not say I like this approach, but till we find an automated way(with
> good results), it seems to be the only way we can use.
>
> DIGY
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 01, 2011 12:43 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Scott -
>
> The idea of the automated port is still worth doing. Perhaps it makes sense
> for someone more passionate about the line-by-line idea to do that work?
>
> I would say, focus on what makes sense to you. Being productive, regardless
> of the specific direction, is what will be most valuable. Once you start,
> others will join and momentum will build. That is how these things work.
>
> I like DIGY's approach too, but the problem with it is that it is a
> never-ending manual task. The theory behind the automated port is that it
> may reduce the manual work. It is complicated, but once it's built and
> works, it will save a lot of future development hours. If it's built in a
> sufficiently general manner, it could be useful for other project like
> Lucene.Net that want to automate a port from Java to C#.
>
> It might make sense for that to be a separate project from Lucene.Net
> though.
>
> -T
>
>
> On Thu, Jun 30, 2011 at 2:13 PM, Scott Lombard <[EMAIL PROTECTED]
> >wrote:
>
> > Ok I think I asked the wrong question.  I am trying to figure out where
> to
> > put my time.  I was thinking about working on the automated porting
> system,
> > but when I saw the response to the .NET 4.0 discussions I started to
> > question if that is the right direction.  The community seemed to be more
> > interested in the .NET features.
> >
> > The complexity of the automated tool is going to become very high and
> will
> > probably end up with a line-for-line style port.  So I keep asking my
> self
> > is the automated tool worth it.  I don't think it is.
> >
> > I like the method has been Digy is using for porting the code.  So I
> guess
> > for me the real question is Digy where did you see 2.9.4g going next and
> > what do you need help on?
> >
> > Scott
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Digy [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, June 30, 2011 4:20 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
> needed?
> > >
> > > Michael,
> > > You interpret the report as "whoever commits code wins"? But when I
> look
> > > at it, I see "a lof of talk, no work". .Net community is not interested
> > in
> > > contributing.
> > > I really don't understand what hinders people to work on Lucene.Net. As
> I
> > > did for 2.9.4g, grab the code, do whatever you want on it and submit
> > back.
> > > If it doesn't fit to the project's direction it can still find a place
> in
> > > contrib or in branch. All of the approaches can live side by side
> happily
> > > in the Lucene.Net repository.
> > >
> > > Troy,
> > > I also don't understand why do you wait for 2.9.4g? It is a *branch*
> and
> > > has nothing to do with the trunk. It need not be an offical release and
> > > can live in branch as a PoC.
> > >
> > >
> > > As a result, I got bored to listen to "this should be done that way".
> > What
> > > I want to see is "I did it that way, should we continue with this".
> > >
> > > DIGY
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, June 30, 2011 10:47 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
> needed?
> > >
> > > Michael,

@Rory, @All,

The only tickets I currently have for those is LUCENE-419, LUCENE-418

418, I should be able to push into the 2.9.4g branch tonight.    419 is a
long term goal and not as important as getting the tests fixed, of have the
tests broken down into what is actually a unit test, functional test, perf
or long running test. I can get into more why it needs to be done.

I'll also need to make document the what build script currently does on the
wiki & and make a few notes about testing, like using the RAMDirectory,
etc.

Things that need to get done or even be discussed.
 * There needs to be a running list of things to do/not to do with testing.
I don't know if this goes in a jira or do we keep a running list on the wiki
or site for people to pick up and  help with.
 * Tests need to run on mono and not Fail (there is a good deal of failing
tests on mono, mostly due to the temp directory have the C:\ in the path).
 * Assert.Throw<ExceptionType>() needs to be used instead of Try/Catch
Assert.Fail.  **
 * File & Path combines to the temp directory need helper methods,
     * e,g, having this in a hundred places is bad   new
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
""), "testIndex"));
 * We should still be testing deprecated methods, but we need to use #pragma
warning disable/enable 0618  for testing those. otherwise compiler warnings
are too numerous to be anywhere near helpful.
 * We should only be using deprecated methods in places where they are being
explicitly tested, other tests that need that functionality in order to
validate those tests should be re factored to use methods that are not
deprecated.
 * Identify code that could be abstracted into test utility classes.
 * Infrastructure Validation tests need to be made, anything that seems like
infrastructure.  e.g. does the temp directory exist, does the folders that
the tests use inside the temp directory exist, can we read/write to those
folders. (if a ton of tests fail due to the file system, we should be able
to point out that it was due to permissions or missing folders, files,
etc).
 * Identify what classes need an interface, abstract class or inherited in
order to create testing mocks. (once those classes are created, they should
be documented in the wiki).

** Asset.Throws needs to replace stuff like the following. We should also be
checking the messages for exceptions and make sure they make sense and can
help users fix isses if the exceptions are aimed at the library users.
try
{
d = DateTools.StringToDate("97"); // no date
Assert.Fail();
}
catch (System.FormatException e)
{
/* expected exception */
}

On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:

> So, veering towards action - are there concrete tasks written up anywhere
> for the unit tests? If a poor schlep like me wanted to dig in and start to
> improve them, where would I get the understanding of what is good and what
> needs help?
>
> -r
>
> On Thu, Jun 30, 2011 at 3:29 PM, Digy <[EMAIL PROTECTED]> wrote:
>
> > I can not say I like this approach, but till we find an automated
> way(with
> > good results), it seems to be the only way we can use.
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, July 01, 2011 12:43 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > Scott -
> >
> > The idea of the automated port is still worth doing. Perhaps it makes
> sense
> > for someone more passionate about the line-by-line idea to do that work?
> >
> > I would say, focus on what makes sense to you. Being productive,
> regardless
> > of the specific direction, is what will be most valuable. Once you start,
> > others will join and momentum will build. That is how these things work.
> >
> > I like DIGY's approach too, but the problem with it is that it is a
> > never-ending manual task. The theory behind the automated port is that it

* need to document what the build script does.  whut grammerz?

On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
[EMAIL PROTECTED]> wrote:

> @Rory, @All,
>
> The only tickets I currently have for those is LUCENE-419, LUCENE-418
>
> 418, I should be able to push into the 2.9.4g branch tonight.    419 is a
> long term goal and not as important as getting the tests fixed, of have the
> tests broken down into what is actually a unit test, functional test, perf
> or long running test. I can get into more why it needs to be done.
>
> I'll also need to make document the what build script currently does on the
> wiki & and make a few notes about testing, like using the RAMDirectory,
> etc.
>
> Things that need to get done or even be discussed.
>  * There needs to be a running list of things to do/not to do with testing.
> I don't know if this goes in a jira or do we keep a running list on the wiki
> or site for people to pick up and  help with.
>  * Tests need to run on mono and not Fail (there is a good deal of failing
> tests on mono, mostly due to the temp directory have the C:\ in the path).
>  * Assert.Throw<ExceptionType>() needs to be used instead of Try/Catch
> Assert.Fail.  **
>  * File & Path combines to the temp directory need helper methods,
>      * e,g, having this in a hundred places is bad   new
> System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> ""), "testIndex"));
>  * We should still be testing deprecated methods, but we need to use #pragma
> warning disable/enable 0618  for testing those. otherwise compiler warnings
> are too numerous to be anywhere near helpful.
>  * We should only be using deprecated methods in places where they are
> being explicitly tested, other tests that need that functionality in order
> to validate those tests should be re factored to use methods that are not
> deprecated.
>  * Identify code that could be abstracted into test utility classes.
>  * Infrastructure Validation tests need to be made, anything that seems
> like infrastructure.  e.g. does the temp directory exist, does the folders
> that the tests use inside the temp directory exist, can we read/write to
> those folders. (if a ton of tests fail due to the file system, we should be
> able to point out that it was due to permissions or missing folders, files,
> etc).
>  * Identify what classes need an interface, abstract class or inherited in
> order to create testing mocks. (once those classes are created, they should
> be documented in the wiki).
>
>
>
> ** Asset.Throws needs to replace stuff like the following. We should also
> be checking the messages for exceptions and make sure they make sense and
> can help users fix isses if the exceptions are aimed at the library users.
> try
> {
> d = DateTools.StringToDate("97"); // no date
>  Assert.Fail();
> }
> catch (System.FormatException e)
>  {
> /* expected exception */
> }
>
> On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire <[EMAIL PROTECTED]>wrote:
>
>> So, veering towards action - are there concrete tasks written up anywhere
>> for the unit tests? If a poor schlep like me wanted to dig in and start to
>> improve them, where would I get the understanding of what is good and what
>> needs help?
>>
>> -r
>>
>> On Thu, Jun 30, 2011 at 3:29 PM, Digy <[EMAIL PROTECTED]> wrote:
>>
>> > I can not say I like this approach, but till we find an automated
>> way(with
>> > good results), it seems to be the only way we can use.
>> >
>> > DIGY
>> >
>> > -----Original Message-----
>> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
>> > Sent: Friday, July 01, 2011 12:43 AM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>> >
>> > Scott -
>> >
>> > The idea of the automated port is still worth doing. Perhaps it makes
>> sense
>> > for someone more passionate about the line-by-line idea to do that work?
>> >
>> > I would say, focus on what makes sense to you. Being productive,
>> regardless

@Michael -

Should that list be in JIRA? It would be easier to manage, I think...

If yes, I'll happily do it.

-r

On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon <[EMAIL PROTECTED]
> wrote:

> * need to document what the build script does.  whut grammerz?
>
> On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
> [EMAIL PROTECTED]> wrote:
>
> > @Rory, @All,
> >
> > The only tickets I currently have for those is LUCENE-419, LUCENE-418
> >
> > 418, I should be able to push into the 2.9.4g branch tonight.    419 is a
> > long term goal and not as important as getting the tests fixed, of have
> the
> > tests broken down into what is actually a unit test, functional test,
> perf
> > or long running test. I can get into more why it needs to be done.
> >
> > I'll also need to make document the what build script currently does on
> the
> > wiki & and make a few notes about testing, like using the RAMDirectory,
> > etc.
> >
> > Things that need to get done or even be discussed.
> >  * There needs to be a running list of things to do/not to do with
> testing.
> > I don't know if this goes in a jira or do we keep a running list on the
> wiki
> > or site for people to pick up and  help with.
> >  * Tests need to run on mono and not Fail (there is a good deal of
> failing
> > tests on mono, mostly due to the temp directory have the C:\ in the
> path).
> >  * Assert.Throw<ExceptionType>() needs to be used instead of Try/Catch
> > Assert.Fail.  **
> >  * File & Path combines to the temp directory need helper methods,
> >      * e,g, having this in a hundred places is bad   new
> >
> System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> > ""), "testIndex"));
> >  * We should still be testing deprecated methods, but we need to use
> #pragma
> > warning disable/enable 0618  for testing those. otherwise compiler
> warnings
> > are too numerous to be anywhere near helpful.
> >  * We should only be using deprecated methods in places where they are
> > being explicitly tested, other tests that need that functionality in
> order
> > to validate those tests should be re factored to use methods that are not
> > deprecated.
> >  * Identify code that could be abstracted into test utility classes.
> >  * Infrastructure Validation tests need to be made, anything that seems
> > like infrastructure.  e.g. does the temp directory exist, does the
> folders
> > that the tests use inside the temp directory exist, can we read/write to
> > those folders. (if a ton of tests fail due to the file system, we should
> be
> > able to point out that it was due to permissions or missing folders,
> files,
> > etc).
> >  * Identify what classes need an interface, abstract class or inherited
> in
> > order to create testing mocks. (once those classes are created, they
> should
> > be documented in the wiki).
> >
> >
> >
> > ** Asset.Throws needs to replace stuff like the following. We should also
> > be checking the messages for exceptions and make sure they make sense and
> > can help users fix isses if the exceptions are aimed at the library
> users.
> > try
> > {
> > d = DateTools.StringToDate("97"); // no date
> >  Assert.Fail();
> > }
> > catch (System.FormatException e)
> >  {
> > /* expected exception */
> > }
> >
> > On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire <[EMAIL PROTECTED]
> >wrote:
> >
> >> So, veering towards action - are there concrete tasks written up
> anywhere
> >> for the unit tests? If a poor schlep like me wanted to dig in and start
> to
> >> improve them, where would I get the understanding of what is good and
> what
> >> needs help?
> >>
> >> -r
> >>
> >> On Thu, Jun 30, 2011 at 3:29 PM, Digy <[EMAIL PROTECTED]> wrote:
> >>
> >> > I can not say I like this approach, but till we find an automated
> >> way(with
> >> > good results), it seems to be the only way we can use.
> >> >
> >> > DIGY
> >> >
> >> > -----Original Message-----
> >> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> >> > Sent: Friday, July 01, 2011 12:43 AM

I think whatever makes sense to do.

possibly create one jira for now with a running list that can be modified
and possibly as people pull from that list, cross things off or create a
separate ticket that links back to to the main one.
On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:

> @Michael -
>
> Should that list be in JIRA? It would be easier to manage, I think...
>
> If yes, I'll happily do it.
>
> -r
>
> On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon <
> [EMAIL PROTECTED]
> > wrote:
>
> > * need to document what the build script does.  whut grammerz?
> >
> > On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
> > [EMAIL PROTECTED]> wrote:
> >
> > > @Rory, @All,
> > >
> > > The only tickets I currently have for those is LUCENE-419, LUCENE-418
> > >
> > > 418, I should be able to push into the 2.9.4g branch tonight.    419 is
> a
> > > long term goal and not as important as getting the tests fixed, of have
> > the
> > > tests broken down into what is actually a unit test, functional test,
> > perf
> > > or long running test. I can get into more why it needs to be done.
> > >
> > > I'll also need to make document the what build script currently does on
> > the
> > > wiki & and make a few notes about testing, like using the RAMDirectory,
> > > etc.
> > >
> > > Things that need to get done or even be discussed.
> > >  * There needs to be a running list of things to do/not to do with
> > testing.
> > > I don't know if this goes in a jira or do we keep a running list on the
> > wiki
> > > or site for people to pick up and  help with.
> > >  * Tests need to run on mono and not Fail (there is a good deal of
> > failing
> > > tests on mono, mostly due to the temp directory have the C:\ in the
> > path).
> > >  * Assert.Throw<ExceptionType>() needs to be used instead of Try/Catch
> > > Assert.Fail.  **
> > >  * File & Path combines to the temp directory need helper methods,
> > >      * e,g, having this in a hundred places is bad   new
> > >
> >
> System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> > > ""), "testIndex"));
> > >  * We should still be testing deprecated methods, but we need to use
> > #pragma
> > > warning disable/enable 0618  for testing those. otherwise compiler
> > warnings
> > > are too numerous to be anywhere near helpful.
> > >  * We should only be using deprecated methods in places where they are
> > > being explicitly tested, other tests that need that functionality in
> > order
> > > to validate those tests should be re factored to use methods that are
> not
> > > deprecated.
> > >  * Identify code that could be abstracted into test utility classes.
> > >  * Infrastructure Validation tests need to be made, anything that seems
> > > like infrastructure.  e.g. does the temp directory exist, does the
> > folders
> > > that the tests use inside the temp directory exist, can we read/write
> to
> > > those folders. (if a ton of tests fail due to the file system, we
> should
> > be
> > > able to point out that it was due to permissions or missing folders,
> > files,
> > > etc).
> > >  * Identify what classes need an interface, abstract class or inherited
> > in
> > > order to create testing mocks. (once those classes are created, they
> > should
> > > be documented in the wiki).
> > >
> > >
> > >
> > > ** Asset.Throws needs to replace stuff like the following. We should
> also
> > > be checking the messages for exceptions and make sure they make sense
> and
> > > can help users fix isses if the exceptions are aimed at the library
> > users.
> > > try
> > > {
> > > d = DateTools.StringToDate("97"); // no date
> > >  Assert.Fail();
> > > }
> > > catch (System.FormatException e)
> > >  {
> > > /* expected exception */
> > > }
> > >
> > > On Thu, Jun 30, 2011 at 11:48 PM, Rory Plaire <[EMAIL PROTECTED]
> > >wrote:
> > >
> > >> So, veering towards action - are there concrete tasks written up
> > anywhere
> > >> for the unit tests? If a poor schlep like me wanted to dig in and

JIRA can to tasks/subtasks/etc.. So you could take the big list, make it a
task like "Unit Tests Need to be Refactored"... Then for the smaller bits,
make those sub tasks...

See LUCENENET-379 for an example

https://issues.apache.org/jira/browse/LUCENENET-379

Thanks,
Troy
On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon <
[EMAIL PROTECTED]> wrote:

> I think whatever makes sense to do.
>
> possibly create one jira for now with a running list that can be modified
> and possibly as people pull from that list, cross things off or create a
> separate ticket that links back to to the main one.
>
>
>
>
> On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:
>
> > @Michael -
> >
> > Should that list be in JIRA? It would be easier to manage, I think...
> >
> > If yes, I'll happily do it.
> >
> > -r
> >
> > On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon <
> > [EMAIL PROTECTED]
> > > wrote:
> >
> > > * need to document what the build script does.  whut grammerz?
> > >
> > > On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > @Rory, @All,
> > > >
> > > > The only tickets I currently have for those is LUCENE-419, LUCENE-418
> > > >
> > > > 418, I should be able to push into the 2.9.4g branch tonight.    419
> is
> > a
> > > > long term goal and not as important as getting the tests fixed, of
> have
> > > the
> > > > tests broken down into what is actually a unit test, functional test,
> > > perf
> > > > or long running test. I can get into more why it needs to be done.
> > > >
> > > > I'll also need to make document the what build script currently does
> on
> > > the
> > > > wiki & and make a few notes about testing, like using the
> RAMDirectory,
> > > > etc.
> > > >
> > > > Things that need to get done or even be discussed.
> > > >  * There needs to be a running list of things to do/not to do with
> > > testing.
> > > > I don't know if this goes in a jira or do we keep a running list on
> the
> > > wiki
> > > > or site for people to pick up and  help with.
> > > >  * Tests need to run on mono and not Fail (there is a good deal of
> > > failing
> > > > tests on mono, mostly due to the temp directory have the C:\ in the
> > > path).
> > > >  * Assert.Throw<ExceptionType>() needs to be used instead of
> Try/Catch
> > > > Assert.Fail.  **
> > > >  * File & Path combines to the temp directory need helper methods,
> > > >      * e,g, having this in a hundred places is bad   new
> > > >
> > >
> >
> System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> > > > ""), "testIndex"));
> > > >  * We should still be testing deprecated methods, but we need to use
> > > #pragma
> > > > warning disable/enable 0618  for testing those. otherwise compiler
> > > warnings
> > > > are too numerous to be anywhere near helpful.
> > > >  * We should only be using deprecated methods in places where they
> are
> > > > being explicitly tested, other tests that need that functionality in
> > > order
> > > > to validate those tests should be re factored to use methods that are
> > not
> > > > deprecated.
> > > >  * Identify code that could be abstracted into test utility classes.
> > > >  * Infrastructure Validation tests need to be made, anything that
> seems
> > > > like infrastructure.  e.g. does the temp directory exist, does the
> > > folders
> > > > that the tests use inside the temp directory exist, can we read/write
> > to
> > > > those folders. (if a ton of tests fail due to the file system, we
> > should
> > > be
> > > > able to point out that it was due to permissions or missing folders,
> > > files,
> > > > etc).
> > > >  * Identify what classes need an interface, abstract class or
> inherited
> > > in
> > > > order to create testing mocks. (once those classes are created, they
> > > should
> > > > be documented in the wiki).
> > > >
> > > >
> > > >
> > > > ** Asset.Throws needs to replace stuff like the following. We should
> > also
> > > > be checking the messages for exceptions and make sure they make sense

My thinking is just a separate ticket for each one. This makes the work
easier to manage and gives a better sense about how much work is left as
well as makes it easier to prioritize independent issues. We could link all
the sub-issues to a single task / feature / whatever (that is, if JIRA has
that capability).

-r
On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon <
[EMAIL PROTECTED]> wrote:

> I think whatever makes sense to do.
>
> possibly create one jira for now with a running list that can be modified
> and possibly as people pull from that list, cross things off or create a
> separate ticket that links back to to the main one.
>
>
>
>
> On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:
>
> > @Michael -
> >
> > Should that list be in JIRA? It would be easier to manage, I think...
> >
> > If yes, I'll happily do it.
> >
> > -r
> >
> > On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon <
> > [EMAIL PROTECTED]
> > > wrote:
> >
> > > * need to document what the build script does.  whut grammerz?
> > >
> > > On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > @Rory, @All,
> > > >
> > > > The only tickets I currently have for those is LUCENE-419, LUCENE-418
> > > >
> > > > 418, I should be able to push into the 2.9.4g branch tonight.    419
> is
> > a
> > > > long term goal and not as important as getting the tests fixed, of
> have
> > > the
> > > > tests broken down into what is actually a unit test, functional test,
> > > perf
> > > > or long running test. I can get into more why it needs to be done.
> > > >
> > > > I'll also need to make document the what build script currently does
> on
> > > the
> > > > wiki & and make a few notes about testing, like using the
> RAMDirectory,
> > > > etc.
> > > >
> > > > Things that need to get done or even be discussed.
> > > >  * There needs to be a running list of things to do/not to do with
> > > testing.
> > > > I don't know if this goes in a jira or do we keep a running list on
> the
> > > wiki
> > > > or site for people to pick up and  help with.
> > > >  * Tests need to run on mono and not Fail (there is a good deal of
> > > failing
> > > > tests on mono, mostly due to the temp directory have the C:\ in the
> > > path).
> > > >  * Assert.Throw<ExceptionType>() needs to be used instead of
> Try/Catch
> > > > Assert.Fail.  **
> > > >  * File & Path combines to the temp directory need helper methods,
> > > >      * e,g, having this in a hundred places is bad   new
> > > >
> > >
> >
> System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> > > > ""), "testIndex"));
> > > >  * We should still be testing deprecated methods, but we need to use
> > > #pragma
> > > > warning disable/enable 0618  for testing those. otherwise compiler
> > > warnings
> > > > are too numerous to be anywhere near helpful.
> > > >  * We should only be using deprecated methods in places where they
> are
> > > > being explicitly tested, other tests that need that functionality in
> > > order
> > > > to validate those tests should be re factored to use methods that are
> > not
> > > > deprecated.
> > > >  * Identify code that could be abstracted into test utility classes.
> > > >  * Infrastructure Validation tests need to be made, anything that
> seems
> > > > like infrastructure.  e.g. does the temp directory exist, does the
> > > folders
> > > > that the tests use inside the temp directory exist, can we read/write
> > to
> > > > those folders. (if a ton of tests fail due to the file system, we
> > should
> > > be
> > > > able to point out that it was due to permissions or missing folders,
> > > files,
> > > > etc).
> > > >  * Identify what classes need an interface, abstract class or
> inherited
> > > in
> > > > order to create testing mocks. (once those classes are created, they
> > > should
> > > > be documented in the wiki).
> > > >
> > > >
> > > >
> > > > ** Asset.Throws needs to replace stuff like the following. We should

I will take a look at the different items and see where I can best apply my
skills.  

Scott
> -----Original Message-----
> From: Digy [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 6:13 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> > Ok I think I asked the wrong question
> Yes, you started the flame war :)
>
> * What I realy hate in code is the AnonymousXXXX classes inhereted from
> JLCA
> which make the code impossible to read.
> I changed a few in 2.9.4g with replacing the single abstract method with
> Func<> or Action<>
>
> like in FilterCache<T>
> from:
> protected abstract object MergeDeletes(IndexReader reader, object value);
> to:
> Func<IndexReader, object, object> MergeDeletes;
>
> but there are zillions of those with more than 1 abstract method. I still
> think of how to replace them with something suitable without diverging
> much
> from Java.
>
>
> * I am also not satisfied with return parameters like ICollection<>,
> IList<>, IEnumerator<> etc.
> These should be standardized some way.
>
>
> * Support.Set<T> & Support.Dictionary<K, V> classes are just fast
> solutions
> to the problem
> "java's collections return null when an item does not exist in the
> collection whereas .NET throws exception". A better way may be used.
>
> * missing IEquatable<T>'s
>
> * making Iterators as real .NET Enumerators
>
> etc. etc. etc.
>
>
> It seems to be a never ending story.
>
>
> DIGY
>
>
>
>
> -----Original Message-----
> From: Scott Lombard [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 01, 2011 12:13 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Ok I think I asked the wrong question.  I am trying to figure out where to
> put my time.  I was thinking about working on the automated porting
> system,
> but when I saw the response to the .NET 4.0 discussions I started to
> question if that is the right direction.  The community seemed to be more
> interested in the .NET features.
>
> The complexity of the automated tool is going to become very high and will
> probably end up with a line-for-line style port.  So I keep asking my self
> is the automated tool worth it.  I don't think it is.
>
> I like the method has been Digy is using for porting the code.  So I guess
> for me the real question is Digy where did you see 2.9.4g going next and
> what do you need help on?
>
> Scott
>
>
>
>
> > -----Original Message-----
> > From: Digy [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 30, 2011 4:20 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > Michael,
> > You interpret the report as "whoever commits code wins"? But when I look
> > at it, I see "a lof of talk, no work". .Net community is not interested
> in
> > contributing.
> > I really don't understand what hinders people to work on Lucene.Net. As
> I
> > did for 2.9.4g, grab the code, do whatever you want on it and submit
> back.
> > If it doesn't fit to the project's direction it can still find a place
> in
> > contrib or in branch. All of the approaches can live side by side
> happily
> > in the Lucene.Net repository.
> >
> > Troy,
> > I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> > has nothing to do with the trunk. It need not be an offical release and
> > can live in branch as a PoC.
> >
> >
> > As a result, I got bored to listen to "this should be done that way".
> What
> > I want to see is "I did it that way, should we continue with this".
> >
> > DIGY
> >
> >
> >
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 30, 2011 10:47 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > Michael,
> >
> > I agree with everything you said. My point in saying "whoever commits

@Rory,

Jira in the past had the ability to create sub tasks or convert a current
task to a sub task. I'm guessing that apache's jira should be able to do
that.

@All,

I've add a Paths Class under the Lucene.Net.Tests Util folder (feel free to
rename, refactor as long as the tests still work) to help with working with
paths in general.  This should help with forming paths relative to the temp
directory or the project root.

NUnit's Shadow Copy tends to throw people off when trying to get the path of
the current assembly being tested to build up a relative path, the Path
class should help with that.

- Michael

On Fri, Jul 1, 2011 at 4:09 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:

> My thinking is just a separate ticket for each one. This makes the work
> easier to manage and gives a better sense about how much work is left as
> well as makes it easier to prioritize independent issues. We could link all
> the sub-issues to a single task / feature / whatever (that is, if JIRA has
> that capability).
>
> -r
> On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon <
> [EMAIL PROTECTED]> wrote:
>
> > I think whatever makes sense to do.
> >
> > possibly create one jira for now with a running list that can be modified
> > and possibly as people pull from that list, cross things off or create a
> > separate ticket that links back to to the main one.
> >
> >
> >
> >
> > On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire <[EMAIL PROTECTED]>
> wrote:
> >
> > > @Michael -
> > >
> > > Should that list be in JIRA? It would be easier to manage, I think...
> > >
> > > If yes, I'll happily do it.
> > >
> > > -r
> > >
> > > On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon <
> > > [EMAIL PROTECTED]
> > > > wrote:
> > >
> > > > * need to document what the build script does.  whut grammerz?
> > > >
> > > > On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
> > > > [EMAIL PROTECTED]> wrote:
> > > >
> > > > > @Rory, @All,
> > > > >
> > > > > The only tickets I currently have for those is LUCENE-419,
> LUCENE-418
> > > > >
> > > > > 418, I should be able to push into the 2.9.4g branch tonight.
>  419
> > is
> > > a
> > > > > long term goal and not as important as getting the tests fixed, of
> > have
> > > > the
> > > > > tests broken down into what is actually a unit test, functional
> test,
> > > > perf
> > > > > or long running test. I can get into more why it needs to be done.
> > > > >
> > > > > I'll also need to make document the what build script currently
> does
> > on
> > > > the
> > > > > wiki & and make a few notes about testing, like using the
> > RAMDirectory,
> > > > > etc.
> > > > >
> > > > > Things that need to get done or even be discussed.
> > > > >  * There needs to be a running list of things to do/not to do with
> > > > testing.
> > > > > I don't know if this goes in a jira or do we keep a running list on
> > the
> > > > wiki
> > > > > or site for people to pick up and  help with.
> > > > >  * Tests need to run on mono and not Fail (there is a good deal of
> > > > failing
> > > > > tests on mono, mostly due to the temp directory have the C:\ in the
> > > > path).
> > > > >  * Assert.Throw<ExceptionType>() needs to be used instead of
> > Try/Catch
> > > > > Assert.Fail.  **
> > > > >  * File & Path combines to the temp directory need helper methods,
> > > > >      * e,g, having this in a hundred places is bad   new
> > > > >
> > > >
> > >
> >
> System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> > > > > ""), "testIndex"));
> > > > >  * We should still be testing deprecated methods, but we need to
> use
> > > > #pragma
> > > > > warning disable/enable 0618  for testing those. otherwise compiler
> > > > warnings
> > > > > are too numerous to be anywhere near helpful.
> > > > >  * We should only be using deprecated methods in places where they
> > are
> > > > > being explicitly tested, other tests that need that functionality
> in
> > > > order
> > > > > to validate those tests should be re factored to use methods that

> I've add a Paths Class under the Lucene.Net.Tests Util folder
Since it is a Lucene.Net specific code, may "Support" be a better place?
DIGY

-----Original Message-----
From: Michael Herndon [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 01, 2011 11:53 PM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

@Rory,

Jira in the past had the ability to create sub tasks or convert a current
task to a sub task. I'm guessing that apache's jira should be able to do
that.

@All,

I've add a Paths Class under the Lucene.Net.Tests Util folder (feel free to
rename, refactor as long as the tests still work) to help with working with
paths in general.  This should help with forming paths relative to the temp
directory or the project root.

NUnit's Shadow Copy tends to throw people off when trying to get the path of
the current assembly being tested to build up a relative path, the Path
class should help with that.

- Michael

On Fri, Jul 1, 2011 at 4:09 PM, Rory Plaire <[EMAIL PROTECTED]> wrote:

> My thinking is just a separate ticket for each one. This makes the work
> easier to manage and gives a better sense about how much work is left as
> well as makes it easier to prioritize independent issues. We could link
all
> the sub-issues to a single task / feature / whatever (that is, if JIRA has
> that capability).
>
> -r
> On Fri, Jul 1, 2011 at 12:48 PM, Michael Herndon <
> [EMAIL PROTECTED]> wrote:
>
> > I think whatever makes sense to do.
> >
> > possibly create one jira for now with a running list that can be
modified
> > and possibly as people pull from that list, cross things off or create a
> > separate ticket that links back to to the main one.
> >
> >
> >
> >
> > On Fri, Jul 1, 2011 at 3:35 PM, Rory Plaire <[EMAIL PROTECTED]>
> wrote:
> >
> > > @Michael -
> > >
> > > Should that list be in JIRA? It would be easier to manage, I think...
> > >
> > > If yes, I'll happily do it.
> > >
> > > -r
> > >
> > > On Fri, Jul 1, 2011 at 8:04 AM, Michael Herndon <
> > > [EMAIL PROTECTED]
> > > > wrote:
> > >
> > > > * need to document what the build script does.  whut grammerz?
> > > >
> > > > On Fri, Jul 1, 2011 at 10:52 AM, Michael Herndon <
> > > > [EMAIL PROTECTED]> wrote:
> > > >
> > > > > @Rory, @All,
> > > > >
> > > > > The only tickets I currently have for those is LUCENE-419,
> LUCENE-418
> > > > >
> > > > > 418, I should be able to push into the 2.9.4g branch tonight.
>  419
> > is
> > > a
> > > > > long term goal and not as important as getting the tests fixed, of
> > have
> > > > the
> > > > > tests broken down into what is actually a unit test, functional
> test,
> > > > perf
> > > > > or long running test. I can get into more why it needs to be done.
> > > > >
> > > > > I'll also need to make document the what build script currently
> does
> > on
> > > > the
> > > > > wiki & and make a few notes about testing, like using the
> > RAMDirectory,
> > > > > etc.
> > > > >
> > > > > Things that need to get done or even be discussed.
> > > > >  * There needs to be a running list of things to do/not to do with
> > > > testing.
> > > > > I don't know if this goes in a jira or do we keep a running list
on
> > the
> > > > wiki
> > > > > or site for people to pick up and  help with.
> > > > >  * Tests need to run on mono and not Fail (there is a good deal of
> > > > failing
> > > > > tests on mono, mostly due to the temp directory have the C:\ in
the
> > > > path).
> > > > >  * Assert.Throw<ExceptionType>() needs to be used instead of
> > Try/Catch
> > > > > Assert.Fail.  **
> > > > >  * File & Path combines to the temp directory need helper methods,
> > > > >      * e,g, having this in a hundred places is bad   new
> > > > >
> > > >
> > >
> >
>
System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
> > > > > ""), "testIndex"));
> > > > >  * We should still be testing deprecated methods, but we need to
> use
> > > > #pragma
library
port
productive,
seemed
code.
But
not
by
with
code
unit
it
patches,
for
digging
and
of
be
Line-by-Line
come
you
Line-by-Line
use,

Troy,

What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has
* bux fixes like LUCENENET-414
* new features  like LUCENENET-429, MemoryMappedDirectory(although not used yet) ,  PartiallyTrustedAppDomain tests
* improvements like LUCENENET-427, LUCENENET-418,  Refactoring of SupportClass
* API changes like
  - StopAnalyzer(List<string> stopWords)
  - Query.ExtractTerms(ICollection<string>)
  - TopDocs.TotalHits, TopDocs.ScoreDocs
* readibily-changes like replacing some abstract methods with Func<>, while(XXX.MoveNext())s with foreachs
etc.

Is it something like creating a 2.9.4 tag and replacing trunk with 2.9.4g?

DIGY

-----Original Message-----
From: Troy Howard [mailto:[EMAIL PROTECTED]]
Sent: Friday, July 01, 2011 12:36 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

DIGY - Re: Why do I wait.. That's mostly because I intend to make some deep
changes, which would make merging the 2.9.4g branch back to trunk difficult.
So, it's easier to merge those changes first. Also, I won't have enough time
to make my changes until a little way in the future, but probably do have
the time to put together another release, so I'll do that first because it
fits with my work/life schedule.

Thanks,
Troy
On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:

> Michael,
> You interpret the report as "whoever commits code wins"? But when I look at
> it, I see "a lof of talk, no work". .Net community is not interested in
> contributing.
> I really don't understand what hinders people to work on Lucene.Net. As I
> did for 2.9.4g, grab the code, do whatever you want on it and submit back.
> If it doesn't fit to the project's direction it can still find a place in
> contrib or in branch. All of the approaches can live side by side happily in
> the Lucene.Net repository.
>
> Troy,
> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> has nothing to do with the trunk. It need not be an offical release and can
> live in branch as a PoC.
>
>
> As a result, I got bored to listen to "this should be done that way". What
> I want to see is "I did it that way, should we continue with this".
>
> DIGY
>
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 30, 2011 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Michael,
>
> I agree with everything you said. My point in saying "whoever commits code
> wins" was to illustrate the reality of how and why the project has the
> current form.
>
> Building consensus is difficult. It is an essential first step before we
> can
> do something like make a list of bit-sized pieces of work that others can
> work on.
>
> This is why my real message of "Let's find a way to accommodate both" is so
> important. It allows us to build consensus, so that we can settle on a
> direction and structure our work.
>
> Until we accomplish that, it really is "whoever commits code wins", and
> that
> is an unhealthy and unmaintainable way to operate.
>
> From a technical perspective, your statements about the unit tests are
> completely accurate. They really need a LOT of reworking. That's the very
> first step before making any significant changes. Part of the problem is
> that the tests themselves are not well written. The other part is that the
> Lucene object model was not designed for testability, and it makes writing
> good tests more difficult, and certain tests might not be possible. It will
> be difficult to write good unit tests without re-structuring. The biggest
> issue is the use of abstract classes with base behaviour vs interfaces or
> fully abstracted classes. Makes mocking tough. This is the direction I was
> going when I started the Lucere project. I'd like to start in on that work
> after the 2.9.4g release.
>
> Thanks,
> Troy
>
>
> On Thu, Jun 30, 2011 at 12:04 PM, Michael Herndon <

Yes. But if there are commits to trunk before that happens it's a merge.

-T
On Jul 2, 2011 1:53 PM, "Digy" <[EMAIL PROTECTED]> wrote:
> Troy,
>
> What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has
> * bux fixes like LUCENENET-414
> * new features like LUCENENET-429, MemoryMappedDirectory(although not used
yet) , PartiallyTrustedAppDomain tests
> * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
SupportClass
> * API changes like
> - StopAnalyzer(List<string> stopWords)
> - Query.ExtractTerms(ICollection<string>)
> - TopDocs.TotalHits, TopDocs.ScoreDocs
> * readibily-changes like replacing some abstract methods with Func<>,
while(XXX.MoveNext())s with foreachs
> etc.
>
> Is it something like creating a 2.9.4 tag and replacing trunk with 2.9.4g?
>
> DIGY
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 01, 2011 12:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> DIGY - Re: Why do I wait.. That's mostly because I intend to make some
deep
> changes, which would make merging the 2.9.4g branch back to trunk
difficult.
> So, it's easier to merge those changes first. Also, I won't have enough
time
> to make my changes until a little way in the future, but probably do have
> the time to put together another release, so I'll do that first because it
> fits with my work/life schedule.
>
> Thanks,
> Troy
>
>
> On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:
>
>> Michael,
>> You interpret the report as "whoever commits code wins"? But when I look
at
>> it, I see "a lof of talk, no work". .Net community is not interested in
>> contributing.
>> I really don't understand what hinders people to work on Lucene.Net. As I
>> did for 2.9.4g, grab the code, do whatever you want on it and submit
back.
>> If it doesn't fit to the project's direction it can still find a place in
>> contrib or in branch. All of the approaches can live side by side happily
in
>> the Lucene.Net repository.
>>
>> Troy,
>> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
>> has nothing to do with the trunk. It need not be an offical release and
can
>> live in branch as a PoC.
>>
>>
>> As a result, I got bored to listen to "this should be done that way".
What
>> I want to see is "I did it that way, should we continue with this".
>>
>> DIGY
>>
>>
>>
>>
>> -----Original Message-----
>> From: Troy Howard [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, June 30, 2011 10:47 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>>
>> Michael,
>>
>> I agree with everything you said. My point in saying "whoever commits
code
>> wins" was to illustrate the reality of how and why the project has the
>> current form.
>>
>> Building consensus is difficult. It is an essential first step before we
>> can
>> do something like make a list of bit-sized pieces of work that others can
>> work on.
>>
>> This is why my real message of "Let's find a way to accommodate both" is
so
>> important. It allows us to build consensus, so that we can settle on a
>> direction and structure our work.
>>
>> Until we accomplish that, it really is "whoever commits code wins", and
>> that
>> is an unhealthy and unmaintainable way to operate.
>>
>> From a technical perspective, your statements about the unit tests are
>> completely accurate. They really need a LOT of reworking. That's the very
>> first step before making any significant changes. Part of the problem is
>> that the tests themselves are not well written. The other part is that
the
>> Lucene object model was not designed for testability, and it makes
writing
>> good tests more difficult, and certain tests might not be possible. It
will
>> be difficult to write good unit tests without re-structuring. The biggest
>> issue is the use of abstract classes with base behaviour vs interfaces or
>was
work
not
consensus
nixing
instead
most
going
about
avoid
https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|lin&versionId=-1&issue
Status=all&selectedProjectId=12310290&reportKey=com.sourcelabs.jira.plugin.r
people
loose
be
it
work,
and
Lucene.NET
all?
on.
same
needed?
wait
privileged.

OK. Maybe I asked wrong question, Suppose I committed IsolatedStorageDirectory only to trunk. How would you merge this branch & trunk?

DIGY.

-----Original Message-----
From: Troy Howard [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 03, 2011 12:28 AM
To: [EMAIL PROTECTED]
Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

Yes. But if there are commits to trunk before that happens it's a merge.

-T
On Jul 2, 2011 1:53 PM, "Digy" <[EMAIL PROTECTED]> wrote:
> Troy,
>
> What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has
> * bux fixes like LUCENENET-414
> * new features like LUCENENET-429, MemoryMappedDirectory(although not used
yet) , PartiallyTrustedAppDomain tests
> * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
SupportClass
> * API changes like
> - StopAnalyzer(List<string> stopWords)
> - Query.ExtractTerms(ICollection<string>)
> - TopDocs.TotalHits, TopDocs.ScoreDocs
> * readibily-changes like replacing some abstract methods with Func<>,
while(XXX.MoveNext())s with foreachs
> etc.
>
> Is it something like creating a 2.9.4 tag and replacing trunk with 2.9.4g?
>
> DIGY
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 01, 2011 12:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> DIGY - Re: Why do I wait.. That's mostly because I intend to make some
deep
> changes, which would make merging the 2.9.4g branch back to trunk
difficult.
> So, it's easier to merge those changes first. Also, I won't have enough
time
> to make my changes until a little way in the future, but probably do have
> the time to put together another release, so I'll do that first because it
> fits with my work/life schedule.
>
> Thanks,
> Troy
>
>
> On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:
>
>> Michael,
>> You interpret the report as "whoever commits code wins"? But when I look
at
>> it, I see "a lof of talk, no work". .Net community is not interested in
>> contributing.
>> I really don't understand what hinders people to work on Lucene.Net. As I
>> did for 2.9.4g, grab the code, do whatever you want on it and submit
back.
>> If it doesn't fit to the project's direction it can still find a place in
>> contrib or in branch. All of the approaches can live side by side happily
in
>> the Lucene.Net repository.
>>
>> Troy,
>> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
>> has nothing to do with the trunk. It need not be an offical release and
can
>> live in branch as a PoC.
>>
>>
>> As a result, I got bored to listen to "this should be done that way".
What
>> I want to see is "I did it that way, should we continue with this".
>>
>> DIGY
>>
>>
>>
>>
>> -----Original Message-----
>> From: Troy Howard [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, June 30, 2011 10:47 PM
>> To: [EMAIL PROTECTED]
>> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>>
>> Michael,
>>
>> I agree with everything you said. My point in saying "whoever commits
code
>> wins" was to illustrate the reality of how and why the project has the
>> current form.
>>
>> Building consensus is difficult. It is an essential first step before we
>> can
>> do something like make a list of bit-sized pieces of work that others can
>> work on.
>>
>> This is why my real message of "Let's find a way to accommodate both" is
so
>> important. It allows us to build consensus, so that we can settle on a
>> direction and structure our work.
>>
>> Until we accomplish that, it really is "whoever commits code wins", and
>> that
>> is an unhealthy and unmaintainable way to operate.
>>
>> From a technical perspective, your statements about the unit tests are
>> completely accurate. They really need a LOT of reworking. That's the very
>> first step before making any significant changes. Part of the problem is
>> that the tests themselves are not well written. The other part is that
the
writing
will
was
work
not
consensus
nixing
instead
most
going
about
avoid
https://issues.apache.org/jira/secure/ConfigureReport.jspa?atl_token=A5KQ-2Q
AV-T4JA-FDED|3204f7e696067a386144705075c074e991db2a2b|lin&versionId=-1&issue
Status=all&selectedProjectId=12310290&reportKey=com.sourcelabs.jira.plugin.r
people
loose
be
it
work,
and
Lucene.NET
all?
on.
same
needed?
wait
privileged.

I'm not sure that I see a conflict. Are you referring to the use of generic
Dictionary in IndexInput in 2.9.4g? That's the only point where I could see
a possible problem, but generic dictionaries are supported on WP7, so it
should be fine.

In which case, the two should merge and compile correctly.

Thanks,
Troy
On Sat, Jul 2, 2011 at 2:36 PM, Digy <[EMAIL PROTECTED]> wrote:

> OK. Maybe I asked wrong question, Suppose I committed
> IsolatedStorageDirectory only to trunk. How would you merge this branch &
> trunk?
>
> DIGY.
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, July 03, 2011 12:28 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Yes. But if there are commits to trunk before that happens it's a merge.
>
> -T
> On Jul 2, 2011 1:53 PM, "Digy" <[EMAIL PROTECTED]> wrote:
> > Troy,
> >
> > What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has
> > * bux fixes like LUCENENET-414
> > * new features like LUCENENET-429, MemoryMappedDirectory(although not
> used
> yet) , PartiallyTrustedAppDomain tests
> > * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
> SupportClass
> > * API changes like
> > - StopAnalyzer(List<string> stopWords)
> > - Query.ExtractTerms(ICollection<string>)
> > - TopDocs.TotalHits, TopDocs.ScoreDocs
> > * readibily-changes like replacing some abstract methods with Func<>,
> while(XXX.MoveNext())s with foreachs
> > etc.
> >
> > Is it something like creating a 2.9.4 tag and replacing trunk with
> 2.9.4g?
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, July 01, 2011 12:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > DIGY - Re: Why do I wait.. That's mostly because I intend to make some
> deep
> > changes, which would make merging the 2.9.4g branch back to trunk
> difficult.
> > So, it's easier to merge those changes first. Also, I won't have enough
> time
> > to make my changes until a little way in the future, but probably do have
> > the time to put together another release, so I'll do that first because
> it
> > fits with my work/life schedule.
> >
> > Thanks,
> > Troy
> >
> >
> > On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:
> >
> >> Michael,
> >> You interpret the report as "whoever commits code wins"? But when I look
> at
> >> it, I see "a lof of talk, no work". .Net community is not interested in
> >> contributing.
> >> I really don't understand what hinders people to work on Lucene.Net. As
> I
> >> did for 2.9.4g, grab the code, do whatever you want on it and submit
> back.
> >> If it doesn't fit to the project's direction it can still find a place
> in
> >> contrib or in branch. All of the approaches can live side by side
> happily
> in
> >> the Lucene.Net repository.
> >>
> >> Troy,
> >> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> >> has nothing to do with the trunk. It need not be an offical release and
> can
> >> live in branch as a PoC.
> >>
> >>
> >> As a result, I got bored to listen to "this should be done that way".
> What
> >> I want to see is "I did it that way, should we continue with this".
> >>
> >> DIGY
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> >> Sent: Thursday, June 30, 2011 10:47 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >>
> >> Michael,
> >>
> >> I agree with everything you said. My point in saying "whoever commits
> code
> >> wins" was to illustrate the reality of how and why the project has the
> >> current form.
> >>
> >> Building consensus is difficult. It is an essential first step before we
> >> can
> >> do something like make a list of bit-sized pieces of work that others
> can
> >> work on.

No no. It was just an example. As you already know, there are a lot of changes in contrib codes related with those API changes in Lucene.Net.2.9.4g core.
Therefore, I see no option like merging other that copying.

DIGY

-----Original Message-----
From: Troy Howard [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 03, 2011 1:53 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

I'm not sure that I see a conflict. Are you referring to the use of generic
Dictionary in IndexInput in 2.9.4g? That's the only point where I could see
a possible problem, but generic dictionaries are supported on WP7, so it
should be fine.

In which case, the two should merge and compile correctly.

Thanks,
Troy
On Sat, Jul 2, 2011 at 2:36 PM, Digy <[EMAIL PROTECTED]> wrote:

> OK. Maybe I asked wrong question, Suppose I committed
> IsolatedStorageDirectory only to trunk. How would you merge this branch &
> trunk?
>
> DIGY.
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, July 03, 2011 12:28 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Yes. But if there are commits to trunk before that happens it's a merge.
>
> -T
> On Jul 2, 2011 1:53 PM, "Digy" <[EMAIL PROTECTED]> wrote:
> > Troy,
> >
> > What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has
> > * bux fixes like LUCENENET-414
> > * new features like LUCENENET-429, MemoryMappedDirectory(although not
> used
> yet) , PartiallyTrustedAppDomain tests
> > * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
> SupportClass
> > * API changes like
> > - StopAnalyzer(List<string> stopWords)
> > - Query.ExtractTerms(ICollection<string>)
> > - TopDocs.TotalHits, TopDocs.ScoreDocs
> > * readibily-changes like replacing some abstract methods with Func<>,
> while(XXX.MoveNext())s with foreachs
> > etc.
> >
> > Is it something like creating a 2.9.4 tag and replacing trunk with
> 2.9.4g?
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, July 01, 2011 12:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > DIGY - Re: Why do I wait.. That's mostly because I intend to make some
> deep
> > changes, which would make merging the 2.9.4g branch back to trunk
> difficult.
> > So, it's easier to merge those changes first. Also, I won't have enough
> time
> > to make my changes until a little way in the future, but probably do have
> > the time to put together another release, so I'll do that first because
> it
> > fits with my work/life schedule.
> >
> > Thanks,
> > Troy
> >
> >
> > On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:
> >
> >> Michael,
> >> You interpret the report as "whoever commits code wins"? But when I look
> at
> >> it, I see "a lof of talk, no work". .Net community is not interested in
> >> contributing.
> >> I really don't understand what hinders people to work on Lucene.Net. As
> I
> >> did for 2.9.4g, grab the code, do whatever you want on it and submit
> back.
> >> If it doesn't fit to the project's direction it can still find a place
> in
> >> contrib or in branch. All of the approaches can live side by side
> happily
> in
> >> the Lucene.Net repository.
> >>
> >> Troy,
> >> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> >> has nothing to do with the trunk. It need not be an offical release and
> can
> >> live in branch as a PoC.
> >>
> >>
> >> As a result, I got bored to listen to "this should be done that way".
> What
> >> I want to see is "I did it that way, should we continue with this".
> >>
> >> DIGY
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> >> Sent: Thursday, June 30, 2011 10:47 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

And just for this hard work I removed the obsolete Similarity.Net.
DIGY

-----Original Message-----
From: Troy Howard [mailto:[EMAIL PROTECTED]]
Sent: Sunday, July 03, 2011 1:53 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?

I'm not sure that I see a conflict. Are you referring to the use of generic
Dictionary in IndexInput in 2.9.4g? That's the only point where I could see
a possible problem, but generic dictionaries are supported on WP7, so it
should be fine.

In which case, the two should merge and compile correctly.

Thanks,
Troy
On Sat, Jul 2, 2011 at 2:36 PM, Digy <[EMAIL PROTECTED]> wrote:

> OK. Maybe I asked wrong question, Suppose I committed
> IsolatedStorageDirectory only to trunk. How would you merge this branch &
> trunk?
>
> DIGY.
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, July 03, 2011 12:28 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> Yes. But if there are commits to trunk before that happens it's a merge.
>
> -T
> On Jul 2, 2011 1:53 PM, "Digy" <[EMAIL PROTECTED]> wrote:
> > Troy,
> >
> > What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has
> > * bux fixes like LUCENENET-414
> > * new features like LUCENENET-429, MemoryMappedDirectory(although not
> used
> yet) , PartiallyTrustedAppDomain tests
> > * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
> SupportClass
> > * API changes like
> > - StopAnalyzer(List<string> stopWords)
> > - Query.ExtractTerms(ICollection<string>)
> > - TopDocs.TotalHits, TopDocs.ScoreDocs
> > * readibily-changes like replacing some abstract methods with Func<>,
> while(XXX.MoveNext())s with foreachs
> > etc.
> >
> > Is it something like creating a 2.9.4 tag and replacing trunk with
> 2.9.4g?
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, July 01, 2011 12:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > DIGY - Re: Why do I wait.. That's mostly because I intend to make some
> deep
> > changes, which would make merging the 2.9.4g branch back to trunk
> difficult.
> > So, it's easier to merge those changes first. Also, I won't have enough
> time
> > to make my changes until a little way in the future, but probably do have
> > the time to put together another release, so I'll do that first because
> it
> > fits with my work/life schedule.
> >
> > Thanks,
> > Troy
> >
> >
> > On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:
> >
> >> Michael,
> >> You interpret the report as "whoever commits code wins"? But when I look
> at
> >> it, I see "a lof of talk, no work". .Net community is not interested in
> >> contributing.
> >> I really don't understand what hinders people to work on Lucene.Net. As
> I
> >> did for 2.9.4g, grab the code, do whatever you want on it and submit
> back.
> >> If it doesn't fit to the project's direction it can still find a place
> in
> >> contrib or in branch. All of the approaches can live side by side
> happily
> in
> >> the Lucene.Net repository.
> >>
> >> Troy,
> >> I also don't understand why do you wait for 2.9.4g? It is a *branch* and
> >> has nothing to do with the trunk. It need not be an offical release and
> can
> >> live in branch as a PoC.
> >>
> >>
> >> As a result, I got bored to listen to "this should be done that way".
> What
> >> I want to see is "I did it that way, should we continue with this".
> >>
> >> DIGY
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> >> Sent: Thursday, June 30, 2011 10:47 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >>
> >> Michael,
> >>
> >> I agree with everything you said. My point in saying "whoever commits

Digy,

Should your 2.9.4g be renamed to 3.0 something and then be released in the
future as a 3.0 release?  The current trunk could be released under the tag
2.9.4.

Scott

> -----Original Message-----
> From: Digy [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, July 02, 2011 7:04 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> No no. It was just an example. As you already know, there are a lot of
> changes in contrib codes related with those API changes in
> Lucene.Net.2.9.4g core.
> Therefore, I see no option like merging other that copying.
>
> DIGY
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, July 03, 2011 1:53 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
>
> I'm not sure that I see a conflict. Are you referring to the use of
> generic
> Dictionary in IndexInput in 2.9.4g? That's the only point where I could
> see
> a possible problem, but generic dictionaries are supported on WP7, so it
> should be fine.
>
> In which case, the two should merge and compile correctly.
>
> Thanks,
> Troy
>
>
> On Sat, Jul 2, 2011 at 2:36 PM, Digy <[EMAIL PROTECTED]> wrote:
>
> > OK. Maybe I asked wrong question, Suppose I committed
> > IsolatedStorageDirectory only to trunk. How would you merge this branch
> &
> > trunk?
> >
> > DIGY.
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, July 03, 2011 12:28 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > Yes. But if there are commits to trunk before that happens it's a merge.
> >
> > -T
> > On Jul 2, 2011 1:53 PM, "Digy" <[EMAIL PROTECTED]> wrote:
> > > Troy,
> > >
> > > What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has
> > > * bux fixes like LUCENENET-414
> > > * new features like LUCENENET-429, MemoryMappedDirectory(although not
> > used
> > yet) , PartiallyTrustedAppDomain tests
> > > * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
> > SupportClass
> > > * API changes like
> > > - StopAnalyzer(List<string> stopWords)
> > > - Query.ExtractTerms(ICollection<string>)
> > > - TopDocs.TotalHits, TopDocs.ScoreDocs
> > > * readibily-changes like replacing some abstract methods with Func<>,
> > while(XXX.MoveNext())s with foreachs
> > > etc.
> > >
> > > Is it something like creating a 2.9.4 tag and replacing trunk with
> > 2.9.4g?
> > >
> > > DIGY
> > >
> > > -----Original Message-----
> > > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, July 01, 2011 12:36 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
> needed?
> > >
> > > DIGY - Re: Why do I wait.. That's mostly because I intend to make some
> > deep
> > > changes, which would make merging the 2.9.4g branch back to trunk
> > difficult.
> > > So, it's easier to merge those changes first. Also, I won't have
> enough
> > time
> > > to make my changes until a little way in the future, but probably do
> have
> > > the time to put together another release, so I'll do that first
> because
> > it
> > > fits with my work/life schedule.
> > >
> > > Thanks,
> > > Troy
> > >
> > >
> > > On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:
> > >
> > >> Michael,
> > >> You interpret the report as "whoever commits code wins"? But when I
> look
> > at
> > >> it, I see "a lof of talk, no work". .Net community is not interested
> in
> > >> contributing.
> > >> I really don't understand what hinders people to work on Lucene.Net.
> As
> > I
> > >> did for 2.9.4g, grab the code, do whatever you want on it and submit
> > back.
> > >> If it doesn't fit to the project's direction it can still find a
> place
> > in
> > >> contrib or in branch. All of the approaches can live side by side
> > happily
> > in

Yes the real 2.9.4 is in the  trunk. 2.9.4g is currently neither 2.9.4 nor
3.0.3.
But having an intermediate tag/release could also be good before removing
deprecated methods.

DIGY

On Tue, Jul 5, 2011 at 5:19 PM, Scott Lombard <[EMAIL PROTECTED]>wrote:

> Digy,
>
> Should your 2.9.4g be renamed to 3.0 something and then be released in the
> future as a 3.0 release?  The current trunk could be released under the tag
> 2.9.4.
>
> Scott
>
> > -----Original Message-----
> > From: Digy [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, July 02, 2011 7:04 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > No no. It was just an example. As you already know, there are a lot of
> > changes in contrib codes related with those API changes in
> > Lucene.Net.2.9.4g core.
> > Therefore, I see no option like merging other that copying.
> >
> > DIGY
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, July 03, 2011 1:53 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port needed?
> >
> > I'm not sure that I see a conflict. Are you referring to the use of
> > generic
> > Dictionary in IndexInput in 2.9.4g? That's the only point where I could
> > see
> > a possible problem, but generic dictionaries are supported on WP7, so it
> > should be fine.
> >
> > In which case, the two should merge and compile correctly.
> >
> > Thanks,
> > Troy
> >
> >
> > On Sat, Jul 2, 2011 at 2:36 PM, Digy <[EMAIL PROTECTED]> wrote:
> >
> > > OK. Maybe I asked wrong question, Suppose I committed
> > > IsolatedStorageDirectory only to trunk. How would you merge this branch
> > &
> > > trunk?
> > >
> > > DIGY.
> > >
> > > -----Original Message-----
> > > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > > Sent: Sunday, July 03, 2011 12:28 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
> needed?
> > >
> > > Yes. But if there are commits to trunk before that happens it's a
> merge.
> > >
> > > -T
> > > On Jul 2, 2011 1:53 PM, "Digy" <[EMAIL PROTECTED]> wrote:
> > > > Troy,
> > > >
> > > > What do you mean by "merging"? 2.9.4g is a superset of 2.9.4 and has
> > > > * bux fixes like LUCENENET-414
> > > > * new features like LUCENENET-429, MemoryMappedDirectory(although not
> > > used
> > > yet) , PartiallyTrustedAppDomain tests
> > > > * improvements like LUCENENET-427, LUCENENET-418, Refactoring of
> > > SupportClass
> > > > * API changes like
> > > > - StopAnalyzer(List<string> stopWords)
> > > > - Query.ExtractTerms(ICollection<string>)
> > > > - TopDocs.TotalHits, TopDocs.ScoreDocs
> > > > * readibily-changes like replacing some abstract methods with Func<>,
> > > while(XXX.MoveNext())s with foreachs
> > > > etc.
> > > >
> > > > Is it something like creating a 2.9.4 tag and replacing trunk with
> > > 2.9.4g?
> > > >
> > > > DIGY
> > > >
> > > > -----Original Message-----
> > > > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > > > Sent: Friday, July 01, 2011 12:36 AM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: [Lucene.Net] Is a Lucene.Net Line-by-Line Jave port
> > needed?
> > > >
> > > > DIGY - Re: Why do I wait.. That's mostly because I intend to make
> some
> > > deep
> > > > changes, which would make merging the 2.9.4g branch back to trunk
> > > difficult.
> > > > So, it's easier to merge those changes first. Also, I won't have
> > enough
> > > time
> > > > to make my changes until a little way in the future, but probably do
> > have
> > > > the time to put together another release, so I'll do that first
> > because
> > > it
> > > > fits with my work/life schedule.
> > > >
> > > > Thanks,
> > > > Troy
> > > >
> > > >
> > > > On Thu, Jun 30, 2011 at 1:19 PM, Digy <[EMAIL PROTECTED]> wrote:
> > > >
> > > >> Michael,
> > > >> You interpret the report as "whoever commits code wins"? But when I