incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Binary Downloads
Date Thu, 03 Nov 2011 16:24:10 GMT

On Nov 3, 2011, at 17:08 , Benoit Chesneau wrote:

> On Thu, Nov 3, 2011 at 12:35 PM, Jan Lehnardt <jan@apache.org> wrote:
>> Hi all,
>> 
>> I think we should start considering providing binary downloads for our users.
>> 
>> The whole topic is a bit of a mess (see below), so I'd propose to start small.
>> 
>> 1. This first iteration are links from couchdb.apache.org that are clearly
>>   marked as "unofficial 3rd party binary downloads" that are not hosted on
>>   ASF infrastructure.
>> 
>> 2. Start with popular platforms.
>> 
>> 3. Use the build-couchdb* script to create a fully self-contained directory with
>>   CouchDB and all its dependencies in one place that can be rm -rf'd for
>>   uninstalling.
>> 
>> * https://github.com/iriscouch/build-couchdb
>> 
>> 
>> The above circumvents several things that I hope we can resolve later, but that
>> I don't consider blocking us from getting the above started.
>> 
>> A. Official ASF releases. Of course, ideally, we should provide official ASF
>>   binary releases, but I acknowledge that with a small community, we may have
>>   trouble getting votes and testing for all popular platforms together.
>> 
>>   The nice thing of the proposal above though is, that we can, at any time
>>   promote an unofficial build to an official one by voting on it and changing
>>   it's label on the downloads page.
>> 
>> B. There's many target platforms our users work with and we can't possibly try
>>   to service them all at once. We can grow this operation as we get volunteers
>>   to help out with each platform.
>> 
>>   The nice thing here is that we can help a significant portion of users with
>>   relatively little effort.
>> 
>> C. Using existing package managers. There are many advantages to use official
>>   package managers for system installation and they should in fact be the
>>   preferred way to set up a system, but they tend to be a little bit behind
>>   with current releases.
>> 
>>   I'd be super happy to also work with existing package managers to improve
>>   the situation there, but I consider this to be outside of the scope of this
>>   discussion.
>> 
>> 
>> What do you think?
>> 
>> Cheers
>> Jan
>> --
>> 
>> 
> 
> Ah, quite interresting topic. Thanks to raise it!
> 
> I'm +1 on the idea to have "official binaries" but I really dislike
> the idea to have to use build-couchdb for that. Or any system that use
> rakes, ruby, python .... where we could just use erlang and unix
> tools. It does the job but it's petty ugly (Jason, no offense,
> build-couchdb does its job quite well).
> 
> I think to do the right job we could:
> 
> - adapt the build system to build proper elang release (using
> reltools). We can wrap rebar for that since it's pretty efficient
> these days and well supported (allows parralel builds, release buils
> and clean updates) but this isn't really required, it can be perfectly
> handled by autotools. (I think that using rebar would give us more
> options though).  The advantage of using erlang release tools is that
> we can cleanly manage the modules we need. You can manage templates,
> so other distributors can adapt it to their system.
> 
> - Create a toolchain à la mozilla that would allows later to introduce
> later cross-complication and start to support other platforms. They
> are petty good for that and I think we can borrow a couple of ideas.
> 
> I would be really interested to work on such things. Also maybe with a
> proper toolchain we could setup a build-bot that create nightly
> releases and such.

Great feedback Benoit. I agree with all of the above, but in light of
the lack of a tool and infrastructure that does all of the above, I'd
suggest we go along with build-couchdb until we have something better
to replace it.

Cheers
Jan
-- 


Mime
View raw message