lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [DISCUSS] Archive Lucy
Date Mon, 09 Mar 2009 19:48:51 GMT
Hoss:

> The fundemental issue is really wether Lucy, as a project, is "alive".

There is one extremely active participant, and as this thread attests, there
is both a small community and demand for the product.  Futhermore, the work
that is being done to move Lucy forward is benefitting Java Lucene.

In my view, the amount of raw activity dedicated to advancing Lucy clearly
exceeds the threshold that would justify a mothballing.  It's not abandoned.
Things are moving more slowly than they would if Balmain were actively
contributing, but *plenty* of important work is being accomplished.
Nevertheless, I understand why the project has an appearance of dormancy --
please see my reply to Jukka for an explanation.

It is my belief that the most useful thing we can do for Lucy right now is to
release an API-stable library that implements some extensibility enhancements
that further Lucy's high-level mission of empowering the users of its
bindings, and study how those enhancements perform in the real world.  To
reach this goal as quickly as possible, I have performed a torso transplant on
KinoSearch -- arguably to KinoSearch's *detriment* as a CPAN module, since the
massive code churn has introduced bugs (e.g. the Highlighter broke) and
siphoned dev time away from other priorities.  It's true that "KS isn't Lucy",
but my top priority is Lucy, not KS.

Additionally, rather than foster discussion within Lucy forums, I went abroad,
and without my voice as a catalyst, the forums stagnated.  I calculated that
contributing to other lucene.apache.org forums would suffice.  This was
an error.

To remedy the situation, the main thing we need to figure out is how to move
the extensibility prototyping work under the ASF umbrella.  If those commits
had been flowing into the Lucy repository, we wouldn't be having this
conversation.  

Incubating KinoSearch is one possible approach, but the point is to advance
Lucy, not bless KinoSearch.  Is that really the right way to go?

> If you believe that the best long term strategy towards making Lucy into a
> solid project is to first focus on KinoSearch, then I have faith in your
> judgement -- but from my perspective, that seems like a strong argument in
> favor of archiving Lucy at this time and reviving it at a future date when
> you feel the time is right to bring he apprpriate code from KS into the
> apache fold via software grant.

The point of focusing on something named "KinoSearch" in the short term is to
test an API-stable release which implements Lucy extensibility enhancements
without spoiling the "Lucy" namespace.  The API stability is important because
it allows people to migrate on their own schedule from "KinoSearch" to "Lucy"
and gives them the confidence that their elaborate extensions won't suddenly
get blasted by a "Lucy 2.0" core update that breaks backwards compatibility.

If sane versioning was supported by all of Lucy's target platforms, this
two-step maneuver wouldn't be necessary: we could release a short-lived Lucy
1.0, then follow it up with a solid Lucy 2.0.  Unfortunately, that's not the
case, so I think it makes sense to hijack KS and use it as a vehicle.

Marvin Humphrey


Mime
View raw message