Mailing-List: contact lucene-net-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucene-net-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: "George Aroush" <george@aroush.net>
To: <lucene-net-user@lucene.apache.org>,
	<lucene-net-dev@lucene.apache.org>
References: <AANLkTi=X=J0pPrrdFo=ECfFjrC=jtcdL3OVKpb1BR9=R@mail.gmail.com>
 <4C00ED0D3953264BBCB45A04D9FAC8500A2F9544@TK5EX14MBXC201.redmond.corp.microsoft.com>
In-Reply-To: 
 <4C00ED0D3953264BBCB45A04D9FAC8500A2F9544@TK5EX14MBXC201.redmond.corp.microsoft.com>
Subject: RE: Lucene.NET Community Status
Date: Fri, 5 Nov 2010 23:39:33 -0400
Message-ID: <03df01cb7d64$3a4fc8e0$aeef5aa0$@net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
thread-index: AQHLe9MATmTUvSh98ESvQ95orcCTmpNgvupfgAIe0KA=
Content-Language: en-us

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