On Thu, Nov 3, 2011 at 15:26, Jan Lehnardt <jan@apache.org> wrote:
> 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.
I think what Till and I are getting at is that something this simple
can still be distro-specific and provide a "better" experience (e.g.,
automatic upgrades with the system package manager when we make more
releases) while still not requiring everyone to be an auto-tools
sysadmin.
$ curl $url | sh
...downloads certs and adds repositories
$ sudo apt-get (install|update) couchdb
Then relax.
-Randall
>
> 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
>
>
|