couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Binary Downloads
Date Tue, 08 Nov 2011 10:26:52 GMT
Big fat +1 for all of this.

On Tue, Nov 8, 2011 at 2:43 AM, Jason Smith <jhs@iriscouch.com> wrote:

> A brief diversion from sticking to technical facts in this thread:
>
>
> On Tue, Nov 8, 2011 at 1:46 AM, Randall Leeds <randall.leeds@gmail.com>
> 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
>

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