lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Irwin <pir...@feature23.com>
Subject Re: Lucene 4.0
Date Thu, 06 Jun 2013 21:44:20 GMT
Thanks Itamar. I can certainly start work on 4.3 version of the Analysis
namespace.

Not sure the checkout command is what you intended -- you might have meant
trunk instead of master, and that would create a new "3x" branch, when
there's already a "branch_3x" and that would be misnamed... so maybe
checkout -b branch_4x trunk and start there aiming for lucene 4.3.x
compatibility?

Also, does someone with commit rights to the upstream want to create the
necessary Version.cs entries, so that we're not all trying to create them
and dealing with a merge?

Paul


On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko <itamar@code972.com>wrote:

> Unless people here have a specific reason to use 3.6.2 I would highly
> recommed putting all the efforts we can towards v4 otherwise we will never
> make it...
>
> Fork the repo from apache servers or github (same repo, different remotes)
> and checkout -b 3x -t origin/master , that should work
>
>
> On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin <pirwin@feature23.com> wrote:
>
> > Itamar,
> >
> > I agree that from scratch is not the best way to do it, I just thought
> that
> > was the "decision" that was made from the discussion previously for the
> 4.x
> > work. An incremental approach will be much better.
> >
> > I've created a branch of the branch_3x branch on my fork and will begin
> > working on bringing the Analysis namespace up to speed to 3.6.2. If
> anyone
> > wants to pull it or just reuse parts once I'm done, have at it.
> >
> > If I shouldn't have branched off the branch_3x branch, please let me know
> > what I should have branched from (trunk?)
> >
> > Paul
> >
> >
> > On Thu, Jun 6, 2013 at 5:04 PM, Itamar Syn-Hershko <itamar@code972.com
> > >wrote:
> >
> > > Thanks Prescott for bringing this up again :)
> > >
> > > Paul, the problem is no one can really know what it would take until
> they
> > > have deep dived into the work, and even then decisions could and will
> > > change. I will strongly advise against starting from scratch, although
> I
> > do
> > > think a lot in the current structure should change, but its going to be
> > > much easier to change it in place, refactoring where needed, than
> > starting
> > > all over again. Once we kicked this off I personally will be happy with
> > you
> > > taking the analysis part of Lucene and porting it, its pretty much self
> > > contained.
> > > Re 3.6.2 work - you can just do that on a fork and send us PRs, its
> much
> > > more straight forward than the v4 upgrade
> > >
> > > Marcos, porting class by class is the fastest way to do this, we can
> then
> > > concentrate on .NETifying and optimizing using .NET constructs.
> > >
> > > That said, I think the way to go is create a branch out of the current
> > git
> > > master HEAD and label it "3.x", and start working on master towards a
> 4.3
> > > compatible version. The actual port should be using a process that
> > ensures
> > > all Java classes are ported with their tests, and that those tests
> pass -
> > > but I'm against committing any Java code to our repositories. The
> process
> > > should probably be working on classes in some order (alphabetically, or
> > > core classes first) and getting each class to compile before moving
> > > forward. I don't mind about the project not being compilable for a
> month
> > or
> > > two.
> > > Once this is done a process of .NETifying and proofing the code can be
> > > started, at which point we will already have a working v4 version so it
> > > will be easier to keep up with the Java project.
> > >
> > > The first step IMO is to stabilize the test suite so tests could more
> or
> > > less be copied and pasted (e.g. implementing Java-like assertEquals
> > methods
> > > etc; I find xUnit to be much easier to work with than NUnit). I already
> > did
> > > some work there but there's still a lot to do.
> > >
> > > Unfortunately I can't dedicate time myself at this point, but I should
> be
> > > back in business in August, at which point I can dedicate several
> hours a
> > > week. Until then I'll be happy to watch closely and even coordinate the
> > > work to some extent.
> > >
> > >
> > >
> > >
> > > On Thu, Jun 6, 2013 at 10:41 PM, Marcos Lima <marcoslimagon@gmail.com
> > > >wrote:
> > >
> > > > It really sounds good to me, this is a kick start =). I haven't
> > > contributed
> > > > anything
> > > > yet, but I would like to help you all to get this job done.
> > > >
> > > > I'm completely agree with Paul and Prescott.
> > > >
> > > > I know that there is a high commitment for keep the
> retrocompatibility
> > on
> > > > Lucene. Does Java Lucene API gets big changes every release?
> > > >
> > > > Is the Lucene.Net a port from a stable version from a Lucene version,
> > > > right? If the Lucene API gets only minor changes every stable release
> > (or
> > > > keep most of its source-code), we could compare the versions, check
> the
> > > > differences and bring them to Lucene.Net. Again, I haven't
> contributed
> > > with
> > > > yet, so I don't know how it is (just an idea).
> > > >
> > > > What's your approach for implement simple performance improvements
> > > (without
> > > > adding references or changing methods signatures)? Does it could be
> > done,
> > > > or "follow the java version only"?
> > > >
> > > >
> > > >
> > > > 2013/6/6 Paul Irwin <pirwin@feature23.com>
> > > >
> > > > > This is just an "outsider" suggestion as I haven't contributed
> > anything
> > > > > yet, although I will definitely help with the 4.x work as I have
a
> > > vested
> > > > > interest in seeing that get completed. I think there should be one
> > > person
> > > > > (or perhaps two) guiding what the structure and workflow will look
> > like
> > > > to
> > > > > avoid chaos. If the 4.x work is going to be starting from scratch
> as
> > a
> > > > > fresh port, that person should set up the project, get everything
> > going
> > > > in
> > > > > source control, create the folder structure, maybe stub out some
> > > classes,
> > > > > etc. Then divide and conquer with anyone interested in
> contributing,
> > > > > perhaps by namespace.
> > > > >
> > > > > I like the idea of throwing the java code in there so it's easy to
> > > > > reference.
> > > > >
> > > > > Again, I can work on Lucene.Net.Documents, Lucene.Net.Analysis, or
> > > > > Lucene.Net.Store -- or any others, those are just the ones I'm most
> > > > > familiar with the inner workings. Tell me what to do and I'll get
> > > started
> > > > > on my fork.
> > > > >
> > > > > Paul Irwin
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 2:38 PM, Prescott Nasser <
> > geobmx540@hotmail.com
> > > > > >wrote:
> > > > >
> > > > > > Hey guys -
> > > > > > I know I've been MIA a little while. We have a board report
due
> > soon
> > > -
> > > > I
> > > > > > think it prudent that we advise them that we seem to have stalled
> > > > > somewhat.
> > > > > > We've got a few low hanging items out of of jira and have been
> > > > responsive
> > > > > > on the mailing list to community questions, but I don't think
> we've
> > > > done
> > > > > > anything to move forward with 4.0.
> > > > > > To that end - I'd like to *try* and start us back up moving
> > forward.
> > > > What
> > > > > > is the best way to accomplish this? If we took the java lucene
> 4.0
> > > code
> > > > > and
> > > > > > committed that java to our branch and then just let people pull
> > that
> > > > down
> > > > > > and being changing / modifying is that one way to maybe make
some
> > > > forward
> > > > > > progress?
> > > > > > ~P
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > --
> > > > Marcos Lima
> > > > Software Developer/Tech Lead
> > > > marcoslimagon@gmail.com
> > > > tel: +55 (19) 9798-9335
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message