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
