incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] 0.1-incubating release timeline?
Date Mon, 22 Nov 2010 01:51:32 GMT
On Sun, Nov 21, 2010 at 09:55:43AM -0800, Mattmann, Chris A (388J) wrote:
> Hey Guys,
> I may be way off here, but it seems like:
> 1. the code has been ported to ASLv2
> 2. the Software Grant is in place
> 3. issues are getting resolved and work is being done

Sounds like we need a TODO list.  Here's what I can think of:


    * Either resolve <>
      favorably or replace JSON::XS and Parse::RecDescent.
    * Review other CPAN dependencies (these were enumerated in a comment on
      LUCY-121 at <>).
    * Work out release numbering mechanics (Perl version numbers are
    * Fully implement ASF branding requirements.  
    * Tighten up the code base a bit.  (Ensure that the "test_valgrind" build
      target passes, fix a couple portability issues, etc.)
    * Adapt the "dist" build target for Apache release.  (Right now it targets
      a CPAN release and has a few other problems.)
    * Establish a "rat" build target so that we can demonstrate to any
      interested Incubator PMC member that we have accounted for the licensing
      of all files.  (Otherwise RAT will flag our sample US constitution
      files, the Snowball C files, etc.)


    * Publish HTML export of documentation on website.
    * Migrate website to new Apache CMS.
    * Work out TextType/FullTextType/StringType refactor. 
    * Move some classes around (all Analyzers underneath LucyX?  Nothing under
      LucyX?  Factor SnowballStopalizer out of Stopalizer?)

It would be nice to have docs hanging off of our homepage, the way that
<> hangs off the KinoSearch
homepage.  It's not mandatory because as soon as we upload to CPAN we can
point people at <> (see
<> for reference.)  However, I do
believe that an inviting, clean web presence is an important recruitment tool,
and I would like to at least revisit the website prior to release.

The refactoring isn't mandatory because of our unstable trunk policy.  It's a
nice-to-have because if we get to it before initial release there would never
be any mindspace occupied by FullTextType and StringType within the
Lucyverse... but we can put off such things for now.

> That said, how far are we off from a 0.1-incubating release? Would it be
> fair to say within a month? 

If LEGAL-86 gets resolved favorably and we can continue to use JSON::XS and
Parse::RecDescent, then yes.  If we have to replace them, probably not.

I thought LEGAL-86 was pretty much a gimme -- I'm under the impression that
other Apache projects have specified Perl-licensed CPAN prerequisites as
system dependencies, which is what LEGAL-86 formally requests.  Since it has
gone unresolved, though, I've started working up replacement components based
on the Lemon parser generator.

We'll have to ditch JSON::XS eventually anyway, since no other host language
binding will be able to use it.  However, I would prefer to address replacing
it after the 0.1-incubating release, since it's known and stable and I'm not
in a hurry to muck with something that Just Works.

Parse::RecDescent is a build-time-only dependency -- it's needed by
Clownfish::Parser.  (It is also referenced in a Cookbook recipe which we can
zap if need be.)  Since Clownfish generates platform-independent C code, we
have the option of shipping the autogenerated C files and omitting Clownfish
-- working around the Parse::RecDescent dependency.  However, my preference
would be to ship Clownfish.

> I think if that's the case, I can help clean up JIRA and get stuff organized
> for a release. I'd even volunteer to be the release manager if someone
> trained me on how to build, test and package up the system.
Peter and I should probably start a ReleaseTODO wiki page, like most Apache
projects seem to have.

The release manager will need enough Perl-fu to install a couple CPAN
prerequisites and will need to be on a Unixy OS for now.  Lucy should build
and test fine for them.  From my perspective, the difficulties in preparing
our first release all have to do with unfamilar Apache rituals.  The packaging
should be handled seamlessly by the "dist" build target once it is repaired
and adapted, so the RM will not have a lot to do there.

Marvin Humphrey

View raw message