You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> on 2010/11/21 18:55:43 UTC
[lucy-dev] 0.1-incubating release timeline?
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
That said, how far are we off from a 0.1-incubating release? Would it be fair to say within a month? 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.
A first Apache release will go a *long* way towards building a community here at Apache. Let's see if we can make it happen!
Cheers,
Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] 0.1-incubating release timeline?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
+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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] 0.1-incubating release timeline?
Posted by Peter Karman <ka...@peknet.com>.
Marvin Humphrey wrote on 11/21/10 7:51 PM:
> Peter and I should probably start a ReleaseTODO wiki page, like most Apache
> projects seem to have.
>
I've started a wiki ReleaseGuide page and will fill it in over the next few days.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] 0.1-incubating release timeline?
Posted by Marvin Humphrey <ma...@rectangular.com>.
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