incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] Build from top dir
Date Tue, 07 Dec 2010 21:30:43 GMT
On Mon, Dec 06, 2010 at 09:01:41PM -0600, Peter Karman wrote:
> Is there some Apache rule that says that the PPMC cannot be burdened, or
> that there needs to be a single release tarball?

No rule, though it's not just the PPMC which has to inspect and vote on the
release artifacts -- as long as we're in incubation, we need three votes from
members of the Incubator PMC.  If we're lucky, we'll get those votes from our
Mentors; if not, we'll have to go hunting.

> Are there any other projects at Apache that build a distinct, stand-alone
> distribution in multiple target languages? 

There's QPid:

    http://qpid.apache.org/download.cgi

Here's the VOTE thread for Qpid release 0.8, which refers to a directory full
of files.

    http://markmail.org/message/n2obon5pjkl7m7oh
    http://people.apache.org/~robbie/qpid/0.8/RC3/

Qpid might be the only one, judging by what I was able to find at
<http://projects.apache.org/>.

CPAN has Net::Zookeeper, Net::Cassandra, Alien::SVN and Apache::Sling, but
they all seem to have been developed and released independently.
SpamAssassin's repository layout is CPAN-compatible.

> > Some projects at Apache make binary release artifiacts available in addition
> > to the source releases.  However, only the source release is official; binary
> > releases are considered volunteer efforts.  Dedicated Lucy release archives
> > for CPAN, PyPI, etc. would fall under the same classification.
> 
> Really? Doesn't a build in perl/ include all the requisite .c/.h files to build
> Lucy for Perl? The Perl build isn't a binary release at all; why should it be
> classified like an RPM?
 
Until you are a top-level project with a significant number of PMC members,
wrangling 3 binding votes to approve a release isn't trivial.  Submitting a
single archive for approval while in the Incubator is standard operating
procedure, and I'm confident we can get the votes we need.  If we submit
multiple tarballs, though, each of which must be independently QC'd for both
build and legal issues, we're asking for something both non-standard and more
labor-intensive.

My main concern here is that I don't want to set us up for a roadblock by
requiring too much of volunteers at Apache outside of our immediate community.
For illustration, we've benefitted from some very valuable volunteer work from
the denizens of Apache legal, but right now we're stuck having to delay our
initial release because LEGAL-82 lingers unresolved.  I don't feel like we
have a right to be dissatisfied because of that; we've just been asking a lot
of legal and I think that has something to do with the fact that we're not
getting 100% of our issues addressed any more.

Post-graduation, I don't have such strong feelings about how we vote on
releases.  I'd still lean towards scrutinizing and voting on a single official
tarball, then either reusing it or autogenerating unofficial archives -- but
we can cross that bridge when we come to it.

> Why can't we stick with making the perl/-level repository CPAN-compatible, the
> ruby/-level repository rubygems-compatible, etc? Each target language should
> know how to build itself, in the same idiomatic way that we intend to design
> each host language's Lucy implementation.

I'm cool with that.  It's where I think we'd eventually end up anyway as we
accumulate binding languages.

The question is whether all those individual archives need to be voted on by
the Incubator PMC.  I think we should make a monolithic release, then build
unofficial archives ourselves for CPAN, etc, rather than trying to push too
much through a narrow channel at Apache.  Why make things more difficult?
Releases are hard enough already.

> How about instead a top-level Makefile like this example:
> 
> -----------------------------8<------------------
> perl-dist: perl/Build.PL
> 	cd perl && perl Build.PL && ./Build dist
> 
> # similar for C-dist, ruby-dist, etc.
> 
> # grand dist target
> dist: perl-dist C-dist ruby-dist
> 
> -----------------------------8<------------------
> 
> So to build all target languages, it's a simple:
> 
>  % svn up && make dist

Looks good to me!

Marvin Humphrey



Mime
View raw message