lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <>
Subject Re: Revisions to Incubator proposal
Date Fri, 02 Jul 2010 06:44:46 GMT
On Thu, Jul 1, 2010 at 10:08 AM, Marvin Humphrey <> wrote:
> There is a possibility that this proposal won't be accepted.  But if that
> happens, we have a contingency plan: leave Apache, yet continue to operate
> according to many of the same procedures and values, possibly returning with a
> new proposal at some later date.  We should seek to exploit any critiques that
> we receive during the proposal process to help guide us, regardless of the
> outcome -- just as we have attempted to make best use of the Lucene PMC's advice.
> Having slept on the matter, here are some thoughts on the current proposal.
> The first half of the Rationale seems fine...
>    There is great hunger for a search engine library in the mode of Lucene
>    which is accessible from various dynamic languages, and for one accessible
>    from pure C. Individuals naturally wish to code in their language of
>    choice. Organizations which do not have significant Java expertise may not
>    want to support Java strictly for the sake of running a Lucene instance.
>    Native applications can be launched much more quickly than JVMs. Lucy will
>    meet all these demands.

I like this, but might stop after the first two sentences.  I think
they're the stronger reasons.  If you wanted to go further, I'd
mention the ways in which C has traditionally been the language of
Unix server programming, and allows one to take full advantage of the
machine's potential.

I think this is essentially what made Apache a great web server:  a
brilliant architecture combined with the clarity of C.  Can you
picture writing mod_php, mod_perl, or mod_python in Java?  It's
certainly not the only way to go, but fills a niche that Lucene never

>    We acknowledge that Apache seems like a natural home for Lucy given that
>    it is also the home of Lucene, and speculate that this may have been on
>    the minds of the Lucene PMC when Lucy was green-lighted as a sub-project.
>    More importantly, though, the Lucy development community strongly believes
>    that The Apache Way is right for Lucy.

I agree that this part is somewhat weak. And while I really like
Apache, I'm not sure it's the only way for Lucy.  For example, I also
really like the SQLite way.  While Lucy certainly can take advantage
of the Apache infrastructure, I'm not sure it really needs it.  What
it needs is more people writing code for it, and the best way to
achieve this is probably to get more technically proficient users.
If the code is clear (which it is) and the architecture is graspable
(needs improvement?) some significant percentage of these users will

> The one thing I don't think we've done well (and this is my fault) is handle
> releases and backwards compatibility.  Father Chrysostomos put in an awful lot
> of work creating a subclassable Highlighter, but later releases of KS broke
> back compat on him.  Nevertheless, I think we have learned from how that
> played out, and that the backwards compatibility policy we arrived at last
> year goes a long way towards solving those problems.

I think you're doing fine on backwards compatibility, and if anything
you're spending too much time on it.  Instead of worrying about not
breaking things that are old, spend the effort making it easier to
write things that are new.

Let's make the dogfood tasty, and start writing 'extensions' instead
of trying to include everything in core.  If it's easy enough and
useful enough, someone will port the old to the new.  In fact, that
would be an excellent project for a beginner to familiarize themselves
with the code base.

> Lastly, it would be nice to cover our contingency plan of growing the
> community and coming back with a bigger committer list at some later date.
> However, I think that may arise naturally during the discussion, and it's
> probably too big a topic to squeeze in.

I don't know if you need to discuss this.  And once we have more
developers, do we really need to come back?   I mean, I really like
Apache, but Trac plus taking the best points of the Incubator approach
might offer 90% of the benefit with a lot less overhead.  Which
doesn't mean Lucy wouldn't benefit from being included, but I wouldn't
precommit to returning at a later date if they don't want us.


View raw message