lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 许鹏 <xupeng1...@188.com>
Subject Re: Lucene 4.0
Date Fri, 09 Aug 2013 14:56:07 GMT
Paul,

Thanks very much! I think I will work on porting the ChineseAnalyzer
in Contrib.Analyzers first, if I have any problems with that, I will send
message to you, and ask for help.
This work will be my first contribution on Lucene.Net project, and, also
my first contribution on open source, I will try my best to finish this work.
If anything you want to know about me, please let me know.

:-)

Athrun Saga
8/9/2013

-----邮件原件-----
发件人: dev-return-7258-xupeng1983=188.com@lucenenet.apache.org [mailto:dev-return-7258-xupeng1983=188.com@lucenenet.apache.org] 代表 Paul Irwin
发送时间: 2013年8月9日 21:12
收件人: dev@lucenenet.apache.org
主题: Re: Lucene 4.0

Athrun,

You can do what I did before you become an "official" contributor, which is
to fork the lucene.net repo on Github at
https://github.com/apache/lucene.net, or if you want to work off of my
latest changes before it's pulled into the main repo, you can pull from
here: https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0

If you speak Chinese, you could jump in and help port the ChineseAnalyzer
in Contrib.Analyzers. When referencing the Java source, we're currently
referencing the code in the lucene_solr_4_3 branch as when we started, 4.4
wasn't out yet. Don't reference trunk/master, as that's where 5.0 dev is
taking place if i'm not mistaken.


On Fri, Aug 9, 2013 at 12:08 AM, 许鹏 <xupeng1983@188.com> wrote:

> Hi Paul,
>
>
> I am a developer from China, I currently using Solr 4.3.0 to construct our
> own
> data system for search and analysis. I am very interested in the work that
> porting
> Lucene java 4.3.1, and I want to join this team to work on this. But I
> have never
> been involved in open source projects, Can you give me some suggestion to
> join
> the team and start contributing.
> Additional, I am not good at English writing, but reading is ok. Also, I
> am now learning English,
> I believe it will be more smooth communication.
>
>
>
>
> Athrun Saga
> 8/9/2013
>
>
>
>
>
>
> At 2013-08-09 03:31:47,"Paul Irwin" <pirwin@feature23.com> wrote:
>
> >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
View raw message