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:13:48 GMT
inline


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

> Ah, I gotcha. Still getting used to git, I've been a TFS guy for so long
> :-)
>
> So to recap, the branch_3x will be used for any patches or anything to the
> current 3.0.3 release, while trunk is what we will branch from for 4x dev.
> Correct?
>

Yes - we can branch from it for 3.6 development if anyone will be
interested in that


>
> Thanks for pushing the Version.cs. What's the deal with the github sync?
> Who could diagnose that?
>

Not sure, Apache Infra, basically. Just use the apache repo for now while
we get that sorted out.


>
>
> On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <itamar@code972.com
> >wrote:
>
> > 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