Hi Folks, Now that DIGY and Doug have committership status, progress on Lucene.Net and commitment should be a lot more active and efficient. Still, the community needs everyone to be active and help to keep Lucene.Net in par with Java Lucene and eventually graduate from incubation.
To help guide everyone on submitting patches, and committing those to SVN, I would like to share with you my rule-of-the-road about accepting patches. Here are the two basic rules that I have followed for accepting patches: 1) Any patch addressing a port defect, must be accepted and committed after a code review. This is common sense. 2) Any patch causes a drastic change in Lucene.Net that doesn't address a crushing issue, must be rejected. This is to prevent general code delta divergence which can complicate subsequent ports as well as cause difficulties addressing general defects and port issues (#1 above). 3) Any patch introduces a divergence in the API, or index format with Java Lucene, must be rejected. This is common sense (but more below). Regarding #3, this is very important if we are to certify that version X.Y of Lucene.Net is in fact a port of Java Lucene X.Y. This means rejecting patches which try to address "improvement" (or even fix) Lucene.Net X.Y but such improvement / fix comes from Java Lucene X.Y.Z. The above is my rule-of-the-road, which I have impose onto myself. If you have any questions, let us discuss, vote and set a new rule-of-the-road. Regards, -- George