lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Martz <>
Subject Re: Vote thread started on
Date Thu, 30 Dec 2010 20:33:48 GMT
Troy, et al,

Given the recent positive shift in attitude regarding the Lucene.Net project, I would like
to consider ways that I could help contribute as well. As with other people in the community,
while my company is very small (I am both Chief Software Architect and Chief Bottle Washer),
we do a have a vested interest in seeing this project succeed.

One thing to consider while developing the incubator proposal is that the reason I stopped
attempting to contribute was that very early on it was made very clear to me that this project
was a one-man show and that any efforts I offered towards working on the port were not welcome.
I think that in order to succeed the new proposal needs to embrace transparency in the entire
port, testing and fix process so that more people (and potential committers) can have the
opportunity to get their hands dirty and expect that their ideas will not be rejected out
of hand. I'm not saying that everyone should be a committer but rather I would hope that the
committers would at least consider input and help from the community.

It's important to remember that Lucene.Net is "just" a (very good) line-by-line port*. This
means that the skill set we need from committers is very different than what the Lucene Java
project would be looking for. I agree with various people who have raised the good point that
automation is the way to go for the initial pass. There are now multiple OSS Java->.NET
conversion tools out there that while not perfect could offer a good starting point. The strength
of working to customize scripts or even the tools themselves would be a repeatable and documented
porting process that could be executed in parallel by multiple people with the expectation
of deterministic results.

     Sharpen (db40):
     Java 2 CSharp (ILOG/IBM):

* Various spin-offs are embracing a functional port model but this is not what I am looking
for and I get the feeling that some developers would prefer to stick with a "true" port as

Also remember that we would need not only people to work on the porting mechanism and port
but also people willing to develop and run the unit tests and such.

In summary, I believe that if we can agree as a community to get away from this magic one-man
black-box porting model then more people such as myself would come out of the woodwork and
help out.

My way is not the only way but it does represent my personal thoughts in any case.

Thanks for your consideration,
Ben Martz

> 	Troy Howard <>
> December 30, 2010 11:51 AM
> Scott,
> We should communicate on the public list as much as possible. I'll put
> together the draft proposal today, post it here, and ask for feedback
> from both the Lucene PMC and the community. We will wait over the
> weekend and Monday to allow people who might have additional input the
> opportunity to either see this at home or at work.
> On Tuesday (Jan 4th) we will move forward with whatever our best
> effort has produced and go from there.
> Thanks,
> Troy

View raw message