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 <t...@php.net> wrote: >> On Thu, Nov 3, 2011 at 12:35 PM, Jan Lehnardt <j...@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
