Consider fewer couchdb images (i.e. get on the same page or elaborate in documentation/comments)

[bean5]

Project	Referencing URL	Suggested Docker Container	Reason	Pitfalls
Official couchdb documentation	https://docs.couchdb.org/en/2.2.0/install/docker.html	https://hub.docker.com/r/apache/couchdb	"convenience binary"	Documentation is out of date listing 2.1.0 as latest
fauxton (this project)	https://github.com/apache/couchdb-fauxton/blob/master/.env#L5	https://hub.docker.com/r/ibmcom/couchdb3	"Used to provide a CouchDB 2 / 3 build matrix in .travis.yml"	No mention as to why apache's convenience package doesn't work.
Docker hub	https://hub.docker.com/_/couchdb	https://hub.docker.com/_/couchdb	Official	Isn't enough (which is why the others exist)

This seems unexpected to me. And causes various questions to surface such as:

• Is the official package not convenient or flexible enough?
• Why doesn't the apache one work for this project?
• This project itself is housed under the apache organization, so why use IBMs container?
• CouchDB isn't nascent anymore, but why is setting up fauxton and couchdb still messy? Standing up a docker instance is usually straight-forward especially for CouchDB after this many years, right?

[wohali]

Hi @bean5 , let me provide some background.

For Apache projects, no binary release is "official." The only official released asset is our source code tarball, which is signed, and checksums are provided. You can read the policy if you want more detail.

Any member of our community is welcome to build and release binary packaged assets. On our webpage, and in the documentation, we link to some of these.

• The apache/couchdb image exists as the one we ourselves maintain and push. It is under our direct control. You can generally find the latest released version there. We won't stop publishing this, as long as the project exists. This is the one we refer to in the documentation, because it's completely under our control.

• The couchdb top-level image is Docker's downstream binary. They use our definition from https://github.com/apache/couchdb , and get regular updates from us. While it is generally lock-step with ours, sometimes it can lag a bit, due to changing technical requirements on their end for submission. (This is similar with many downstream binary releases.) It's Docker's decision to make this image available, or take it down anytime they want to. While we'll continue to support them having it, it's neither our official image, nor is it the official image. Docker is free to call it their official image, if they want to. This is why it's not linked in our documentation today.

• IBM also has a CouchDB image, which they are perfectly entitled to do. I believe their image also includes the text-search functionality, which is something we don't include in the official image due to licensing constraints.
   
  During the long ramp-up to CouchDB 3.0, Faxuton had a need to run against the development version of CouchDB. Because Apache policy prohibits any "official" image from being made that contains an unreleased version of the product (this is why there is no apache/couchdb:dev or couchdb:dev available), IBM created this preview image for internal use, and for the Fauxton CI chain, so they wouldn't have to docker build apache/couchdb:dev with every pull request.
   
  Publishing this image was actually unsanctioned, and once it was brought to the attention of the CouchDB PMC, the image was taken offline until the official release could be done. Now that CouchDB 3.0 has released, the image is back.
   
  All this is by way of saying that, now, Fauxton can probably restore doing CI testing against the apache/couchdb:3.1.0 image if they want, but it's certainly not required /cc @popojargo @willholley

That said, this issue isn't constructive and especially doesn't belong in couchdb-fauxton.

Also note that CouchDB isn't nascent anymore, but why is setting up fauxton and couchdb still messy? Standing up a docker instance is usually straight-forward especially for CouchDB after this many years, right?

Yes, that's all you need. All 3 images you mention above come with Fauxton built in. Your peeking inside of our fauxton CI workflow is confusing you because of our testing process. Obviously we need to test Fauxton against CouchDB, so it uses an image, yes?

[bean5]

Oh! Thanks for all that! It was very instructive. You are spot-on that I was peeking into things and by not realizing it I got majorly confused. I did not realize fauxton was built-in.

I've been using a container I built myself, but wanted something more mainstream. My container was built with Ubuntu 15.10 and couchdb 1.5.0. I knew if I was going to start using CouchDB full-time, I'd have to overhaul or replace. I was hoping to peek into major projects and gain some insight as to which containers would be most mainstream and trust-worthy. This one was the one that threw me off. While your selenium use was obviously top-notch, I was baffled at why the IBM container was being used instead. Your history lesson explains how it came to be and it makes sense. I'm glad you guys are careful on the legal front. Better safe than sorry.

Thank you for understanding, for being quick to close tickets I made in error, and for the lesson. I'm actually going to bookmark this page for later use.

[bean5]

Oh my. I was also looking at the wrong documentation. I was at 2.2.0 documentation, which explains why it doesn't mention 3.1.0.

* so embarrassed *