What about changes that make Lucene.Net more .Net-like? For instance, I was thinking of submitting a patch to add an IDisposable implementation to IndexWriter, IndexSearcher, etc. so that the using() idiom could be implemented. This is a natural way to write code in .Net, especially since properly closing these objects is important. Thoughts?
Sean Carpenter On Fri, Nov 14, 2008 at 9:32 PM, George Aroush <[EMAIL PROTECTED]> wrote: > 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 > >
