On Wed, Oct 31, 2012 at 9:02 PM, Adam Kocoloski <kocol...@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 projects 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
