[KinoSearch] Bundling KinoSearch

[Marvin Humphrey]

On Sat, Jun 20, 2009 at 04:13:06PM -0700, Robert Krimen wrote:
> Thanks for working on KinoSearch, it looks really promising.
> 
> Unfortunately in its current form, it's hard to distribute (being a
> developer release). To address this, I've put together Search::Kino03:
> 
>         http://github.com/robertkrimen/Search-Kino03/tree/master

Robert,

Yikes, you got out in front of me, here.  When I responded to your private
email suggesting that we discuss this on-list, I expected to have the
discussion before you went and did any work.  And I'll wager it was more work
than you were expecting, given KinoSearch's size and complex build 
process...

I'm sorry, but I would really prefer that you not rebadge a KinoSearch dev
release as a stable release.  That's misleading and unfair to users, and it
threatens to drain my time as well.  I'm extremely pressed right now and while
I can make time for the support burden of a dev release, that's all I can
budget for.

There are a number of features that I absolutely have to finish for my
employer ASAP -- numeric FieldTypes, the last bits to finish off real time
indexing, PFOR posting format, split file posting formats, better scalability
in the SortWriter.  I'm planning on releasing rapid-fire updates for 0.30_xx
as those get implemented -- however, some of them don't uphold the backwards
compatibility promises you're making, because they break both the API and file
format.

Now, what happens once KS svn trunk has drifted out of sync with your distro,
and then we need a crucial bug fix?  The patch from trunk doesn't apply, so we
need someone to prepare a patch specially for your distro.  Until you have a
track record demonstrating both solid C chops and an intimate understanding of
this large project, I have to assume that it will either be me preparing that
patch or nobody.  I suppose I'll end up throwing up my hands and chanting
"unsupported, unsupported", but now I'm counting on people not to start
associating KinoSearch proper with buggy behavior in an unauthorized fork.

> The dist is locked to the KinoSearch 0.3 API/format, and will only get bug
> fixes and feature updates as appropiate.

You've assumed that the 0.30_xx file format is static.  The 0.20_xx format
wasn't static, and people were forced to regenerate their indexes between some
of the 0.20_xx releases.  The same thing is going to be true for 0.30_xx.  The
only people who should be using dev releases are people who can afford to mod
their code and regenerate their indexes on upgrading if necessary.

KinoSearch comes under a GPL/Artistic license, so you have the right to fork
it if you wish.  I can't contribute my stamp of approval or support your
users, though.

I would really prefer to work with you as I have with other collaborators, but
your particular need -- stability -- seemingly makes that infeasible.  That's
unfortunate, because you seem to possess both energy and initiative.

Regards, 

Marvin Humphrey