lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <gsing...@apache.org>
Subject Re: [DISCUSS] Archive Lucy
Date Mon, 09 Mar 2009 01:14:47 GMT
Boy, I wish I had said it this well, Hoss.  +1.

I totally agree.  I very much respect what Marvin is doing with KS and  
the contributions to Lucene he has made and I'm definitely not trying  
to cast out the  people who feel strongly about a C-based search  
library.  I just know that Lucy doesn't meet the standard of what an  
Apache project should be and it has been given ample time to become  
that.   It is very much a tough thing for me to even suggest, because  
I know how much Marvin cares about it and I'd be happy to see a port  
of Lucene in every programming language there is if it is useful to  
people.

However, as PMC chair, I've had to fill out the board reports for a  
good while now with what amounts to "Lucy: No activity to report" (at  
best it says "minimal activity"), see [1], [2], [3], [4] and [5] (and  
I could probably keep going, see http://www.apache.org/foundation/board/calendar.html) 
.  In fact, in [2] (Sept. '08), the report was:

"LUCY

Lucy will develop a shared C-based core for ports of Lucene to other
languages, such as Perl, Python and Ruby.  No progress has been made
this quarter, but we have been in contact with the committers and
they are still interested in the project and plan to be more
active in the near future."

So, it is not like my concern (or other that of other PMC members) is  
all of a sudden news.
However, since September, little has happened since the PMC contacted  
Dave and Marvin (Doug was obviously contacted since he's a member of  
the PMC, and that accounts for all the committers).

 From http://svn.apache.org/viewvc/lucene/lucy/, there hasn't been a  
commit in 6 months.  The website itself is still showing only the  
original news item announcing the project back in 2006.  Since Sept of  
'08, there has been a sum total of 39 messages on the mailing list.   
While it is clear Marvin very much has some notion of Lucy alive  
somewhere, it is, unfortunately, not alive at Apache.

However, what about some type of interim probation, for lack of a  
better word?  Marvin and Nathan (and whoever else), how about putting  
forth a plan for going forward with some reasonable milestones that we  
can all point to and see the progress?  And don't feel like it has to  
be some huge leap, either.   While this may seem like it is just  
"jumping through hoops", I don't think it is.  Lucy will never attract  
other developers if all the discussion of how to implement Lucy takes  
place on the KS and Lucene Java mailing lists.

Hope this helps,
Grant

[1] http://www.apache.org/foundation/records/minutes/2008/board_minutes_2008_12_17.txt
[2] http://www.apache.org/foundation/records/minutes/2008/board_minutes_2008_09_17.txt
[3] http://www.apache.org/foundation/records/minutes/2008/board_minutes_2008_06_25.txt
[4] http://www.apache.org/foundation/records/minutes/2008/board_minutes_2008_03_19.txt
[5] http://www.apache.org/foundation/records/minutes/2007/board_minutes_2007_12_19.txt






On Mar 8, 2009, at 6:17 PM, Chris Hostetter wrote:

>
> : It *is* actively progressing.  It's just that neither you nor  
> Grant are
> : willing to acknowledge that any of the design work I just did (in  
> happy
> : collaboration with Java Lucene devs) applies to Lucy.
>
> I don't really believe that's a fair characterization of the  
> comments made
> in this thread.
>
> The fundemental issue is really wether Lucy, as a project, is "alive".
>
> This is not about wether progress is being made towards a good C  
> Library
> for search, or wether there have been good design discussions to  
> further
> that goal, or wether there has been good collaboration amongst various
> people towrds common goals that can be implimented in multiple  
> projects --
> the answers to all of those questions may be "yes" (and i genuinely
> believe that they are) but that doesn't mean that Lucy, as a  
> project, is
> alive.
>
> : The proposal remains sound, and there is a deep hunger out there  
> for a solid C
> : IR library similar to Lucene.  The KS-then-Lucy progression is the  
> fastest and
> : best way to get there.
>
> Marvin, I respect your opinion.  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.
>
> : >From my perspective, what we have is an optics problem.  I'm  
> working full
> : time, and I've been plenty active in the Lucene forums, but you  
> and Grant only
> : see a big fat zero.  :(
>
> At this point (from my perspective) Lucy as a project is not  
> "alive" ...
> that doesn't mean i don't respect your participation in Lucene as a  
> whole,
> and I do recognize that you've been making a lot of progress; but  
> one man
> isn't a community, and KS isn't Lucy.  I don't see a zero, I see a  
> large
> blank area that can be filled later, but for now it confuses people.
>
> It seems to me that (to borrow a cliche) Lucy was an idea ahead of  
> it's
> time, so we should be honest to the world (and ourselves) about the  
> state
> of things. If people want to work on a project developing a C search
> library with bindings for dynamic langauges let's not frustrate them  
> with
> a 3 year old website, and ghost town mailing lists and code base --
> instead let's encourage and promote groth in the internals of  
> KinoSearch,
> so that at a future point we can revive the Lucy project, with a  
> healthy
> developer community.
>
> This discussion isn't about "killing" a project -- it's not an  
> execution
> -- it's about acknowledge that Lucy hasn't really been born yet.
>
>
>
> -Hoss
>


Mime
View raw message