lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mherndon michael <mhern...@michaelherndon.com>
Subject Re: Lucene 4.0
Date Thu, 06 Jun 2013 23:25:08 GMT
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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message