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)
From: "Mattmann, Chris A (388J)" <chris.a.mattmann@jpl.nasa.gov>
To: "lucy-dev@lucene.apache.org" <lucy-dev@lucene.apache.org>
Date: Fri, 30 Jul 2010 21:38:06 -0700
Subject: Re: [Lucy] Roadmap for first release
Thread-Topic: [Lucy] Roadmap for first release
Thread-Index: AcswCCj+P11ZD6fxSXmQnk5c4rhZqQAYgI4L
Message-ID: <C878F6BE.1A0F5%Chris.A.Mattmann@jpl.nasa.gov>
In-Reply-To: <20100730165558.GB10908@rectangular.com>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Marvin,

Yeah, my big concern is that you=B9re talking about a project that doesn=B9=
t
live at Apache (yet) on Apache lists. I like your timeline below, but there
are no dates behind them? How long does it take to cut a 0.31 Kinosearch
release? My hope is a few days, not a few weeks. We have Incubator reports
to file over here in Apache-land (in a few weeks), and those reports need
*Apache* milestones -- not milestones from a project that isn't at Apache.
This dualism has to stop and the development/mailing list discussion/releas=
e
cycle needs to occur over here at Apache.

Cheers,
Chris


On 7/30/10 9:55 AM, "Marvin Humphrey" <marvin@rectangular.com> wrote:

> On Thu, Jul 29, 2010 at 08:31:27PM -0700, Mattmann, Chris A (388J) wrote:
>> Thanks, Peter for the email. I kind of guessed it was more related to
>> KinoSearch.
>=20
> Since Lucy is about to assimilate the KinoSearch code base, they are now
> effectively the same project.  I was perusing the early days of the
> SpamAssassin dev mailing list today to get a feel for how our code import
> would go, and I found a thread called "Where to fix the stable branch":
>=20
>     http://markmail.org/message/e5avbm6z2pldv55u
>   =20
> It addressed the problem of making a last bugfix release on GPL'd code in=
 the
> 2.6 branch, when there was CLA'd code at Apache for 2.7+.  I think the
> situation is analogous, and that like SpamAssassin, we will move on and l=
eave
> the issue behind with time.
>=20
>> I think it would be good to keep the discussions focused on Apache over
>> here, even though I'm aware of the transition as part of the podling.
>=20
> I appreciate you're keeping our eyes on the prize.  I agree that completi=
ng
> the transition as soon as possible is very important.  Frankly, nobody wa=
nts
> this dualism to end more than I do.
>=20
> For me, this is mostly about compromise and community.  Peter is an impor=
tant
> contributor.  Father Chrysostomos is an important contributor.  I want th=
em to
> feel that the KinoSearch community appreciated the extensions that they w=
rote
> and supported them.  My preferred mechanism for that would have been to f=
ork
> off Lucy1 and provide them with patches for their extensions to work with=
in
> that namespace.  But Peter, at least, feels very strongly that we ought t=
o do
> a "KinoSearch" release.  I'm -0.1 on the idea, but I don't think the
> consequences will be severe, and I want Peter to feel like a stakeholder.
>=20
> Here's the roadmap as I see things now:
>=20
>     KinoSearch 0.30_11
>         * Misc Bugfixes.
>         * Move some classes around.
>     KinoSearch 0.31
>         * KS 0.30_11 with a version number increment.
>     Lucy 0.1
>         * KS 0.31 with a new namespace, new license, and a new home.
>     Lucy 0.2
>         * Introduce numeric field types.
>     Lucy1 1.0
>         * Forked from Lucy 0.2.x once things setle down.
>=20
> The only significant change of plans here is the insertion of KinoSearch =
0.31
> into the roadmap.  The changes that will go into KS 0.30_11 are the same =
as
> what we would have done anyway, and I believe the discussions about those
> belong here, as they will directly impact the API of Lucy 0.1.  For examp=
le,
> I'm about to propose moving all of our Analyzers out of core, like Lucene=
 has.
> I don't think that discussion should take place on the KS list.
>=20
> I also believe that potential Mentor impatience will help keep us from ge=
tting
> sidetracked and spending too much time on pre-transition changes.  :)
>=20
> Marvin Humphrey
>=20
>=20


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