Jan Lehnardt wrote yesterday:
>To take a bit of pressure out of this decision making process, I want
>to bring up an option that unblocks us indefinitely for making new
>releases at the expense of end-user experience.
> It’s a little bit of work, but not as much as anything approaching a
> rewrite.
> 1. move apache-fauxton to its own GitHub organisation outside of the
> ASF (we can always re-integrate it later)
> 2. publish release builds as tarballs somewhere on the web.
> 3. replace /_utils in CouchDB with a custom route that displays a
> simple web ui with a button “install Fauxton” that goes away once
> Fauxton is installed, that then fetches a Fauxton release tarball from
> outside the ASF and installs it on the user system.
> There is some infrastructure work to be done, and the added
> inconvenience for our end-users is not something I’d like to keep up
> for long.
> But should we decide to take this option (or one like it), it would
> allow us to not have to rush with a Fauxton adaptation, or be blocked
> on releases, or have no admin UI in a release.
Cheers Jan. I've followed up with Apache Legal on whether or not we
need to do the "repository dance" if we're not making official
releases, and it sounds like we don't:
https://issues.apache.org/jira/browse/LEGAL-319
So I propose that we only move couchdb-fauxton out of the aegis of
the ASF if and only if we decide we need to make another release
post- August 31.
If we stick to my proposed release schedule, that gives us until
November sometime before we have to make a decision. (I'd like to avoid
a December release, given the typical end-of-year schedule.)
-Joan
