lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Date Wed, 04 Apr 2007 13:46:55 GMT
Ciaran,

The first step is to contribute some code as a patch (or full code  
dump) to an issue in our issue tracker.

Here's a good overview of the roles we use on Apache projects:

	<http://apache.org/foundation/how-it-works.html#roles>

"developer" is the next step up, and when that role has solidified in  
the community "committer" is considered.

   Erik


On Apr 4, 2007, at 4:28 AM, Ciaran Roarty wrote:

> George
>
> I think this would be best done on Lucene.Net 2.1 as this will  
> allow us to
> see the impact of fixes to the 2.1 codebase on the branched code.
>
> Now, how do I go about getting a branch?
>
> Ciaran
>
>
> On 03/04/07, George Aroush <george@aroush.net> wrote:
>>
>> Erik: I agree with your suggestion and I don't think any one is  
>> stiffing
>> any
>> innovation.  I'm questioning the value and if this is the right  
>> time to do
>> this.  At this point, it makes better sense to use our cycles on  
>> brining
>> the
>> code base in par with Java's code base.
>>
>> Ciaran: If you want to give this a try, go ahead.  You can start  
>> now with
>> the existing Lucene.Net 2.0 or wait a bit more for 2.1 release and  
>> report
>> back about your effort.  IMHO, I believe, while you do this  
>> change, the
>> existing public interfaces of Lucene.Net will end up changing too and
>> those
>> changes will have ripple effect all over the code base; but I like  
>> to be
>> proven otherwise and your experiment might put us on a new track.   
>> So go
>> for
>> it!
>>
>> -- George
>>
>> > -----Original Message-----
>> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
>> > Sent: Tuesday, April 03, 2007 4:58 PM
>> > To: lucene-net-dev@incubator.apache.org
>> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
>> >
>> > The best way to move forward from here is with actual code
>> > that demonstrates the benefits.  What I don't like seeing is
>> > the impression that innovation is being stifled.  If folks
>> > have great ideas, let's see 'em.  While George is the
>> > initiator of Lucene.Net, the community owns it.  I'm happy to
>> > see several folks speak up here about their interest in
>> > personally helping this project along.  This is exactly what
>> > it needs.  The more the merrier!
>> >
>> > Having a branch that is innovating with more hand-made C#
>> > sounds great to me.  The comparisons and contrasts between
>> > the two approaches becomes more concrete, allowing objective
>> > decisions based on some benchmarking and other factors.
>> >
>> >       Erik
>> >
>> >
>> >
>> > On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
>> >
>> > > Hi Everyone,
>> > >
>> > > I am going to have to side with George on this one.  Up to this
>> > > point I believe he has been the sole contributor &
>> > committer to the
>> > > Lucene.Net project, and has been porting over the code once the
>> > > Java group released a version.  Attempting to exploit the
>> > > advantages in the .NET framework and continuing to release
>> > > Lucene.Net in that manner will require lots of repetitive work.
>> > > Once we can maintain the Lucene.Net trunk identical to the Java
>> > > trunk (within a day or two), then we can safely start altering
>> > > internal implementations to take full advantage of the .NET
>> > > platform and not fall out of step with the API or  
>> functionality of
>> > > Java Lucene.
>> > >
>> > > Of those that are interested in development of Lucene, I highly
>> > > suggest subscribing to the Java Developer mailing list to see  
>> what
>> > > changes are being suggested and made.  Incorporating those  
>> changes
>> > > manually on the .NET side in a relatively short period after they
>> > > are committed on the Java side will take additional people.  I  
>> for
>> > > one am interested in this as I have the luxury of being able to
>> > > contribute during my normal work day.
>> > >
>> > > While I do agree that everyone will benefit from changes that
>> > > exploit the differences in the .NET framework, we'll need to  
>> start
>> > > with a smaller, more reasonable goal.  Has anyone thought
>> > of how we
>> > > can actually maintain a manual port that is reflective of the
>> > > current Java trunk?  My first thought is that a changelog
>> > will need
>> > > to be kept in each class file indicating which Java SVN
>> > version the
>> > > file was last ported from.  Any other ideas on that?
>> > >
>> > > Michael
>> > >
>> > > Ciaran Roarty wrote:
>> > >> George
>> > >>
>> > >> Thanks for the clarification. I think that you miss a central
>> > >> point of what
>> > >> I am trying to achieve and hopefully I will make this evident  
>> in my
>> > >> response.
>> > >>
>> > >> I understand that changing Lucene.Net - I hesitate to keep using
>> > >> the word
>> > >> 'pure' - into a .NET 2.0 specific library is a big change.
>> > >> However, I cannot
>> > >> understand why you think changes in the internals of a class  
>> will
>> > >> ripple all
>> > >> the way up a chain. Obviously, if the accessible interface
>> > changes
>> > >> then we
>> > >> would break calling code but much of the 'guts' of the code  
>> is not
>> > >> accessible outside of the class.
>> > >>
>> > >> I understand your reticence to diverge effort but I regard this
>> > >> exercise as
>> > >> a complementary task - it depends on a stable release of
>> > >> Lucene.Net; it does
>> > >> not replace it. By attempting to create a .NET 2.0 library, the
>> > >> community
>> > >> can learn the lessons of how to take Lucene.Net to
>> > Lucene.Net.2.0.
>> > >> As you
>> > >> rightly point out, there will be difficulties in doing this per
>> > >> Lucene
>> > >> release but if we learn how to do it now then we can drive
>> > out those
>> > >> difficulties and understand where they occur.... if we do not do
>> > >> it now then
>> > >> we will not know and, I suggest, we will not be able to do it in
>> > >> the future
>> > >> without far more pain.
>> > >>
>> > >> Does anyone on the list have an opinion on this? If the  
>> community
>> > >> does not
>> > >> think that there is any value in having a 'purer' Lucene.Net.2.0
>> > >> then that's
>> > >> fine; if this effort is not supported then I will let it go.
>> > >>
>> > >> Can you advise me of what is included in Lucene.Net 2.1 which is
>> > >> new? Is
>> > >> there a published roadmap for Lucene?
>> > >>
>> > >> Ciaran
>> > >>
>> > >> On 03/04/07, George Aroush <george@aroush.net> wrote:
>> > >>>
>> > >>> Hi Ciaran,
>> > >>>
>> > >>> Your goal is well understood; my pushback with it is in the
>> > >>> approach you
>> > >>> are
>> > >>> proposing and the timing.
>> > >>>
>> > >>> The current port is not 'purur' in the sense that it doesn't  
>> take
>> > >>> advantage
>> > >>> of what .NET 2.0 framework has to offer (this is because JLCA
>> > >>> only targets
>> > >>> .NET 1.1.)  Spinning off Lucene.Net 2.1 into another branch and
>> > >>> making it
>> > >>> 'purur' will make life very difficult to keep up with any
>> > >>> upcoming Java
>> > >>> Lucene releases because the code base will be so different  
>> (in the
>> > >>> Lucene.Net code base) to figure out what has changed in
>> > >>> comparison with
>> > >>> the
>> > >>> Java version when porting 2.2 for example.  Not to mention, it
>> > >>> will also
>> > >>> consume a good deal of our limited resources and to make the
>> > >>> current code
>> > >>> 'purur' is no easy task.
>> > >>>
>> > >>> If you are not convince, please give it a try.  You will see  
>> one
>> > >>> change,
>> > >>> in
>> > >>> one file, leading to several changes across several files (and
>> > >>> keep in
>> > >>> mind
>> > >>> you also have all the "contrib" code too which must continue to
>> > >>> work.)
>> > >>>
>> > >>> Before we undertake this task, which I consider a very
>> > >>> challenging task,
>> > >>> I'm
>> > >>> suggesting that we first prove yourself.  The prove will be  
>> that
>> > >>> we get
>> > >>> Lucene.Net 2.1 in a timely fashion, and that we can get the C#
>> > >>> Lucene's
>> > >>> SVN
>> > >>> in par with the Java Lucene's SVN.  If and when we achieve this
>> > >>> milestone,
>> > >>> then we can start porting changes from the Java land to the C#
>> > >>> land on a
>> > >>> weekly basic, or even sooner, and have the time to make
>> > the existing
>> > >>> Lucene.Net code base 'purur'.
>> > >>>
>> > >>> In a nutshell, there are more important and urgent work we need
>> > >>> to get
>> > >>> done
>> > >>> then start work on making the code 'purur'.
>> > >>>
>> > >>> Regards,
>> > >>>
>> > >>> -- George
>> > >>>
>> > >>> > -----Original Message-----
>> > >>> > From: Ciaran Roarty [mailto:ciaran.roarty@gmail.com]
>> > >>> > Sent: Tuesday, April 03, 2007 5:58 AM
>> > >>> > To: lucene-net-dev@incubator.apache.org
>> > >>> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project
>> > >>> involvement']
>> > >>> >
>> > >>> > George
>> > >>> >
>> > >>> > Thanks for your comments. I don't want to reply to all of
>> > >>> > them and make the email completely unreadable so I will try
>> > >>> > to sum up my thoughts and see where we go from there.
>> > >>> >
>> > >>> > I think we have conflicting views of what a 'pure' Lucene.Net
>> > >>> > is and I'd like to make my case more clearly as I cannot
>> > >>> > imagine that you would have a problem with it.
>> > >>> >
>> > >>> > Lucene.Net will always be driven by Lucene as the community
>> > >>> > around Lucene is mature and developing at pace compared to
>> > >>> > Lucene.Net; this is not a criticism, it is a fact of life.
>> > >>> > What I don't understand is how that development is
>> > >>> > progressing - i.e. what features are being added, what
>> > >>> > features are being removed, if performance is being
>> > >>> > improved...... I presume you have a far better understanding
>> > >>> > of those realities.
>> > >>> >
>> > >>> > Now, Lucene.Net is a fully functioning, very performant,
>> > >>> > extremely useful component / library / product. I cannot
>> > >>> > emphasise how important Lucene.Netwas in developing a viable
>> > >>> > search strategy for a project I was working on recently.
>> > >>> > However, I wanted the library to be a .NET 2.0 library; not
>> > >>> > just compiled under .NET 2.0.... I have an aversion to
>> > >>> > ArrayLists, for example, and I'd like them to be replaced
by
>> > >>> > Generic Collections.
>> > >>> >
>> > >>> > So, to achieve these two aims: keeping up with Lucene and
>> > >>> > making Lucene.Netmore .NET 2.0 specific, I think we have to
>> > >>> > prove the process..... By that, I mean we need to take a
>> > >>> > Lucene.Net release - I suggest 2.1 - and branch the codebase.
>> > >>> > What this allows us to do, is to revise the Lucene.Net
>> > >>> > release without affecting Lucene.Net's ability to move
>> > >>> > forward with Lucene enhancements and improvements whilst -
in
>> > >>> > a low risk environment - learn the lessons of making
>> > >>> > Lucene.Net 'purer.'
>> > >>> >
>> > >>> > Does that make sense?
>> > >>> >
>> > >>> > Basically, I am happy with the functionality in Lucene.Net
>> > >>> > just now and I think it would be a good thing to have an
>> > >>> > optimised, purer .NET 2.0 version of the library. I
>> > >>> > understand that the Lucene.Net / Lucene relationship should
>> > >>> > not be broken as Lucene is clearly still developing and we,
>> > >>> > as a community, can gain from this continued development.
>> > >>> > However, I think the community can also gain from the
>> > >>> > development of an optimised for .NET 2.0version of the  
>> library.
>> > >>> >
>> > >>> > That's my thinking. It is what I am truly interested in
>> > >>> > doing. I think the community would respond well to a version
>> > >>> > of Lucene.Net which is optimised for .NET 2.0 and I think
we
>> > >>> > will struggle to do that with Lucene.Net alone as it
>> > >>> > necessarily follows Lucene developments.
>> > >>> >
>> > >>> > Thanks for reading,
>> > >>> > Ciaran
>> > >>> >
>> > >>> > On 03/04/07, George Aroush <george@aroush.net> wrote:
>> > >>> > >
>> > >>> > > Hi Ciaran,
>> > >>> > >
>> > >>> > > Please see my comments below.  Thanks.
>> > >>> > >
>> > >>> > > -- George Aroush
>> > >>> > >
>> > >>> > > > -----Original Message-----
>> > >>> > > > From: Ciaran Roarty [mailto:ciaran.roarty@gmail.com]
>> > >>> > > > Sent: Monday, April 02, 2007 6:44 AM
>> > >>> > > > To: lucene-net-dev@incubator.apache.org
>> > >>> > > > Subject: Lucene.NET Pure [was 'Lucene.Net project
>> > >>> involvement']
>> > >>> > > >
>> > >>> > > > Hi
>> > >>> > > >
>> > >>> > > > I just want to check some facts and see if I have
>> > picked up
>> > >>> the
>> > >>> > > > right emphasis from the majority of the posts.
>> > >>> > > >
>> > >>> > > > Firstly, Lucene.NET 2.1 is due to be released soon.
>> > >>> > >
>> > >>> > > Yes, Lucene.Net 2.1, a first cut release should be out
by
>> > >>> > end of this
>> > >>> > > week or over the coming weekend.  Btw, it's "Lucene.Net"
>> > >>> > and not "Lucene.NET"
>> > >>> > >
>> > >>> > > > Secondly, the port of Lucene to Lucene.NET is not
>> > an automatic
>> > >>> > > > process and George does post-migration work currently
to
>> > >>> > bring the
>> > >>> > > > JLCA work closer to the .NET world.
>> > >>> > > >
>> > >>> > > > Using the Lucene.NET effort, people on this list
have
>> > >>> > gone away and
>> > >>> > > > made the port of Lucene into a purer .NET version.
>> > >>> > > > These changes have, however, stayed internal to
their
>> > >>> > work and they
>> > >>> > > > have not been backported.
>> > >>> > >
>> > >>> > > Are you sure about this?  I have not read anyone saying
>> > >>> this.  What
>> > >>> > > folks have said is that they eliminated unnecessary
>> > >>> exceptions from
>> > >>> > > the Lucene.Net code; exceptions that also exist in the
Java
>> > >>> version
>> > >>> > > and were brought over to C# via the port.  There is a
JIRA
>> > >>> > issue about
>> > >>> > > this and we had a long discussion about it on this mailing
>> > >>> > list some
>> > >>> > > time ago.  The folks on the Java mailing list knew about
it
>> > >>> > and fixed
>> > >>> > > it for 2.1 release.
>> > >>> > >
>> > >>> > > > When I asked the question about getting involved
in the
>> > >>> > project and
>> > >>> > > > making Lucene.NET 'purer' - in a .NET sense - then
there
>> > >>> > appeared to
>> > >>> > > > be a real desire to get involved with that process.
It  
>> was
>> > >>> also
>> > >>> > > > noted that this would need to be a manual process;
I
>> > >>> > suggested that
>> > >>> > > > the next major release - Lucene.NET 2.1 - should
be the
>> > >>> basis for
>> > >>> > > > this work.
>> > >>> > > >
>> > >>> > > > Therefore, I think we should branch the code at
2.1 and
>> > >>> > work on that
>> > >>> > > > branch.
>> > >>> > > > In that way, we do not stop the progress of Lucene.NET
in
>> > >>> > line with
>> > >>> > > > Lucene but we do get to make some .NET optimisations.
>> > >>> > >
>> > >>> > > I disagree about branching off a new baseline.  Like
>> > I said in a
>> > >>> > > previous posting, the first thing we need to do is bring
up
>> > >>> > Lucene.Net
>> > >>> > > to be in part with the code base of what's in the Java
>> > >>> > Lucene SVN with
>> > >>> > > what's in the C# Lucene SVN.  Once we achieve this
>> > important but
>> > >>> > > difficult milestone, and most importantly we prove that
 
>> we can
>> > >>> > > maintain it, then we can start looking at the existing
code
>> > >>> > base and
>> > >>> > > make the code .NET 'purer'.
>> > >>> > >
>> > >>> > > > Lastly, I believe that .NET 2.0 was the preferred
>> > >>> > platform for this
>> > >>> > > > work and that it would be ok to use .NET 2.0 specific
>> > >>> > capabilities.
>> > >>> > >
>> > >>> > > Yes, the work on Lucene.Net 2.1 will be release .NET
2.0
>> > >>> > specific; but
>> > >>> > > again, our first goal must be that we get in par with
 
>> Java's
>> > >>> Lucene
>> > >>> > > SVN before we diverge the code into more .NET.
>> > >>> > >
>> > >>> > > > Does that sound right? Any builds on this? Any problems
>> > >>> with the
>> > >>> > > > approach?
>> > >>> > > >
>> > >>> > > > Thanks in advance,
>> > >>> > > > Ciaran Roarty
>> > >>> > > >
>> > >>> > >
>> > >>> > >
>> > >>> >
>> > >>>
>> > >>>
>> > >>
>> >
>>
>>


Mime
View raw message