Rory,
We'd love to have your contributions! Any time you can spend on it will be
deeply appreciated.
Also, I understand your skepticism, and I agree that this is a significant
concern.
Unfortunately, that's kind of the best we can do. It's the most fair way to
set project priorities; "Whoever contributes the most wins". This is, in one
sense, the basis of Apache's meritocracy (though many would probably
disagree with that characterization). Actions speak louder than words. We
cannot please everyone, and we cannot arbitrarily decide a direction to go
in and force others to contribute to that vision. We can discuss and be open
about all possibilities, but the contributions are the real force behind the
project direction.
We encourage anyone, from whatever perspective or opinion they may hold, to
*write the code* and submit it for inclusion. If the code looks good, works,
and we can generally agree as a PMC that we should use it, we'll commit it.
That is how the project direction will be shaped.
This is fair, because while we might say that "a lot of people want a
line-by-line port" or we might say that "a lot of people want a .NET
idiomatic port" and those people might vocalize that on the mailing lists,
in the end it's "Who is willing to write code and contribute it to the
project?" which determines the shape of the code base. If there really are a
lot or people on either side of a particular opinion, they will manifest
themselves by writing and contributing (or convincing others to do so) and
thus shaping the project.
Right now, we don't have enough contributions from either side of that
discussion to prove that there is a "strong interest" in either one. We have
generally agreed to "depart from Java", but have not yet discussed the form
of that, or to what degree we want to diverge. That means it's open to
interpretation, discussion, and suggestions. No one has submitted a huge
.NET style re-write, or even seriously discussed what that sufficiently that
someone could take action on it. DIGY, who is our most active contributor,
seems most comfortable (at the moment) with maintaining and improving a
"mostly line-by-line" port. Other than that, we have had relatively few
contributions to the core library.
It could be said that this is a result of a lack of vision or direction from
the committers who are organizing the project, but really, it's not for us
to decide what the community wants. Rather, the community tells us what it
wants by voting with their submitted patches.
Take myself for example... I really, really want to move to a very modern,
.NET idiomatic, fluent, LINQ enabled API, with everything based around
interfaces, generics, injected behaviours using Action/Func<T>, all data
streamable, and all memory correctly freed, everything threadsafe, etc. I
bet there are a lot of people like me out there. However, even though I
would really LIKE it to be that way, I have neither written, nor contributed
code that makes that happen, nor effectively convinced/organized others to
help write it. This is proven by the lack of submitted patches... (well,
Chris Currens' streaming contributions are marginally my fault, since I'm
his boss at work and encouraged/enabled him to work on it on the clock, and
discussed the design and implementation details which helped him to write
it, but I personally didn't write any of that code, and it's mostly his
design and personal passion that made it happen). So, when I actually sit
down and write the code for what I want Lucene.Net to be, or sit down and
write the emails to get other people fired up enough to take action, that's
when my opinion becomes influential to the project.
At the end of the day, what is important is to let the community know that
contributions and discussions of ALL KINDS are welcome. We don't want anyone
to say, "Well, I would help out Lucene.Net, but they are going a different
direction than I want to go, so I'll just keep my changes to myself" (or
worse, just not write any code at all).
In my opinion, we should be using our energy and brainpower to discuss how
we can achieve "this AND that" vs arguing over whether we should do "this OR
that". When you write your patches, try to think of how you can implement
something to support both. We don't need two side-by-side code bases, but
rather one code base that supports all major use cases. This is not easy to
do, but it's almost always possible.
We are a bunch of smart and talented folks. We can do it. It'll be awesome.
Thanks,
Troy
On Wed, Jun 29, 2011 at 5:47 PM, Rory Plaire <codekai...@gmail.com> wrote:
> Of course I'd love to contribute. I'm hopeful I can spend even a few hours
> a
> week doing this when (if...) my people adopt NHibernate.Search.
>
> Troy, I'm going to defer to your sense that there is enough interest and
> support from the community to maintain both code bases. It is hard,
> however,
> to restrain my skepticism, which I relate in order to record a sort of
> warning to consider. In a perfect world two code-bases could live
> side-by-side and even benefit each other. In practice, however, I'm
> doubtful
> that this can be symbiotic relationship. If people contribute more to one
> than another, it creates an unhealthy uncertainty about the state of the
> project. It also splits any potential future project resources who may be
> ambivalent about translation vs. transliteration. Open source projects are
> often fragile, and it's hard for me to keep from worrying if there would
> need to be a sacrifice at some point to keep the project concentrated
> enough
> to remain viable. While the model of open source is such that *anyone* can
> contribute, this very mechanism can also lead to projects that are pulled
> back and forth among contributor needs and interests, adding complexity and
> instability which ultimately doom them.
>
> -r
> On Wed, Jun 29, 2011 at 3:47 PM, Troy Howard <thowar...@gmail.com> wrote:
>
> > I pretty much agree with Rory.
> >
> > And as others have said, this issue has been discussed many times. What
> is
> > most important about the fact that it has been discussed many times is
> that
> > it has not been resolve, even though it has been discussed so many times.
> >
> > That means that the both the developer community that contributes to the
> > project and the user community that uses the library have an interest in
> > *both*. I think we have enough interest and support from the community to
> > develop both of these at the same time.
> >
> > Some key points:
> > - Being a useful index/search library is the goal of any implementation
> of
> > Lucene. Being useful is more important than being identical to one
> another.
> > Don't forget that Java Lucene has bugs, design problems, and may not
> always
> > be the best implementation of Lucene.
> > - Unit tests should validate the code's "correctness" in terms of
> > functionality/bugs
> > - The library can contain multiple APIs for the same tasks. Fluent? LINQ?
> > Just Like Java? Just like pylucene? All of the above?
> > - Implementation details between .NET and Java are *very* significant and
> > often account for a lot of the bugs that are Lucene.Net only. Our attempt
> > to
> > be a "line-by-line" port is what is introducing bugs, not the the other
> way
> > around
> > - The only reason we are having this discussion is because C# and Java
> are
> > very similar languages. If this was a F# port or a VB.NET port, we
> > wouldn't
> > even be discussing this. Instead we'd say "make it work the way that
> makes
> > the most sense in {{insert language here}}".
> >
> >
> > That said, DIGY has a very good point. Continued development on the
> library
> > is the most important part of the project's goals. A dead project helps
> no
> > one. If the current active contributors are writing a line-by-line port,
> > then that's what it will be. If they are writing a complete re-write,
> then
> > that is what it will be. Some might find it easier to write line-by-line,
> > but others might find that task daunting. The opposite is also true. It
> > depends on the person, how much time they have, and what they consider
> > "easy" or "manageable" or "worth doing".
> >
> > As always, if you want the code base to be something specific, submit a
> > patch for that, and it will be. If not, then you need to convince someone
> > else to write that patch. And just so it's clear, *anyone* can write and
> > submit a patch and be a contributor, not just the project committers.
> >
> > Thanks,
> > Troy
> >
> > On Wed, Jun 29, 2011 at 3:06 PM, Rory Plaire <codekai...@gmail.com>
> wrote:
> >
> > > For what it's worth, I've participated in a number of projects which
> have
> > > been "ported" from Java to .Net with varying levels of "translation"
> into
> > > the native style and functionalty of the .Net framework. The largest
> are
> > > NTS, a JTS port and NHibernate, a Java Hibernate port. My experience is
> > > that
> > > a line-by-line port isn't as valuable as people would imagine.
> > >
> > > Even if we discount the reality that a line-by-line port is really
> > > unachievable due to various differences between the frameworks, keeping
> > > even
> > > identical code in sync will always take some work: full automation on
> > this
> > > large of a project is infeasible. During manual effort, therefore,
> making
> > > readable changes to the code is really not that much more work.
> > >
> > > For update maintenance, porting over code from recent versions of both
> > > projects to the .Net versions, and ".Nettifying" that code is little
> > > trouble. Since both projects use source control, it's easy to see the
> > > changes and translate them.
> > >
> > > When it comes to debugging issues, in NTS or NHibernate, I go to the
> Java
> > > sources, and even if the classes were largely rewritten to take
> advantage
> > > of
> > > IEnumerable or generics or structures, running unit tests, tracing the
> > > code,
> > > and seeing the output of each has always been straightforward.
> > >
> > > Since I'm using .Net, I'd want the Lucene.Net project to be more .Net
> > than
> > > a
> > > line-by-line port of Java, in order to take advantage of the Framework
> as
> > > well as provide a better code base for .Net developers to maintain. If
> > > large
> > > .Net projects ported from Java do this, and have found considerable
> > > success,
> > > it is, in my view, a well-proven practice and shouldn't be avoided due
> to
> > > uncertainty of how the resulting code should work. Ultimately, that is
> > what
> > > unit tests are for, anyway.
> > >
> >
>
