Hi Sean, As long as we are not braking rule #2, and the public APIs remain backward compatible I would say go ahead and submit a patch. However, a while back, when I experimented to do just that, I quickly found the amount of change was all over the place with no end in sight.
Regards, -- George > -----Original Message----- > From: Sean Carpenter [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 15, 2008 8:53 AM > To: lucene-net-user@incubator.apache.org > Subject: Re: Lucene.Net and my rule-of-the-road > > 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 > > > > >
