couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Binary Downloads
Date Sat, 05 Nov 2011 13:57:26 GMT
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.

View raw message