lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: [Lucy] Roadmap for first release
Date Sat, 31 Jul 2010 04:38:06 GMT
Hi Marvin,

Yeah, my big concern is that you¹re talking about a project that doesn¹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/release
cycle needs to occur over here at Apache.


On 7/30/10 9:55 AM, "Marvin Humphrey" <> 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.
> 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":
> 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 leave
> the issue behind with time.
>> 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.
> I appreciate you're keeping our eyes on the prize.  I agree that completing
> the transition as soon as possible is very important.  Frankly, nobody wants
> this dualism to end more than I do.
> For me, this is mostly about compromise and community.  Peter is an important
> contributor.  Father Chrysostomos is an important contributor.  I want them to
> feel that the KinoSearch community appreciated the extensions that they wrote
> and supported them.  My preferred mechanism for that would have been to fork
> off Lucy1 and provide them with patches for their extensions to work within
> that namespace.  But Peter, at least, feels very strongly that we ought to 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.
> Here's the roadmap as I see things now:
>     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.
> 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 example,
> 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.
> I also believe that potential Mentor impatience will help keep us from getting
> sidetracked and spending too much time on pre-transition changes.  :)
> Marvin Humphrey

Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA

View raw message