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

Reply via email to