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 04:08:43 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message