Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.210.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAL6JQiFsqvtQxqD_xv5aAtxezEMuEp1ukHTaezQFFy4xDbxSg@mail.gmail.com>
References: <785FABDB-2EF0-409A-A6C5-E9C8D498241B@apache.org>
	<CAFx2Yf7b6Whirg+LrMF+kn843h7+c9HYFhY2+PvUzZTXThk32w@mail.gmail.com>
	<CAAL6JQiFsqvtQxqD_xv5aAtxezEMuEp1ukHTaezQFFy4xDbxSg@mail.gmail.com>
Date: Thu, 3 Nov 2011 15:12:09 -0700
Message-ID: 
 <CAAL6JQhUMoZ0kH-K150mpQ=5sUCjRZWLTdy867PwCJFgqZGGcw@mail.gmail.com>
Subject: Re: Binary Downloads
From: Randall Leeds <randall.leeds@gmail.com>
To: dev@couchdb.apache.org, till@php.net
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 3, 2011 at 15:11, Randall Leeds <randall.leeds@gmail.com> wrote=
:
> On Thu, Nov 3, 2011 at 14:22, till <till@php.net> 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 clea=
rly
>>> =C2=A0 marked as "unofficial 3rd party binary downloads" that are not h=
osted on
>>> =C2=A0 ASF infrastructure.
>>>
>>> 2. Start with popular platforms.
>>>
>>> 3. Use the build-couchdb* script to create a fully self-contained
>>> directory with
>>> =C2=A0 CouchDB and all its dependencies in one place that can be rm -rf=
'd for
>>> =C2=A0 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 officia=
l
>>> ASF
>>> =C2=A0 binary releases, but I acknowledge that with a small community, =
we may
>>> have
>>> =C2=A0 trouble getting votes and testing for all popular platforms toge=
ther.
>>>
>>> =C2=A0 The nice thing of the proposal above though is, that we can, at =
any time
>>> =C2=A0 promote an unofficial build to an official one by voting on it a=
nd
>>> changing
>>> =C2=A0 it's label on the downloads page.
>>>
>>> B. There's many target platforms our users work with and we can't possi=
bly
>>> try
>>> =C2=A0 to service them all at once. We can grow this operation as we ge=
t
>>> volunteers
>>> =C2=A0 to help out with each platform.
>>>
>>> =C2=A0 The nice thing here is that we can help a significant portion of=
 users
>>> with
>>> =C2=A0 relatively little effort.
>>>
>>> C. Using existing package managers. There are many advantages to use
>>> official
>>> =C2=A0 package managers for system installation and they should in fact=
 be the
>>> =C2=A0 preferred way to set up a system, but they tend to be a little b=
it behind
>>> =C2=A0 with current releases.
>>>
>>> =C2=A0 I'd be super happy to also work with existing package managers t=
o improve
>>> =C2=A0 the situation there, but I consider this to be outside of the sc=
ope of
>>> this
>>> =C2=A0 discussion.
>>>
>>>
>>> What do you think?
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>>
>> Yes and no.
>>
>> I'm not a fan of rogue binary installs which don't leverage anything
>> distributions have to offer. It's never all self-contained, e.g. you wan=
t
>> to register the service for a startup procedure and off you go into
>> specifics of a system and outside a single directory. If anything it sho=
uld
>> be specific to the target: on Ubuntu/Debian there should be a launchpad
>> project which contains updated releases of CouchDB for let's say the
>> current Ubuntu/Debian releases. On Redhat/CentOS/Fedora a yum-mirror wou=
ld
>> be appropriate, etc. pp.. I'm sure each platform has a project to piggyb=
ack.
>
> 100% agree. I've already got a launchpad ppa here:
> https://launchpad.net/~randall-leeds/+archive/couchdb
> It's not useful right now, but I'm volunteering now to start keeping
> that up to date. I've already got the schroot toolchain set up so it
> shouldn't be too hard to maintain backports of recent CouchDB
> versions, along with dependencies, back to the lastest LTS Ubuntu
> release. I did some work the other night toward maintaining a debian
> branch in my git clone which should make it easier to maintain the
> package. I'll link up with sbisbee and chrisccoulson to see if I can
> help out with official Ubuntu packaging, but will also aim to maintain
> my own backports when necessary.

I'll look at creating a project for CouchDB in launchpad. I know
Benoit has done this for gunicorn, so I'll work with him to see how
that goes.

>
> Meebo runs CentOS/Scientific Linux and I've played with the RPM
> packaging for that quite a bit, though I tend to be less up to date on
> that since upgrading is a big production, whereas on my desktop I tend
> to keep more up to date. Happy to help out with that conversation,
> too, though.
>
> -Randall
>
>>
>> Generally though, I'm not sure what the objective is. E.g. is it to plea=
se
>> people on hackernews (SCNR)? :-D
>>
>> But for realz: is it to ensure more up-to-date CouchDB (binary) releases=
 on
>> different platforms? Because that might be something to work on. As far =
as
>> binary is concerned, most platforms have something already (Ubuntu, Debi=
an,
>> *BSD, ...). And some just don't do binary at all (I think Archlinux and
>> Gentoo would be examples). And then I am not sure if providing a binary =
to
>> their users makes sense.
>>
>> Also to consider: team up with current package maintainers in order to h=
ave
>> more frequent releases etc.. Or at least give that a try, before the
>> CouchDB project goes off to do their own thing.
>>
>> Till
>>
>
> Great thoughts, Till. I agree all over.
>
> -Randall
>