couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Riyad Kalla <rka...@gmail.com>
Subject Re: Binary Downloads
Date Sun, 06 Nov 2011 14:13:08 GMT
>
> I don't think that this is too big a problem.


It is, it really is.

Many of you are too close to the problem to see it, but the 10-second
impression when you step into the Couch world (as compared to Mongo, Redis,
Orient, Raven or even Cassandra) is "... where do I download and run this
thing?"

How many times have you guys answered "Well version 1.1.2 isn't out yet, so
what version are you really using?"

and those aren't even the people that gave up and turned the other
direction, those are the ones that actively stayed and dug their way over
to couchbase (either knowingly or unknowingly) and grabbed one of their
binaries instead and they still don't even know what version of couch they
are running.

CouchDB needs pre-build binaries, ready to unzip and run exactly as Jan
enumerated in his first post.

On Sat, Nov 5, 2011 at 6:57 AM, Noah Slater <nslater@tumbolia.org> wrote:

> A few thoughts:
>
> I don't think that this is too big a problem. CouchDB is a server
> tool, and by and large, the type of people who are going to be
> installing it are going to know how to from source, or are going to be
> using a system where the application is pre-packaged for them. You
> wouldn't expect Apache httpd to have one-click installers. Having said
> that, it's nice that MongoDB have a list of pre-built packages to
> download. But they don't have a rigorous community voting process in
> place that requires people to test and vote on each artefact.  I think
> that's a weakness as well as a strength.
>
> Just to reiterate. The biggest problem in providing official platform
> specific binary downloads is that these artefacts would need to be
> voted on by the community. Dave asks what needs to be in place for
> them to be official. Nothing more than a vote. And therein lies the
> problem. Getting enough people, with the right hardware, to vote on
> all these things at the time of release.
>
> I don't have any problem with people, individuals or organisations,
> who want to build CouchDB for different platforms and make those
> packages available to our users. One one level, this is exactly what
> Debian and RedHat, for example, are doing already.
>
> I also have no problem linking through to unofficial packages from our
> downloads page, with the appropriate disclaimers, if it makes it
> easier for our users. I don't care how these packages are built, and I
> don't think there should be a submissions process. We'd just link
> through to any trust-worthy places that promised to keep a reasonably
> up-to-date package archive available.
>
> But let's bare in mind that for each platform, packaging CouchDB is a
> very specific process. We cannot possibly hope to get that kind of
> experience within the core committer team. We can't even hope to get
> all that experience on the mailing lists. So we're left with two
> options. Either build a set of generic packages that don't fit that
> well into the specifics of each platform, or commit ourselves to
> working with, enabling, and promoting specialised efforts by
> downstream teams. Or at all.
>
> MongoDB can do this because they don't use a community process for
> releases.
>
> From what I understand, Jan wants a sort of generic package. A
> directory that has a self-contained CouchDB that you can run. I guess
> this could be useful, in the same way CouchDBX was useful. You get to
> play around with CouchDB real quick. But it's not useful for much more
> than that, in my opinion. I certainly wouldn't advise anyone to use
> this for anything serious. There's no integration with the host
> operating system, and that's a pretty egregious problem for a database
> server. Jason covers this in his response I think. A CouchDB that
> lives in a little sandbox like that is a neutered CouchDB. Fun for
> playing with, but you can't do anything serious with it. And maybe
> that has a place in our ecosystem, but it should come with the
> appropriate warnings, & delineation.
>
> Speaking as the guy who built the first CouchDB package for Debian, I
> can tell you that building these things requires a lot of specialist,
> and in some case, arcane knowledge. It also requires a lot of care. I
> made sure that when you upgrade from one version to another, it would
> not trash your previous data. Building a proper package is full of
> this sort of stuff. Any system that promises to automate the process
> for you is a quick-fix. Not something I would ever recommend.
>
> Retooling the source to build proper Erlang applications, or any other
> similar proposal, does not solve our problem. The problem isn't the
> lack of technical means to build these packages. The problem lies in
> being able to build them in the first place (given a lack of varies
> infrastructure available to the build team) and a lack of people to
> vote on them at the point of release.
>
> If there is any community knowledge in Build CouchDB that we could
> move upstream, and bake in to our configure script of Makefiles, I
> would be totally behind that effort. The whole point of configure is
> to abstract away the specifics of individual platforms. The GNU
> Autotools may be a hideous beast, but if there's one thing they're
> good for, it's this. And precisely this.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message