lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <chris.a.mattm...@jpl.nasa.gov>
Subject Re: Draft proposal: Move Lucy to Incubator
Date Sun, 04 Jul 2010 20:40:37 GMT
Hi Marvin,

Yep I think you're in good shape. +1 to submit to the Incubator. My comment was mainly, once
the proposal arrives over there, I expect Incubator folks to jump in and try and help out
either via mentorship, or as a committer. I'm already mentoring 2 podlings right now, else
I'd jump in, but I don't really have many spare cycles. I'll snoop around on the lists though
and if I get time later on, perhaps I can jump in and help.

Best of luck!

Cheers,
Chris



On 7/4/10 11:44 AM, "Marvin Humphrey" <marvin@rectangular.com> wrote:

On Fri, Jul 02, 2010 at 10:29:45AM -0700, Mattmann, Chris A (388J) wrote:
> +1, Marvin. My only comment is that you can hopefully add some additional
> committers when you move into the Incubator to really kick start the
> project.

Thanks, Chris.

Another possibility for us is to delay entry into the Incubator until we have
accumulated a larger number of committers.

To achieve this, we would make our stable release ASAP under the current
KinoSearch namespace and license.  We expect to generate significant interest
within the Perl community with this release, attracting many new users.  If
the past is prologue, these users will soon start contributing, and we'll be
able to identify and develop some candidates who subsequently become
committers.  Then we would be able to put our proposal to the Incubator PMC
with more names on the list.

However, that's not my preferred course of action for a number of reasons.

First, I believe that it's in the best interests of the project to launch the
modern codebase under the Lucy brand.  Making a release under the KinoSearch
brand and then switching to Lucy shortly thereafter will be confusing and
inconvenient for our users.

Second, the more contributors we have, the more complicated the relicensing
and software grant becomes.  We have all the necessary past contributors on
board now.  In a worst case scenario, one or more of those individuals becomes
unable to participate while we delay.

Third, accumulating worthy committers will take time, and it's not clear how
much.

Fourth, I think it would be good for the project if the release happens while
Lucy is in the Incubator under the guidance of Mentors.  We have received some
thoughtful advice on this general@ list lately.  Having Mentors available to
provide us with ongoing feedback during this phase of expansion will help us
to run as efficiently and effectively as possible, establishing healthy
cultural norms within the community that persist for years to come.

Our chief challenge is now identifying a Champion and three Mentors.  If we
can do that and pass an Incubator PMC vote, I believe that Lucy's future is
extremely bright.

We have solved the technical problems that Dave Balmain and I set out to
solve.  We have a product that delivers great features like mmap-powered
near-real-time search, and offers mechanisms for extension which will entice
users to become contributors.  We have the institutions, infrastructure, and
accumulated wisdom of Apache pushing us forward, particularly the traditions
of the Lucene community where Lucy was born.  And we have a collectively
devised proposal which incorporates lessons learned from past mistakes, and
which we are all very excited about.

Marvin Humphrey




++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: Chris.Mattmann@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message