couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: fauxton in its own repo.
Date Tue, 19 Mar 2013 17:04:41 GMT

On Mar 19, 2013, at 18:02 , Noah Slater <nslater@apache.org> wrote:

> 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.

The problem isn’t that we can’t have them, but that coordinating change sets
that span repos is a pain in the neck.

Cheers
Jan
-- 



> 
> 
> 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
View raw message