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: local policy)
Date: Wed, 6 Jul 2011 18:33:04 -0700
From: Marvin Humphrey <marvin@rectangular.com>
To: lucy-dev@incubator.apache.org
Message-ID: <20110707013304.GA10824@rectangular.com>
References: <BANLkTikbXe8DCzHqt=2c67LvEM7Wo4dbkg@mail.gmail.com>
 <20110701205259.GA22872@rectangular.com>
 <CABTa2P6kBKHmxUBfofTP4OotgxLz=4ckP98ehkpEMpRdQCeGjw@mail.gmail.com>
 <20110704180514.GA10459@rectangular.com>
 <CABTa2P6LCqF2NW2yQiK8CFfRVgE27wU3yk0j3BayvVUKa9EfuQ@mail.gmail.com>
 <20110706232010.GA10488@rectangular.com>
 <CABTa2P7nu5wA7xnNc4JWn5_ereSctaY9sS8dgwMRUDY6i+r5YQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CABTa2P7nu5wA7xnNc4JWn5_ereSctaY9sS8dgwMRUDY6i+r5YQ@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [lucy-dev] building withOUT perl

On Thu, Jul 07, 2011 at 02:16:53AM +0200, Torsten Curdt wrote:
> Having a volunteer publish the gem does not sound like a great idea -
> at least long term. If there are committers around that do the work on
> a release - great. But it would be so much better if this was an
> automated process.

I like the sound of that. :)

We are already doing 90% of the automation, by writing the code which
generates the downstream dist artifacts.  We also have a script which
generates the commands that the RM needs to execute:

    https://svn.apache.org/repos/asf/incubator/lucy/trunk/devel/bin/release_commands.pl

How about we change that script to be an interactive app?  I.e. instead of
printing out commands for the RM to copy/paste, it prompts for permission and
then executes?

The output of this "gen_release_artifacts.pl" script would be not just the
canonical tarball, but as many of the downstream dists as the RM's system
could support generating, isolated within a directory (working name
"downstream") and accompanied by a README explaining that only the canonical
source release is officially endorsed under ASF policy.

    apache_lucy_incubating-0.2.0-rc1/
        apache-lucy-incubating-0.2.0.tar.gz
        apache-lucy-incubating-0.2.0.tar.gz.asc
        apache-lucy-incubating-0.2.0.tar.gz.md5
        downstream/
            README
            perl/
                Lucy-0.2.0.tar.gz
            ruby/
                apache-lucy-0.2.0.gem
            objective_c/
                apache-lucy-0.2.0.tar.gz

So long as the downstream build processes aren't too long or too flaky, and so
long as the RM isn't *required* to produce anything other than the canonical
artifacts, I think this would be a nice improvement over the current system.
There's no increase in PMC oversight burden, because the source release
remains canonical -- but it actually gets easier for PMC members who want to
audition downstream dist packages.

> ...but the ruby folks need a gem, objective-c people need a framework
> and/or a static library etc. And that's what they will expect. If it's
> really just a source only dist at *least* the build would have to be
> super super easy.

Once we eliminate the Parse::RecDescent and JSON::XS dependencies, everything
you need to build Lucy will come bundled with the Lucy tarball aside from the
host language, the C compiler and Make.  Building from source will be entirely
dependent on our code's reliability and portability.

Nevertheless, I'd be happy to see us supply unofficial downstream dists via
the ASF mirror network.  Apache has a long tradition of accompanying offical
source releases with unofficial "binary" distributions.  This is a slight
variation on that theme -- some of the downstream dists will be source-only --
but the principle is the same and so are the institutional costs.

> >> Or how are user obtaining and using it?
> >
> > I expect that the majority of our Perl users will always get the release via
> > the CPAN packaging system.
> 
> So why would it be published to CPAN but not to e.g. rubygems?

Oh, it will go to rubygems, I'd just left that out.  And to PyPI when we add
Python, etc.

Marvin Humphrey