lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Lucene 4.0
Date Thu, 06 Jun 2013 22:00:42 GMT
Ok, haven't noticed that branch. Just use it then for 3.x development. WRT
v4, yeah - just fork the repo and work on whatever branch. When you send us
PRs we will merge either to master or to a dedicated repo. For now it
doesn't really matter, thats the beauty of git.

I pushed a new Version.cs file, you should see it on the apache servers
(github sync seems to be off)


On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <pirwin@feature23.com> wrote:

> 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