Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Fri, 1 Feb 2013 20:30:13 +0000 (UTC)
From: "Paul Joseph Davis (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12630132.1359639650298.231368.1359750613962@arcas>
In-Reply-To: <JIRA.12630132.1359639650298@arcas>
References: <JIRA.12630132.1359639650298@arcas>
Subject: [jira] [Commented] (COUCHDB-1664) Import Fauxton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COUCHDB-1664?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13=
569041#comment-13569041 ]=20

Paul Joseph Davis commented on COUCHDB-1664:
--------------------------------------------

Hrm. I'm not sure I totally agree with the reason that Futon hasn't seen mo=
re contributions is merely because its in the same repo as CouchDB. Althoug=
h I wouldn't be surprised if we did get more contributions having it separa=
te.

As for releases, I wonder if we couldn't just insert a built version of Fau=
xton into the releas artifact. I know the ASF has rules about releases only=
 containing code from ASF VCS, but I wonder if it has to be the same repo (=
granted, I doubt that this question has been asked before given that Git is=
 so new). Instead of worry about git submodule/subtree/subwhatever maybe we=
 just have two projects that are on different release cycles and for ease o=
f use we bundle a Fauxton in the CouchDB tarball (and allow package manager=
s to pull newer Fauxton based on its own dev cycle?).


               =20
> Import Fauxton
> --------------
>
>                 Key: COUCHDB-1664
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1664
>             Project: CouchDB
>          Issue Type: Task
>          Components: Futon
>            Reporter: Jan Lehnardt
>
> Fauxton is the the next Futon. Now is a good time to get it=E2=80=99s cod=
e base into Apache CouchDB.
> The code currently lives at https://github.com/cloudant-labs/couchdb/comm=
its/fauxton
> Here=E2=80=99s the sub-steps:
>   1. ask the authors/committers to sign an Apache CLA (in progress)
>   2. decide on how to integrate the code base (see below)
>   3. decide if we want to keep calling it Fauxton, or just Futon again.
>   4. fill out IP Clearance documentation (in progress).
>   5. prepare the code base with legal requirements, like ASF headers & NO=
TICE.
> I=E2=80=99ll volunteer to do champion all of these.
> As for 2. Integration I propose the following:
>  - Ask INFRA for a separate repository couchdb-futon (or couchdb-fauxon a=
s per 3)
>  - in the CouchDB repo, make src/futon or wherever it should live a git-s=
ubmodule to the new couchdb-futon repo.
>  - Update build-from-checkout/clone instructions to add `git submodule up=
date --init` after `git clone <repo>`
> (I realise that not everyone likes submodules, I don=E2=80=99t exactly ca=
re about the integration as long as it is a single command that needs to be=
 run to make things work. No solution is without drawbacks, so unless someo=
ne can point to a point that makes submodules *not* work for this, I sugges=
t we avoid this particular bikeshed).
> As for 3: Futon.
> Once all that is in place we can work on integrating building Fauxton on =
`make dist`. It should be a matter of installing the dependencies and calli=
ng one command. For `make test` we should also run Fauxton=E2=80=99s test s=
uite (when it exists). None of that is critical for the import, though.
> Consider this a draft.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira