couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Lehnardt (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1664) Import Fauxton
Date Fri, 01 Feb 2013 10:43:16 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568645#comment-13568645
] 

Jan Lehnardt commented on COUCHDB-1664:
---------------------------------------

You are technically correct, and like I wrote, I don’t necessarily care how the link up
is done, but the thing I am trying to solve here is easy of contribution. I have seen, time
and time again, that capable frontend developers would refrain from chipping because this
all looked too complicated. If we really want to get their contributions, we need to optimise
for them.

And yes, I suggest that:

    git clone couchdb-fauxton
    cd couchdb-fauxton
    npm start # or whatever
    <edit-reload-cycle>
    <commit-and-pull-request>

Makes *all* the difference over

    git clone couchdb
    cd couchdb/share/www
    <same as above>

Just because the latter comes with so much more fluff. It is unfamiliar and confusing.

In the other Fauxon thread I argued for top level command aliases in favour of "simply adding
a subfolder to PATH" because that’s not second nature to most web developers. And if we
ask them to do these things, they won’t and go away without contributing.

This just as an example of what mindset we want to have in mind when we set this up.

In addition, old Futon has barely seen any contributions, there are many reasons, but one
was that it is tucked into CouchDB. We can’t be doing the same and expect that problem to
magically go away. That’d be insane.

Finally, Fauxton/Futon is a fairly decoupled component of CouchDB. I can see the disadvantages
of using submodules (or whatever) in modules that are more tightly integrated (say the replicator,
or the view server), and I believe you learned that lesson at Cloudant and are not particularly
fond of. I support not putting all internal CouchDB modules in separate repository for exactly
that reason, but Fauxton merely exercises the outer API and is otherwise, code and development-wise
it’s own thing. I project/hope that the disadvantages of using submodules (or whatever)
aren’t as grave as with other components and thus the advantages outweigh them.



  
                
> 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’s code base into Apache
CouchDB.
> The code currently lives at https://github.com/cloudant-labs/couchdb/commits/fauxton
> Here’s 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 & NOTICE.
> I’ll 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 as per 3)
>  - in the CouchDB repo, make src/futon or wherever it should live a git-submodule to
the new couchdb-futon repo.
>  - Update build-from-checkout/clone instructions to add `git submodule update --init`
after `git clone <repo>`
> (I realise that not everyone likes submodules, I don’t exactly care 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 someone can point to a point that makes submodules *not* work
for this, I suggest 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 calling one command. For `make test`
we should also run Fauxton’s test suite (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 administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message