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 Fri, 07 Jun 2013 17:16:39 GMT
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
>

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