A brief diversion from sticking to technical facts in this thread:
On Tue, Nov 8, 2011 at 1:46 AM, Randall Leeds <[email protected]> wrote: > But build-couchdb still _builds_ couchdb, so it's not the dream of a > "download-and-run-it" binary. The primary difference in the end > between build-couchdb and a standard source build is that the deps are > all wrapped up in the install prefix and kept separate from the user > system. What Jan was proposing was something like the _result_ of > build-couchdb builds, on several OS/architecture combinations, ready > to go. > > And to be honest, I'm totally fine with that. But, users are getting > more and more used to package managers even outside the *nix world, so > great downstream packaging is also key. I think this is the same > topic. > > It's really starting to sound like nothing's much wrong with our > source tree as just that our download page, and our packaging > community, doesn't get users where they need to go easily enough. Randall, thanks for moving the conversation back to goals and non-goals of a hypothetical binary distribution. That will illuminate a subsequent discussion about tooling and execution. Noah and I have each asked whether people *really* want a download-and-run executable. Recall the Steve Jobs quote, "You can't just ask customers what they want and then try to give that to them." Many users were briefly satisfied with build-couchdb's "just works" behavior, but ultimately disappointed that it requires manual startup/shutdown integration, manual log management, and manual upgrades. I strongly agree with Jan that the community needs turnkey CouchDB, but I share Noah's skepticism whether ./bin/couchdb is the best we can do. > Concrete next steps? > > For me, I'm going to try to get a clean debian patch branch based off > the latest packaging I can find, start building CouchDB in a chroot > and put it in my PPA. CouchDB as a desktop app is exciting. It reminds me of the joke that Linux is where you run web applications, Mac is where you develop web applications, and Windows is where you debug Internet Explorer bugs for web applications. Every desktop Couch user is a larval server Couch user, long-term developer, and community member. (Larva! Ew, it's nasty. It's so nasty.) IMO, as a CouchDB user, somebody who has to test upgrades and compatibility often: * An Ubuntu PPA * A free app in the Mac App Store * Whatever Windows does (.msi installer?) * An Android app, either in the Marketplace or maybe Amazon * An iPhone app in the App Store Notes: 1. If we achieved Jan's hypothetical ./bin/couchdb milestone, we would be very close to achieving the above list. Mostly it's jumping through a few procedural hoops. 2. All (most?) of these imply an official install, uninstall, and upgrade process, but we wouldn't have to write that ourselves (the "check for updates" feature) 3. The mobile apps are not an SDK, but like Android's DavDrive, http://davdrive-android.fun2code.de/ -- you run the app, it tells you your phone's IP, and you hit it with your browser (or CouchApp, or whatever). You could actually develop entire couch apps and replicate them to your production server. Quit the app, couch is gone. Remove the app, the data is gone. -- Iris Couch
