Mailing-List: contact lucy-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of hossman_lucy@fucit.org
 designates 208.69.42.181 as permitted sender)
Date: Tue, 7 Dec 2010 18:29:35 -0800 (PST)
From: Chris Hostetter <hossman_lucy@fucit.org>
To: lucy-dev@incubator.apache.org
In-Reply-To: <20101207213043.GA15550@rectangular.com>
Message-ID: <alpine.DEB.1.10.1012071752010.21158@radix.cryptio.net>
References: <20101207004351.GA12827@rectangular.com>
 <4CFDA395.7050702@peknet.com> <20101207213043.GA15550@rectangular.com>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [lucy-dev] Build from top dir


: 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.

1) Although the lucene release haven't really set a good example of this, 
the mantra Juka has always evangalized that i've come to appreciate is 
that the "source" release should essentially be "svn export | tar | gzip"

it not only keeps things simple, it ensures that you don't risk 
complications of a build process that accidently leaves out important 
files (some of hte old lucene-java source release could not actually be 
built because common-build.xml was accidently excluded from the tar ball)

2) The source release is all that matters, it's the only thing that *must* 
be voted on.

in lucene land we typically (ie: every release i know of) review the 
binary release artifacts at the same time as the source vote, because if 
there's a problem with them it's probably going ot require a change to the 
source release as well -- ut you don't have to do it that way.

Note for example the HTTPD project, which produces all sorts of binary 
artifacts from any given source release (in their case not because of 
target langauges but because of target *architectures*) they don't even 
worry about the binary artifacts until after the source release has been 
voted on and made public...

    http://httpd.apache.org/dev/release.html
    http://httpd.apache.org/dev/binaries.html

i wouldn't jump through any hoops trying to organize the code in some 
convoluted way just for the sake of trying to simplify the release voting 
-- if you want to to keep the vote simple, make the source release 
artificats clean, clear, well documented and easy to "build"

If it makes sense for the Lucy build to have 200 different binary 
artifacts targeted at diff languages, so be it - the important thing is 
that every one of those binary packages needs to be reproducable by anyone 
with the source release, the build documentation, and a copy of the 
neccessary dependencies.

And FWIW: I have no direct experience with this sort of thing, but i 
suspect stuff like the CPAN and PEAR distributions and what not fall under 
the same guidelines as "Downstream Packages" like RPM and DEB files and so 
on ... they aren't considered official, and shouldn't factor into the vote 
at all.  As i understand it: the ASF deliberately avoids 
voting/regulating/condoning on the downstream packages...

http://incubator.apache.org/guides/releasemanagement.html#best-practice-downstream

The Lucy PPMC (in conjunction with the IPMC) should be able to formally 
vote on a Lucy source release, and after that: any individual (including 
PMC members) can go build and upload artifacts to CPAN, PEAR, etc... (no 
vote required)


-Hoss