lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Revisions to Incubator proposal
Date Fri, 02 Jul 2010 16:36:23 GMT
On Thu, Jul 01, 2010 at 11:44:46PM -0700, Nathan Kurz wrote:
> >    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.

OK, I went with this for today:

  Developers may want to take advantage of C's interoperability and
  fine-grained control. 

I do think it's important to at least touch on the advantages of natively
compiled code in the Rationale, and not limit ourselves to the
language-loyalty angle.

> While Lucy certainly can take advantage of the Apache infrastructure, I'm
> not sure it really needs it.  

Acknowledged.  However, the more successful Lucy gets, the more useful it is
to have the support systems and institutions of Apache protecting it and
instilling confidence.  And it's not just about backups, uptime, and fending
off crackers -- it's things like stable governance, legal protection
mechanisms, encouraging contributions from developers sponsored by major
corporations, and so on.

> 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.

I agree.  That is our most pressing need, so we should prioritize accordingly.

> 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.

I believe that the new backwards compatibility policy properly privileges
active developers, while still offering strong stability guarantees to those
who require them.  It's not perfect, but I think it strikes a good balance.  

> Let's make the dogfood tasty, and start writing 'extensions' instead
> of trying to include everything in core.  

A public C API will facilitate extensions.  Had one been available,
ProximityQuery would have been written to be a separate CPAN distro.

I think separating ProximityQuery from core would be a good concrete goal to
help us focus while we design the C API.

> 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.

Your response helps to clarify the point that I really wanted to get in there,
which is that a long overdue release is imminent.  That's now covered in the
revised Community section.

OK, I only made that one minor content change, so I think we have adequate
consensus.  I'm going to perform a QA pass and maybe tweak some phrasings so
that the word "community" doesn't appear eleventy-billion times.  Then I'll
send it off to general@lucene.

Thanks, folks -- this has worked out well!

Marvin Humphrey

View raw message