Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 209.85.223.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YBU8U-6g34YDv54s0=0D-LNzP9nmY=LgJWvgEwofGF9XQ@mail.gmail.com>
References: <62FB425D-453A-4F9F-8BAA-A38E1E219FE4@apache.org>
	<CAJ_m3YBU8U-6g34YDv54s0=0D-LNzP9nmY=LgJWvgEwofGF9XQ@mail.gmail.com>
Date: Thu, 1 Nov 2012 09:26:38 +0100
Message-ID: 
 <CAJNb-9q-c1P8GEHH-pDpyZHgjLQy0OXMf3t83r7+KrTExHq4AA@mail.gmail.com>
Subject: Re: Source code layout
From: Benoit Chesneau <bchesneau@gmail.com>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=bcaec529a0b12619cd04cd6ac7a5

--bcaec529a0b12619cd04cd6ac7a5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

about multiple repo noah pointed yesterday on the cordova projet:

https://git-wip-us.apache.org/repos/asf?s=3Dcordova

Not sure how each projects are considered though.

- beno=EEt


On Thu, Nov 1, 2012 at 7:19 AM, Paul Davis <paul.joseph.davis@gmail.com>wro=
te:

> On Wed, Oct 31, 2012 at 9:02 PM, Adam Kocoloski <kocolosk@apache.org>
> wrote:
> > Hi, I mentioned in IRC earlier today that I'd really like to see us
> organize our source code so that OTP applications are wholly contained in
> their own subdirectories and are organized according to the standard OTP
> application layout.  In a world where we've refactored the monolithic
> 'couch' application into a few more focused applications the layout could
> look something like this:
> >
> > src/
> >         couch_core/
> >                 c_src/
> >                 include/
> >                 priv/
> >                 src/
> >                 test/
> >         couch_config/
> >                 src/
> >         ...
> >         ibrowse/
> >                 include/
> >                 src/
> >                 test/
> >
> > We've already followed this layout for couch_index, couch_mrview and
> couch_replicator -- I'd just like to "finish the job".  A few of the
> advantages that I see are
> >
> > a) We can extract these individual applications using e.g. git-subtree
> and use them on their own as we see fit.
> >
>
> I'd be fairly interested in seeing how git subtree works in real life.
> I've seen two rough uses of it. First, to include a project whole sale
> as a dependency. Ie, avoid requiring the build system to have to
> download a tarball and script that project's build system. The other
> is to do what you're suggesting where we manage them with subtree
> while their development history is tied more directly to the main
> project. I guess that's a really long winded way of "are we or are we
> not sending patches upstream as often as committing to master".
>
> For the "coordinated development" model which would require us to have
> multiple git repos for individual OTP apps we'll have to figure out if
> infra has relaxed their requirements on multiple git repos per TLP.
>
> > b) We can remove the external dependencies (ibrowse, mochiweb) from our
> git repository and instead have the build system check them out directly
> from upstream.  Of course they'd still show up directly in the release
> artefacts.
> >
>
> This we actually can't do directly. We theoretically could have ASF
> mirrors like is common practice on GitHub (ie, fork a copy to own) but
> this comes with the caveats about multiple repos from A as well as
> probably blow back on why we're simply mirroring dependency projects.
>
> > c) Rebar is the de facto build system for most other Erlang/OTP project=
s
> and it expects to see this kind of layout.
> >
>
> While true, we should remember that we still haven't figured out a
> plan on how to actually use rebar with Autotools. Though I don't think
> this in anyway is an argument against splitting apps. I think its
> already pretty obvious that our code organization is terrible and we
> should be doing the source tree refactoring regardless. Just wanted to
> make a note.
>
> > If there are no objections we can set about achieving this after we
> branch 1.3.x.  Regards,
> >
> > Adam
>

--bcaec529a0b12619cd04cd6ac7a5--