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 policy. 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 follows: 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 base. 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. Regards, -- George Aroush -----Original Message----- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Thursday, February 22, 2007 11:52 PM To: [email protected] 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 releases. 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, http://mail-archives.apache.org/mod_mbox/incubator-lucene-net-dev/ 200701.mbox/[EMAIL PROTECTED] 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 2.0 and Snowball.Net 2.0. In addition, for each of those components, there corresponding MSDN style documentation is also release. Example tarball: http://incubator.apache.org/lucene.net/download/ Highlighter.Net-2.0-001-07Jan07.src.zip * 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: < http://incubator.apache.org/lucene.net/download/> 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 George? Let's get back on track! Erik
