couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: fauxton in its own repo.
Date Tue, 19 Mar 2013 17:02:58 GMT
What's the issue with just creating a second Git repos? Like I did for
couchdb-admin. I'd say this was a cheap operation. Doesn't cost us anything
to have 3, 4, 5 repos if we need them.

I don't want to open a can of worms here. I'm not heavily invested in this.
But if we avoided it because it seemed like it wasn't technically possible,
then we might want to re-consider. Repos are easy to request.


On 18 March 2013 23:19, Stephen Bartell <snbartell@gmail.com> wrote:

>
> On Mar 18, 2013, at 3:49 PM, Jan Lehnardt <jan@apache.org> wrote:
>
> >
> > On Mar 18, 2013, at 23:42 , Stephen Bartell <snbartell@gmail.com> wrote:
> >
> >> Thanks guys for clearing that up.
> >>
> >> I work mostly in multi git setups, so naturally flags were going up
> over this.  The reasons make sense though.
> >
> > Just out of curiousity, what do you do to mitigate the pain? :)
>
> tl;dr version:
> private npm + independent release cycles
>
> long version:
> We've got upwards of 50 repos for project I work on.  It was a complete
> bitch to release.  We considered moving to a single repo setup.  But, we
> really wanted to keep each component  in its own repo.  So I wrote a script
> which consumed cfg file specifying what was to be included in a given
> release.  It would then checkout the code as prescribed and build a tar
> ball.  That made it waaaay easier to create a release.
>
> About six months ago we decided to put each component on its own release
> cycle. We needed a package manager,and chose to use npm.  We set up an
> internal, private npm registry. Everything gets released there.  Each
> package defines all its dependencies and the repo from whence it came.
>
> I know some people would keel over at this sort of thing.  But it was a
> paradigm shift in how we release, maintain, and deploy our product. :)
>
>
>
> >
> > Jan
> > --
> >
> >>
> >>
> >> On Mar 18, 2013, at 3:15 PM, Russell Branca <chewbranca@apache.org>
> wrote:
> >>
> >>> Hi Stephen,
> >>>
> >>>
> >>> There was a fair bit of discussion behind this, and single repo ASF is
> the
> >>> real blocker. Also, while Fauxton can run as a couchapp, by default it
> >>> builds down into static files and is hosted by CouchDB the same way as
> >>> Futon.
> >>>
> >>> That said, making Fauxton as easily to develop as possible for new
> >>> contributors has been a primary concern of ours. We've gotten all
> >>> dependencies moved into package.json, and Garren has been knocking out
> a
> >>> new development server which will allow you to develop locally and not
> have
> >>> to build CouchDB as a part of Fauxton development. The new process will
> >>> basicaly be:
> >>>
> >>> git clone couchdb
> >>> cd couchdb/src/fauxton
> >>> npm install
> >>> ./bin/dev-server
> >>>
> >>> And you'll be up and running.
> >>>
> >>>
> >>> -Russell
> >>>
> >>>
> >>> On Mon, Mar 18, 2013 at 3:06 PM, Stephen Bartell <snbartell@gmail.com
> >wrote:
> >>>
> >>>> Referencing the topic [Merging the fauxton branch into master]
> >>>>
> >>>> Im just wondering, why can't fauxton development take place in an
> entirely
> >>>> separate repo from couch.  Its a couch app after all, correct?
> >>>>
> >>>> I think fauxton could be an example of couch's modular design.
> >>>>
> >>>> As I write this email, I think I've realized a blocker to this idea.
>  And
> >>>> that is that Couch really lives in a single ASF repo.  Nonetheless,
I
> want
> >>>> to throw this out there.
> >>>>
> >>>> Best,
> >>>> Stephen Bartell
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >
>
>


-- 
NS

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