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, 08 Aug 2013 19:31:47 GMT
Is this mailing list dead?! If anyone is interested in releasing an
up-to-date build of Lucene.net, please write back! If you didn't read my
other messages, I have Lucene.net Core working with Lucene java 4.3.1
compatibility thanks to the help of my colleagues. We just need to round
out the contrib modules, unit tests, and documentation as a community and
we can push Lucene.net forward almost 3 years in time -- Lucene java 3.0.3
was packaged in December 2010!

I have checked in the KeywordAnalyzer, WhitespaceAnalyzer, SimpleAnalyzer,
ClassicAnalyzer, and StandardAnalyzer to the Contrib.Analyzers assembly
(where they now live in Lucene java, they were moved from core) and their
associated filters and tokenizers. I've briefly tested each and they seem
to work correctly. I've purposefully "Exclude[d] from Project" the other
language analyzers until we can forward-port them. So now the Analyzers DLL
compiles with those analyzers only. Also, I fixed the bug that was causing
NumericRangeQuery to not work.

Next on my list is the QueryParsers contrib library (QueryParser was moved
out of Lucene java core) so that, combined with StandardAnalyzer, we can
test a pretty common real-world use case (the prototypical "hello lucene"
tutorial). After that, it might be worth forward-porting what we have so
far to 4.4 and use that as the latest point to finish out the port. The
changes shouldn't be too dramatic to core from what I can tell.

My fork/branch: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0

I'll keep updating as I go, but if anyone wants to jump in, there's not a
better time than now...



On Wed, Aug 7, 2013 at 11:35 AM, Paul Irwin <pirwin@feature23.com> wrote:

> I made a dumb mistake... I have worked with StandardAnalyzer so long that
> I forgot that KeywordAnalyzer is not what I needed to be using, I needed to
> use WhitespaceAnalyzer to do a simple breakup of terms by spaces... duh.
>
> Now it works after re-indexing with a quick, dirty implementation of
> WhitespaceAnalyzer :-) The index that I created with Lucene.net 4.3.1 can
> also be read and searched by Java Lucene 4.3.1. Now I'm going to move on to
> find out why NumericRangeQuery isn't working.
>
> Sorry for the blast of emails, but I wanted to prevent people from
> spending time hunting down my mistake!
>
>
> On Wed, Aug 7, 2013 at 10:08 AM, Paul Irwin <pirwin@feature23.com> wrote:
>
>> I was able to resolve the EOF issue by fixing a bug in ReadVLong. Java's
>> byte being signed is a pain.
>>
>> Now there's no exception doing a TermQuery, but I also don't get any
>> results. It doesn't find any terms when scanning for them. I also tried a
>> NumericRangeQuery on DocID (see example gist) between 100 and 200 and it
>> didn't find any results that way either. So right now only
>> MatchAllDocsQuery seems to work.
>>
>> If anyone would like to do a Google Hangout or anything sometime to look
>> into it, let me know.
>>
>>
>> On Wed, Aug 7, 2013 at 9:44 AM, Paul Irwin <pirwin@feature23.com> wrote:
>>
>>> I realized after I sent that email last night that I could do as you
>>> described. When you've been debugging through CorruptedIndexExceptions, you
>>> get a little bit of tunnel vision... haha
>>>
>>> I have now fixed a few bugs and I can now do a MatchAllDocsQuery with
>>> IndexSearcher and TopScoreDocsCollector and get hits! And .ToString()'ing
>>> the matching documents prints the fields to the console, so it's loading in
>>> the stored fields data correctly.
>>>
>>> I tried doing a TermQuery and now I get a "read past EOF" exception that
>>> I can't figure out. There's a whole bunch of buffered byte array operations
>>> going on and I can't determine where the issue came from. I'll keep
>>> looking, but if someone could grab my fork/branch and help me look that
>>> would be great. Here's example index writing and then reading code (also
>>> included is a quick port of KeywordAnalyzer):
>>> https://gist.github.com/anonymous/6174164
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Wed, Aug 7, 2013 at 12:19 AM, Itamar Syn-Hershko <itamar@code972.com>wrote:
>>>
>>>> Great
>>>>
>>>> You can build you Query objects on your own to execute a search, you
>>>> don't
>>>> actually have to use QueryParser for that
>>>>
>>>>
>>>> On Wed, Aug 7, 2013 at 5:52 AM, Paul Irwin <pirwin@feature23.com>
>>>> wrote:
>>>>
>>>> > Hey all, sorry it's been a little while, but I wanted to let you know
>>>> that
>>>> > although I took a few weeks off from it, I now have a 4.3.1 equivalent
>>>> > Lucene.net core building and able to write a simple index in Lucene
>>>> 4.2
>>>> > codec and read in things like the number of documents and whatnot.
>>>> Since
>>>> > QueryParser has been moved to a separate module in Lucene Java 4.x, I
>>>> > haven't ported that yet so I haven't done a real search, and I only
>>>> built
>>>> > the index using a quick port of KeywordAnalyzer which all those
>>>> analyzers
>>>> > have also moved to another module. But this is definitely good
>>>> progress and
>>>> > should be a launch point for finishing a 4.3/4.4 port.
>>>> >
>>>> > You can see my fork/branch here:
>>>> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0 (note:
>>>> like I
>>>> > said, only core builds now, no modules/tests build, so only open the
>>>> > Lucene.Net.Core.sln)
>>>> >
>>>> > I'm sure it's riddled with bugs, but I hope this can help kickstart
>>>> the
>>>> > community into finishing the 4.3/4.4 port. Let me know if you have any
>>>> > questions, thanks!
>>>> >
>>>> >
>>>> > On Thu, Jun 20, 2013 at 2:59 PM, Itamar Syn-Hershko <
>>>> itamar@code972.com
>>>> > >wrote:
>>>> >
>>>> > > 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