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 22:26:11 GMT
Randall, Till,

I had hoped I addressed this in my original mail, but let me try again :)

I'm in favour of all the things your are saying, but I'm trying to address this scenario:

$ wget $url
$ tar xzf $archive
$ ./$dir/couchdb
  Time to relax.

All the other things we should also do, and please don't let me hold you back from doing them
:)

A lot of areas need improvement, and I'm attacking a small one without trying to boil the
ocean. If you think the above is a bad idea, please let me know, we shouldn't do it.

But if you think it is okay, then lets do it. And then get to the next thing.

Cheers
Jan
-- 


On Nov 3, 2011, at 23:11 , Randall Leeds 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 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
>>> --
>>> 
>>> 
>> 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 want
>> 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 should
>> 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 would
>> be appropriate, etc. pp.. I'm sure each platform has a project to piggyback.
> 
> 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.
> 
> 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 please
>> 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, Debian,
>> *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 have
>> 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


Mime
View raw message