lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Aroush" <>
Subject RE: good incubator citizen
Date Sat, 24 Feb 2007 03:09:25 GMT
Hi Erik and all,

Erik: Thanks for bringing this to my attention privately and on the mailing
list.  Those releases were done as a result of my bad doing -- I am new to
ASF and I didn't know a release must go through a "vote" first.

All: Few days ago, I have removed all 2.0 packaged ZIP releases from the
Lucene.Net download site, and I believe Erik wants the reaming once to be
removed too, this I will do too.  I want to make sure each new release does
follow the ASF process as well as anything we do here is within the ASF

As for how I do the port, there is nothing magical about it and I already
described the process in the past both on this mailing list, back at
SourceForge.Net as well as on Java Lucene mailing list.  The steps are as

1) Using an Eclipse plug-in that I wrote, this plug-in will convert, (using
Eclipse refractor feature) all method names from lower case name to upper
case.  That it, getFoo() becomes GetFoo().  In addition, I convert the name
space from org.apache... to Lucene.Net.

2) Using JLCA, which comes with VS.NET 2005 or you can download it as a
plug-in into VS.NET 2003, I convert the Java code to C#.

3) JLCA doesn't convert everything and in some cases it will do wrong
conversions.  In addition, it introduces a lot of it's own classes and
methods in the class SupportClass.  For those, I have compiled notes and
wrote a little tool to scan the C# code for open issues and point them out.
If I have documented an issue from a previous port, then I have a
replacement for it handy, otherwise, I add the new issue to my knowledge

As you can see, most of the port work is done via JLCA, the only magic is my
plug-in for Eclipse which does the naming conversion -- this is what gives
the converted code the look and feel of .NET.

Can this initial task be streamlined across multiple developers?  I don't
think so.  It is a one time task, must be done in one-shot as one activity,
and it takes me few hours to do.

The bigger task and the real hard work, which is where I can really, REALLY,
use help on form the Lucene.Net development community, is finishing off the
open issues that JLCA didn't resolve and debugging the converted code.
Those non-converted code must be dealt with manually and any wrong
conversion must be debugged.  This is the part that takes a while before a
new release becomes usable.

This is why, with 1.x, and 2.0 releases, I have always done the above
process and released the code -- as one chunk onto SVN -- as soon as I got
step #3 done.  Every initial release into SVN was a non-working release.  It
took me few more months afterward (vs. few days for the initial conversion)
to get a new version in a useable state.

I hope this explains things and why it's done like so.  If not, and if you
have suggestions, please let me know.


-- George Aroush

-----Original Message-----
From: Erik Hatcher [] 
Sent: Thursday, February 22, 2007 11:52 PM
Subject: good incubator citizen

George and other Lucene.Net contributors,

As a mentor for this project, I've been lame and for that I apologize.  It
has come to my attention that we're not following the rules very well with
respect to voting on releases, and have been distributing unapproved

The report I received was this ------
Lucene.Net has done a few releases without any kind of vote, without
following incubator rules, putting tarballs in the wrong location, etc. See,
for example,

I found out about it while reading the january incubator board report:

   * The code base continues to develop and new releases are being made.
   Recently Lucene.Net 2.0 "final" was release as well as Highlighter.Net
   and Snowball.Net 2.0.  In addition, for each of those components, there
   corresponding MSDN style documentation is also release.

Example tarball:

  * no incubation disclaimer
  * wrong LICENSE.txt file
  * no NOTICE.txt
  * copyright dates (2002-2004) on license headers seem wrong

I've discussed this situation a bit in private with George and he's already
taken some corrective actions.  However, I still see files here:


These need to be removed, and then official votes need to take place.

I have to admit to still being clueless on how all the procedures for these
things work myself.  However, Solr just breezed through incubation, so I
encourage you to examine the processes that were followed throughout that
incubation period.

While I realize what George has undertaken is labor intensive, we  
must go through these steps in order to do things the "Apache Way".   
By dotting our i's and crossing our t's on the administration front it you
will be rewarded.

Another idea that came up in these discussions in how to gain more
transparency to the commits George makes is to make the conversion from Java
Lucene to Lucene.Net more open.  Obviously some type of automated conversion
of the code is made.  The tool that does this conversion, is it open source?
Can the process be made to be more automated and runnable by others besides

Let's get back on track!


View raw message