about multiple repo noah pointed yesterday on the cordova projet: https://git-wip-us.apache.org/repos/asf?s=cordova
Not sure how each projects are considered though. - benoît On Thu, Nov 1, 2012 at 7:19 AM, Paul Davis <[email protected]>wrote: > On Wed, Oct 31, 2012 at 9:02 PM, Adam Kocoloski <[email protected]> > 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 >
