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 Wed, 19 Jun 2013 18:02:07 GMT
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