From dev-return-19078-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Nov 3 16:24:39 2011 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6457A7416 for ; Thu, 3 Nov 2011 16:24:39 +0000 (UTC) Received: (qmail 32827 invoked by uid 500); 3 Nov 2011 16:24:38 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 32793 invoked by uid 500); 3 Nov 2011 16:24:38 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 32785 invoked by uid 99); 3 Nov 2011 16:24:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2011 16:24:38 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Nov 2011 16:24:31 +0000 Received: from rose.local (p5797A81A.dip.t-dialin.net [87.151.168.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id F24933CDD9 for ; Thu, 3 Nov 2011 17:24:10 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Binary Downloads From: Jan Lehnardt In-Reply-To: Date: Thu, 3 Nov 2011 17:24:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <726AF1DE-A3EB-42C4-84DB-3E5502B1C381@apache.org> References: <785FABDB-2EF0-409A-A6C5-E9C8D498241B@apache.org> To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on apache.org On Nov 3, 2011, at 17:08 , Benoit Chesneau wrote: > On Thu, Nov 3, 2011 at 12:35 PM, Jan Lehnardt wrote: >> Hi all, >>=20 >> I think we should start considering providing binary downloads for = our users. >>=20 >> The whole topic is a bit of a mess (see below), so I'd propose to = start small. >>=20 >> 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. >>=20 >> 2. Start with popular platforms. >>=20 >> 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. >>=20 >> * https://github.com/iriscouch/build-couchdb >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> The nice thing here is that we can help a significant portion of = users with >> relatively little effort. >>=20 >> 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. >>=20 >> 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. >>=20 >>=20 >> What do you think? >>=20 >> Cheers >> Jan >> -- >>=20 >>=20 >=20 > Ah, quite interresting topic. Thanks to raise it! >=20 > 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). >=20 > I think to do the right job we could: >=20 > - 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. >=20 > - Create a toolchain =E0 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. >=20 > 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 --=20