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, 20 Jun 2013 18:59:29 GMT
Paul, that's awesome. I will need some more time to go over this thread and
your work to give actual feedback, SUPER busy at the moment


On Wed, Jun 19, 2013 at 9:02 PM, Paul Irwin <pirwin@feature23.com> wrote:

> All,
>
> My colleagues and I have made good progress on porting Lucene 4.3's core
> library before, during, and after the hackathon last week. We now only have
> some remaining items in Search, Index, and Codecs namespaces (plus a few
> other minor ones here and there). I expect to be done by the end of the
> weekend. Analysis, Documents, Store, Util (except some FST and Packed), and
> the root Codecs and Codecs.PerField namespaces are all now "done".
>
> Again, my goal is to only get a buildable, experimental build of Lucene.net
> with 4.3.0 (now 4.3.1) compatibility. We are intentionally not porting new
> javadoc comments or unit tests right now, due to the vast amount of code
> that needs to be written just to get it to compile. If this work ends up
> becoming a pull request, great, otherwise it should help accelerate a port
> of 4.3.x since the bulk of the work on core will already be done and
> contributors can use it as a reference. And again, we're taking the
> pragmatic approach of porting class-by-class, namespace-by-namespace, with
> the understanding that until we're done the project won't build.
>
> Once complete, I also will work on updating the Analyzers contrib module
> and porting the QueryParsers contrib module, which I feel should be
> included in the core NuGet package for Lucene.net as the core library is
> now (post-4.0) practically useless (or atleast not turn-key) without them.
> You can check out the code on my fork/branch here:
> https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
>
> In particular, I'd like some feedback on my work on ByteBuffer,
> MemoryMappedFileByteBuffer, MMapDirectory, and NIOFSDirectory. For the MMap
> support, I created a ByteBuffer subclass that uses .NET 4's
> MemoryMappedFile support which should emulate the Java nio stuff pretty
> well, but required some creative shuffling of the code to make it work due
> to lifecycle management.
>
> I'll update again this weekend or next week, when we should have wrapped up
> most of the main hacking on porting the core code.
>
> Paul
> On Thu, Jun 13, 2013 at 8:39 AM, Paul Irwin <pirwin@feature23.com> wrote:
>
> > Marcos,
> >
> > That would be helpful. As far as I can tell, the 3.0 java code is only on
> > SVN here, before the lucene and solr projects were bundled together:
> > http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/
> >
> > The SVN for 4.3 java is here:
> > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
> > And the GitHub for 4.3 java is here:
> > https://github.com/apache/lucene-solr/tree/lucene_solr_4_3
> >
> > My fork/branch of Lucene.net for the 4.3 port is here:
> > https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0
> >
> > My fork is the "upstream" fork for my team members, and i'm remote
> merging
> > their changes in from their forks while they fetch/merge from mine to get
> > everyone else's changes, rather than using pull requests. James and I
> have
> > been working the past few days on the Util namespace ahead of tonight's
> > hackathon since that namespace is in common with the rest of the
> > namespaces. Tonight, we'll have at least 8 guys that I know of hacking on
> > porting 4.3, each with a different namespace or part of a namespace.
> Since
> > we're going class-by-class, namespace-by-namespace, the project does not
> > build as it is. Once we finish doing a translation of each file, then
> we'll
> > hammer out any remaining issues and get it to build again. I'm hoping
> that
> > we can get at least 75% done with Core tonight. Wish us luck!
> >
> > But one thing to keep in mind is it looks like much functionality has
> been
> > moved out of core into the contrib modules, especially around analysis,
> for
> > 4.0+. For example, there are no built-in analyzers in core anymore. So
> when
> > this is all done, we may want to include at least the analysis contrib
> > module in with the standard core NuGet package, because otherwise it's
> > practically useless unless you roll your own analyzer.
> >
> > Paul
> >
> >
> > On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <marcoslimagon@gmail.com
> >wrote:
> >
> >> Hi everyone!
> >>
> >> Does someone know where can I find the 3.0.3 release from Lucene(java)?
> >>
> >> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and
> make
> >> the diff between then and get all changes between releases... I gonna
> >> publish it here soon. (If you think there is another important release,
> >> let
> >> me know)
> >>
> >> Paul, are you dealing (i`m not sure about this word, sorry) with 4.3.0
> >> port
> >> for .Net on github (last email)?
> >>
> >> See you,
> >>
> >>
> >> 2013/6/10 Paul Irwin <pirwin@feature23.com>
> >>
> >> > Thanks for the discussion points, Michael.
> >> >
> >> > I would vote for not worrying about trying to achieve portable
> >> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> >> completed.
> >> > Otherwise it may delay the project and stall it further. That's just
> my
> >> > $0.02 based on my admittedly selfish need for 4.x features.
> >> >
> >> > I have started porting the changes from the core library (from the
> >> > java lucene_solr_4_3 branch) in my fork on github in a separate
> branch.
> >> > Since I need 4.3 ASAP, I am just going to keep going on my port until
> >> > there's changes to pull from upstream to work from. Also due to my
> time
> >> > constraints, I am not fully documenting new methods that I'm adding.
> >> But if
> >> > anyone wants to pull/copy/reference my changes while porting, that's
> >> > awesome. My branch currently does not build as I'm primarily going
> >> > class-by-class, starting with the util namespace. Once we get the ball
> >> > rolling on a community effort, I'll stop my rogue work and join in.
> But
> >> > hopefully my work will be useful to someone, if not as a pull request
> >> then
> >> > as a reference. I'm also going to be holding a hackathon this week
> with
> >> my
> >> > colleagues where we're all going to work on the port. I'm comparing
> >> files
> >> > and making changes as necessary, rather than starting from scratch. My
> >> > repo/branch is here:
> >> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >> >
> >> > Paul
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> >> > mherndon@michaelherndon.com> wrote:
> >> >
> >> > > the guithub.com repo is a mirror to the git mirror that apache
> >> > maintains.
> >> > >
> >> > > The was some work at one time to move the official svn repository
to
> >> > start
> >> > > using git one instead.  Was that actually finalized or not?
> >> > >
> >> > > The Lucene.Net_4e (e for experimental) is an old branch to see what
> >> kind
> >> > of
> >> > > work was involved using a portable libraries project. Some of it can
> >> > still
> >> > > be used but will need to be validated against the current version
of
> >> > Java's
> >> > > Lucene.  It was also using .net 4.
> >> > >
> >> > > clean branch vs current.     Its going to depend on what we support.
> >> If
> >> > you
> >> > > support windows mobile 8, win RT, then the current code in trunk
> will
> >> not
> >> > > compile against those versions of the framework which would a
> >> frustrating
> >> > > starting point, then you couldn't even run tests, which would make
> >> taking
> >> > > patches very difficult.  Supporting those can almost mean larger
> gaps
> >> in
> >> > > design between Lucene.Net and its parent project.
> >> > >
> >> > > Also the  structure has changed significantly between the branches
> and
> >> > the
> >> > > side of the code base of Lucene 4 is bigger, uses Java 6, and seems
> >> > > significantly different.  That doesn't mean you can't cherry pick
> >> stuff
> >> > > from the other tags/branches that would still work as is.  A clean
> >> branch
> >> > > would also make it easier to get our build / tool chain in order as
> >> you
> >> > can
> >> > > then do them incrementally versus having to do all the stuff that
I
> >> did
> >> > for
> >> > > the 3x branch which saps energy and desire to code.   It could also
> >> make
> >> > it
> >> > > easier to see which classes have been ported or not.
> >> > >
> >> > > The major downside to a clean branch is extra work it requires and
> the
> >> > > start up cost in time and energy of getting it in order, which can
> be
> >> > > daunting / intimidating and lower morale. And generally you want to
> >> use
> >> > > take your legacy code and refactor instead of in someways starting
> >> over.
> >> > >
> >> > > Are we going to port lucene 4 or 4.3 ?   If so I can do something
> >> similar
> >> > > to
> >> > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> >> > > where it tracks what needs to get ported / what has been ported.
> >> > >
> >> > > What are we going to support in the next version?
> >> > >
> >> > > Who is going to work on the next version?
> >> > >
> >> > > What would make the most sense and what would invigorate the
> >> community to
> >> > > get involved more and lower the barrier to entry?
> >> > >
> >> > > I think those are the questions that would make a lot of the
> decisions
> >> > for
> >> > > us so that we can get back to work on lucene.net.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <
> marcoslimagon@gmail.com
> >> > > >wrote:
> >> > >
> >> > > > Regarding the new branch, I'm a rookie with ASF projects...
> >> > > >
> >> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> >> > > > https://github.com/apache/lucene.net points to the same
> repository?
> >> > > (This
> >> > > > is new for me, pretty good) Which of them do you recommend (i'm
> used
> >> > with
> >> > > > SVN and its patterns).
> >> > > >
> >> > > > I'm checking the subversion right now.
> >> > > >
> >> > > > I can see the branches/Lucene.Net_4e. I think this is a old
> branch,
> >> i`m
> >> > > not
> >> > > > sure about its current status.
> >> > > >
> >> > > > Will we wipe the current solution from /trunk and start a new
one?
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > 2013/6/6 mherndon michael <mherndon@michaelherndon.com>
> >> > > >
> >> > > > > We may be forced to start with a clean/empty branch if people
> >> still
> >> > > want
> >> > > > to
> >> > > > > attempt supporting lucene.net for mobile devices, win RT,
etc.
> >> The
> >> > are
> >> > > > > many
> >> > > > > classes that Lucene.net uses from the full framework that
would
> >> not
> >> > be
> >> > > > > accessible in other versions of the .NET Framework.  It
also
> might
> >> > > > require
> >> > > > > a design that differs even more from its parent project.
> >> > > > >
> >> > > > > It might be wise to poll what users most desire in the next
> >> version
> >> > > > through
> >> > > > > jira or user voice.
> >> > > > >
> >> > > > >
> >> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> >> > itamar@code972.com
> >> > > > > >wrote:
> >> > > > >
> >> > > > > > 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
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > --
> >> > > > Marcos Lima
> >> > > > Software Developer/Tech Lead
> >> > > > marcoslimagon@gmail.com
> >> > > > tel: +55 (19) 9798-9335
> >> > > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> --
> >> 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