Mailing-List: contact lucy-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Fri, 23 Jul 2010 13:27:27 -0700
To: lucy-dev@lucene.apache.org
Subject: Re: [Lucy] Roadmap for first release
Message-ID: <20100723202727.GB17473@rectangular.com>
References: <20100718175940.GA22940@rectangular.com>
 <4C49BCBA.9080107@peknet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C49BCBA.9080107@peknet.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Marvin Humphrey <marvin@rectangular.com>

On Fri, Jul 23, 2010 at 11:00:58AM -0500, Peter Karman wrote:
> those all sound good for Lucy. Should not impede the KS3 release though. I
> imagine Lucy1 as an improvement on KS3, inspiring users to migrate.

Forking and releasing KS3 is not a huge development burden in the grand scheme
of things, but I'm not sure it's wise from a marketing perspective.  Do we
really want to introduce this codebase under the name KinoSearch3 and then
deprecate it right away?  Wouldn't that be confusing to our users?  What if
we're lucky enough to get some press, articles get written about KinoSearch3,
users subscribe to the KinoSearch mailing list, and links get pointed at
rectangular.com?  Won't we be diffusing some of that goodwill by trying to
redirect it towards Lucy later?  Would all of those prospective KinoSearch3
users be turned off by its imminent deprecation and be less enthusiastic about
adopting it in the first place?  Would we be squandering our big feature
rollout of mmap-powered near-real-time search by bundling it with a
soon-to-be-deprecated library, making Lucy's release less momentous?

As far as I can see, the only advantage KinoSearch3 has over Lucy1 is that it
could happen slightly sooner.  A KinoSearch3 release won't automatically help
people like Father Chrysostomos and yourself who have released extensions --
you'll have to adapt your existing distros to a new namespace regardless, and
"KinoSearch3" doesn't seem to offer any compelling advantages over "Lucy1".
In fact, from Lucy's perspective, it's a negative to have the developer
community fractured and supporting incompatible extensions.

Is there something I haven't thought of?  Is there some reason other than
timing that you want to see a KinoSearch3 release?

>From my perspective, the sooner that KinoSearch gets EOL'd and we can focus on
Lucy development in earnest, the better.  I wouldn't mind having some extra
pressure to release Lucy1 ASAP because we didn't release KinoSearch3.  :)

Marvin Humphrey