George,

Great summary of everything that is going on with Lucene.NET. Once you
produce that actionable list of items I'm more than willing to help out
where I can.

On Fri, Nov 5, 2010 at 8:39 PM, George Aroush <geo...@aroush.net> wrote:

> Hi Everyone,
>
> Again, my apology for the long post, but like I did before, I am going to
> reply in one post to answer and clarify questions around this subject --
> again, my points and clarification below are in no particular order or
> importance.
>
> 1) SVN: Whatever backend source repository is used, as long as the tool is
> doing its job, should not hinder a developer -- SVN is well know, and
> competes against much larger and complex similar product.  As long as
> Lucene.Net will be released under ASF, it's required that all ASF codes be
> hosted on ASF's SVN.  This is to insure legal issues don't arise.  In
> addition (I'm not sure how many know this) if you want to submit fixes, or
> code, and you are not a committer, the only way your work will be accepted
> is if: a) you do so through ASF's JIRA, b) include the ASF license terms
> (if
> it's new code and not a patch).  Otherwise, your code will be rejected.
>
> 2) CodePlex.com: Lucene.Net being at ASF has far more benefit because it
> has
> Java Lucene to fall back to.  There has been a lot of cross post to Java
> Lucene and Lucene.Net mailing list from various users.  In addition, PMC of
> both projects have mutual support.  What's more, if we manage to mature
> Lucene.Net, being at ASF means we WILL have influence on Java Lucene (this
> already happened in the past -- we made an API change in Lucene.Net and
> requested it for Java Lucene to sync up with Lucene.Net).  Also, if you
> search "lucene.net" on CodePlex.com, you will see over 3 dozen projects
> using it in one form or another -- thus, the exposure is already there, and
> folks do know about Lucene.Net.  Finally, if anyone wants to move
> Lucene.Net
> out of ASF, you can do so, but you can't call it Lucene.Net as ASF owns
> that
> name (I signed a release form when I moved dotLucene from SourceForge.net
> to
> ASF back in 2004; Grant can pull it out if need be).  I made this move
> because: a) ASF has a brand name, b) dotLucene can benefit from Java Lucene
> under one umbrella.  Btw, Java Lucene was originally on SourceForge.net
> before moving to ASF.
>
> 3) ASF + MSFT working together: We, as developers, can champion it,
> however,
> ASF legal will have to get involved and has the final say.  I want to point
> this out to emphasize that ASF is more than a project or code repository.
> This is why the brand name is important and why there are standard that ASF
> expects of its projects.  If you haven't already, please subscribe to
> general[AT]incubator.apache.org and you will see broader discussions about
> other projects with ASF PMCs.
>
> 4) line-by-line port and what got us here: As I have pointed out before,
> this has a lot of benefits (I don't want to repeat them, you can read my
> earlier post).  Yes, a line-by-line is tedious and not sexy, however, this
> isn't why we are here (i.e.: Grant's email).  We are here because: a) the
> jump from 2.4.x to 2.9.x port was huge in terms of Java Lucene code changes
> and new code, and b) JLCA is no longer supported by MS to understand new
> Java code (it used to port over 80% of the code and the rest I finished off
> via scripts I wrote or manually).  Here is a fact about 2.9.1 release.  If
> you look at its release date, you will see that Java Lucene 2.9.1 was
> released on Nov. 6, 2009 and Lucene.Net 2.9.1 was released (via SVN) on
> Feb.
> 17, 2010.  Yes, that is 3 months delay, but if you look under the hood,
> Lucene.Net 2.9.1 "beta" was made available on Nov 16 2009 -- this beta
> release, is what's known as the "initial line-by-line port" -- is the bulk
> of the port work.  Now, a) I don't think 3 month delay is too long, but yes
> I would like it shortened, and b) subsequent releases, 2.9.x to 3.0.x,
> should be way simpler because the port is a delta of the two versions.  So,
> again, we are here because no one bothered to work on the port after
> releasing 2.9.x -- not necessarily the next port will be hard because the
> delta shouldn't be too large.
>
> 5) .NET'fying (again): I want to bring this up again because it's something
> keeps came up as back as 2005 and is up again now.  When finished working
> on
> 2.9.x, we sync'ed up Java Lucene and Lucene.Net code base as well as
> release
> dates very well.  The plan was to achieve commit-per-commit port moving
> forward -- i.e.: once a SVN commit for Java Lucene takes place, we port
> that
> commit to Lucene.Net within a week.  This would have: a) kept Lucene.Net
> code base in sync with Java Lucene and thus eliminating the bulk port that
> I
> have been doing, b) allow us to -- selectively -- change both the internal
> and external code of Lucene.Net to be more .NET'es.  Unfortunately, this
> didn't go through as I wasn't able to commit to Lucene.Net (I was absent
> from the project since early this year due to family emergency) and no one
> picked up the project to continue working on it.  It seems to me the
> community was happily using 2.9.x and didn't bother to think about "what's
> next" until when Grant's email arrived!  (Sorry if this last statement
> sounding harass; it's not what I want to portray, other than emphasize that
> users have to be contributors too for Lucene.Net to be successful).  Btw,
> the port isn't just the core Lucene code, it's also all the test code that
> come with Java Lucene.
>
> 6) Wrapping Java Lucene with WCF, using IKVM or adding a .NET'es layer:
> Those are fine ideas, and maybe valuable to have -- you are welcome to
> start
> such a project if you want.  There are already such ports out there for
> languages other than C# (check out PyLucene, PLucene, Lucy, etc. they are
> not line-by-line port)  The line-by-line port has more values as has been
> highlighted several times.  My point here is, there is nothing stopping
> anyone from starting an alternative port, but I believe our energy would be
> misplaced.
>
> 7) Comparing Lucene.Net to project X's Java to .NET port: Some examples
> that
> come up, such as NUnit, NHibernation, and NAnt, are not a fair comparison.
> NUnit is much smaller and is not compatible to JUnit (API, as well as
> parameters, and classes don't match up).  I submit to you that if NUnit
> maintained compatibly with JUnit (like Lucene.Net with Java Lucene does),
> the port of the Lucene test code would have been a breeze, but it's not.
>
> 8) Companies backing Lucene.Net: I'm glad to see the list, and I know few
> others (big ones) but can't name them unless if they want to speak up.  The
> question is, who will jump in first and provide resources?  To any such
> company, it's in your interest to do so.  Why?  Once someone from your
> company proves that s/he is active and contributes, s/he will be nominated
> to become a committer.  That committer is now representing YOUR and thus,
> your vote counts.  In effect, you can define the direction of Lucene.Net.
> To start with, at a minimum, if those companies do promote Luene.Net (via
> "powered by") and are willing to have their name listed on Lucene.Net's
> home
> page, that would be a good start.  Next, those companies should add some
> blob in their product and on their website that they are using Lucene.Net.
>
> 9) Visual Studio 2005/2010 IDE support (or other build-env.): This the
> least
> of our concern.  How often new files get added/renamed/removed/moved that
> require someone to commit changes to the VS build file?  Also, only
> committers can check-in changes; I bet you committers don't mind taking
> over
> this small task of maintaining the IDE build file(s) if folks are actively
> working on more relevant task.  On my machine, I have VS 98, 2005 and 2010.
> Why?  Where I work, we support apps built with all of those versions (and
> did I mention on Linux, Solaris, and AIX -- sorry, no Mac).  What we should
> care about is targeting the lowest common, widely acceptable framework,
> such
> as 2.0.  If anyone needs Lucene.Net for a more recent framework, you can
> build it off the source.  What would be more helpful is if we provide
> binaries releases for Windows CE, Compact Framework, Framework 2.0, 3, et.
> al. for folks who can't / don't want to build off the source.
>
> If you have read this far, thank you! :-)  Now, I was suppose to put
> together a list of actionable tasks for the short term need of Lucene.Net.
> I promise that I will do so over the weekend.
>
> Thanks,
>
> -- George
>
>

Reply via email to