You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by George Aroush <ge...@aroush.net> on 2008/11/15 03:32:16 UTC
Lucene.Net and my rule-of-the-road
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
RE: Lucene.Net and my rule-of-the-road
Posted by George Aroush <ge...@aroush.net>.
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:stcarpenter@gmail.com]
> 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
> <ge...@aroush.net> 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
> >
> >
>
Re: Lucene.Net and my rule-of-the-road
Posted by Sean Carpenter <st...@gmail.com>.
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 <ge...@aroush.net> 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
>
>