You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Prescott Nasser <ge...@hotmail.com> on 2011/12/01 09:33:57 UTC
[Lucene.Net] 3.0.3
With 2.9.4 out the door, do we merge 3.0.3 into the trunk? How do we want to handle this?
Re: [Lucene.Net] 3.0.3
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-12-02, Prescott Nasser wrote:
> Troy pointed out the benefits of NOT automating a java port, and if we
> can get up to parity, keep us in line shouldn't be too difficult. If
> we move towards a more .Net version, we are going to lose some of the
> ease of that porting. I'm personally ok with that, knowing that X
> causes a bug shouldn't be too hard to track down even if we refactor -
> it should be trivial to set up a quick test with our version and find
> out if the bug applies - if so, using the Java Lucene fix as guidance
> (was it an off by one error or something) can easily be ported into
> our code base (even if not copied and pasted as a line-by-line would
> allow).
As long as the API doesn't change significantly it may be possible to
keep the unit tests as close to line-by-line ports as possible. This
should give you confidence in any refactoring you've performed and allow
you to port unit tests for Java fixes easily. Of course you may want to
add more tests. Just a thought.
Stefan
RE: [Lucene.Net] 3.0.3
Posted by Prescott Nasser <ge...@hotmail.com>.
Lucene.Net 3.0.3
I've started a wiki page, very rough, to help track the progress of 3.0.3. It also provides a link to the Issues that Lucene (java) 3.0.3 fixed from their previous release.
https://cwiki.apache.org/confluence/display/LUCENENET/Lucene.Net+3.0.3
Roadmap:
I agree we should probably all focus on one release at a time, until it is mostly finished, then move on to the next. Chris you bring up a good point "What does that mean" As for line-by-line port vs .NET version this is how I interpret the terms:
-- line-by-line --
* Classes are mapped identical (where possible), no refactoring
* We keep same types where possible (even if not optimal for .NET)
* We don't refactor or condense code where possible - think linq queries vs various for loops and variable tracking.
-- .Net Version --
* We use generics
* We use .Net code and style conventions
* We refactor everything that makes sense
* Maintain 100% compatibility with Java Lucene index
* It doesn't mean we significantly change the API
Troy pointed out the benefits of NOT automating a java port, and if we can get up to parity, keep us in line shouldn't be too difficult. If we move towards a more .Net version, we are going to lose some of the ease of that porting. I'm personally ok with that, knowing that X causes a bug shouldn't be too hard to track down even if we refactor - it should be trivial to set up a quick test with our version and find out if the bug applies - if so, using the Java Lucene fix as guidance (was it an off by one error or something) can easily be ported into our code base (even if not copied and pasted as a line-by-line would allow).
It's late, hopefully that makes some sense. Please add to it so we can continue to define what this means to us. When we understand what we mean by these terms and can really start to make decisions on where we are going.
----------------------------------------
> Date: Thu, 1 Dec 2011 09:57:37 -0800
> From: currens.chris@gmail.com
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] 3.0.3
>
> There are a few patches that were made for 2.9.4 between when the 3.0.3
> branch was forked from trunk and now that haven't been merged in. It looks
> like I branched it on Nov. 7th, so
> LUCENENET-431, LUCENENET-433, LUCENENET-453, and LUCENENET-455 may or may
> not be fixed, since that also largely depends on what was ported (that code
> may be removed, or changed in the new version).
>
> The Readme.txt, build.cmd line endings, and possibly the licence in
> Contrib.SpellChecker.Test.nunit might need to be added as well. I still
> need to make Jira issues for quite a few things, regarding 3.0.3, since
> right now what is left do to is only stated in a few scattered emails and
> text files in the repository. I was planning on doing that a few days ago,
> but unfortunately life and work have gotten in the way.
>
> So regarding merging 3.0.3 into trunk, I'd probably like to fix those
> first. I'm fine with merging 3.0.3 into trunk, though, I think a lot of it
> is determined by our current AND long term goals. It makes sense to throw
> 3.0.3 into trunk, but we're also already working on 4.0 in another branch.
> On top of that, our board report shows that we still want the existing
> line-by-line port (which the 3.0.3 branch is), as well as a .NET idomatic
> API which is also mentioned in our long term goals as not just an API, but
> a new .NET version.
>
> Now that we're finished with 2.x and we're in between versions, now is a
> good time to talk about prioritizing our work. An important point Stefan
> brought up last week, was that we are all working on x number of branches
> in parallel, instead of all working together to get releases pushed, of
> course we can still have branches but we are all kinda doing our own thing,
> I'm guilty of this as well. We have a lot of goals, but there is seemingly
> no priority for them (I realize current activities seems like a higher
> priority than long term goals, but it just happened that way, and was never
> discussed between all the committers).
>
> What is more important? The line-by-line port or the fully .NET-ified
> version of Lucene? Should we start on the .NET version now? And what is
> meant by .NET version? Is it simply API differences or significant
> internal changes, as well? I'm not sure everyone has the same idea on
> this, but it's *very* important we all do, and each way requires a
> significantly different amount of work to accomplish. Additionally, and
> I'm being very frank about this, our goals of having a line-by-line port
> *and* a .NET version may or may not be possible with the current number of
> committers we have, considering the amount of time everyone has to give to
> the project differs greatly by so many factors (I'm not trying to attack
> anyone, it's just how life works, I wasn't as active as I could have been
> on the project until fairly recently, and I'm having a little less time
> than I had a few weeks ago).
>
> I think it's important we discuss this and make sure everyone is on the
> same page (it's possible we already are, and just haven't officially
> documented it anywhere). Then I think we can move forward as a group in
> the project.
>
>
> Thanks,
> Christopher
>
> On Thu, Dec 1, 2011 at 12:33 AM, Prescott Nasser <ge...@hotmail.com>wrote:
>
> >
> > With 2.9.4 out the door,
do we merge 3.0.3 into the trunk? How do we want
> > to handle this?
Re: [Lucene.Net] 3.0.3
Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-12-01, Christopher Currens wrote:
> There are a few patches that were made for 2.9.4 between when the 3.0.3
> branch was forked from trunk and now that haven't been merged in. It looks
> like I branched it on Nov. 7th, so
> LUCENENET-431, LUCENENET-433, LUCENENET-453, and LUCENENET-455 may or may
> not be fixed, since that also largely depends on what was ported (that code
> may be removed, or changed in the new version).
I can easily check out the branch and provide the equivalent of
LUCENENET-453 for it if that helps.
> Additionally, and I'm being very frank about this, our goals of having
> a line-by-line port *and* a .NET version may or may not be possible
> with the current number of committers we have, considering the amount
> of time everyone has to give to the project differs greatly by so many
> factors
Probably not. Are there additional people who are no committers yet who
want to help?
I realize the two approaches are apealing to different kinds of
developers. The line-by-line approach will give you the power (and
bugs) of the Java version and is pretty easy to maintain once done but
sounds boring. There is not much creativity involved.
My understanding of the docs has been that a line-by-line port would
still be kept but an additional .NET API was provided. I may be totally
off, but that's how I read it.
> I think it's important we discuss this and make sure everyone is on the
> same page (it's possible we already are, and just haven't officially
> documented it anywhere). Then I think we can move forward as a group in
> the project.
+1
Stefan
Re: [Lucene.Net] 3.0.3
Posted by Christopher Currens <cu...@gmail.com>.
There are a few patches that were made for 2.9.4 between when the 3.0.3
branch was forked from trunk and now that haven't been merged in. It looks
like I branched it on Nov. 7th, so
LUCENENET-431, LUCENENET-433, LUCENENET-453, and LUCENENET-455 may or may
not be fixed, since that also largely depends on what was ported (that code
may be removed, or changed in the new version).
The Readme.txt, build.cmd line endings, and possibly the licence in
Contrib.SpellChecker.Test.nunit might need to be added as well. I still
need to make Jira issues for quite a few things, regarding 3.0.3, since
right now what is left do to is only stated in a few scattered emails and
text files in the repository. I was planning on doing that a few days ago,
but unfortunately life and work have gotten in the way.
So regarding merging 3.0.3 into trunk, I'd probably like to fix those
first. I'm fine with merging 3.0.3 into trunk, though, I think a lot of it
is determined by our current AND long term goals. It makes sense to throw
3.0.3 into trunk, but we're also already working on 4.0 in another branch.
On top of that, our board report shows that we still want the existing
line-by-line port (which the 3.0.3 branch is), as well as a .NET idomatic
API which is also mentioned in our long term goals as not just an API, but
a new .NET version.
Now that we're finished with 2.x and we're in between versions, now is a
good time to talk about prioritizing our work. An important point Stefan
brought up last week, was that we are all working on x number of branches
in parallel, instead of all working together to get releases pushed, of
course we can still have branches but we are all kinda doing our own thing,
I'm guilty of this as well. We have a lot of goals, but there is seemingly
no priority for them (I realize current activities seems like a higher
priority than long term goals, but it just happened that way, and was never
discussed between all the committers).
What is more important? The line-by-line port or the fully .NET-ified
version of Lucene? Should we start on the .NET version now? And what is
meant by .NET version? Is it simply API differences or significant
internal changes, as well? I'm not sure everyone has the same idea on
this, but it's *very* important we all do, and each way requires a
significantly different amount of work to accomplish. Additionally, and
I'm being very frank about this, our goals of having a line-by-line port
*and* a .NET version may or may not be possible with the current number of
committers we have, considering the amount of time everyone has to give to
the project differs greatly by so many factors (I'm not trying to attack
anyone, it's just how life works, I wasn't as active as I could have been
on the project until fairly recently, and I'm having a little less time
than I had a few weeks ago).
I think it's important we discuss this and make sure everyone is on the
same page (it's possible we already are, and just haven't officially
documented it anywhere). Then I think we can move forward as a group in
the project.
Thanks,
Christopher
On Thu, Dec 1, 2011 at 12:33 AM, Prescott Nasser <ge...@hotmail.com>wrote:
>
> With 2.9.4 out the door, do we merge 3.0.3 into the trunk? How do we want
> to handle this?