lucy-dev 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: [lucy-dev] 0.1-incubating release timeline?
Date Mon, 22 Nov 2010 23:51:51 GMT
+1 to the below, with the exception of implementing the branding requirements. I don't think
that's mandatory for a release...it's really independent of it (though mandatory).

Cheers,
Chris

On Nov 21, 2010, at 5:51 PM, Marvin Humphrey wrote:

> 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:
> 
> Mandatory:
> 
>    * Either resolve <https://issues.apache.org/jira/browse/LEGAL-86>
>      favorably or replace JSON::XS and Parse::RecDescent.
>    * Review other CPAN dependencies (these were enumerated in a comment on
>      LUCY-121 at <http://s.apache.org/kQ>).
>    * Work out release numbering mechanics (Perl version numbers are
>      complicated).
>    * 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.)
> 
> Optional:
> 
>    * 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
> <http://www.rectangular.com/kinosearch/docs/devel/> hangs off the KinoSearch
> homepage.  It's not mandatory because as soon as we upload to CPAN we can
> point people at <http://search.cpan.org/perldoc?Lucy> (see
> <http://search.cpan.org/perldoc?KinoSearch> 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
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
View raw message