[almighty] Monorepo

[Thomas Mäder]

Hi folks,

Neither mono- nor multirepo organization is inherently better or worse. 
We should look at the practical issues. From a developers perspective, 
some would be:

 1. Do we want different versions of the source code checked out at the
    same time?
    In the end, this comes down to whether different components have
    their own release cycle, for example, we might develop the next
    version of the work item storage service, but the UI still runs
    against a previous version of the API. Our advertised approach is to
    always have master in production. Since we have different people
    working on the back end and the UI, I don't expect us to be able to
    make changes to the back end and front end in the same pull request.
    However, we may have an integration branch where we collect the
    related changes and then promote them to master atomically.
    If we have multiple repositories, we will have to prevent breakage
    some other way: for example with a "no breaking changes" policy
    (using a deprecation window) or by good old coordination between
    contributors.
 2. Tool support
    I use VSCode to program in go (in my opinion, the code editor that
    sucks the least ;-)). However, if I checkout both almighty-core and
    almighty-ui and then open the parent folder in VSCode, I can't use
    the git tooling in VSCode anymore. So for me, monorepo would work
    better.
 3. The downside of monorepo is that you can't ever check out less than
    the whole repo. But aside from some wasted disk space, what's the
    problem with that?


Note that this is purely a git issue, if we had a svn repo, we would 
naturally have a single repo with multiple projects (folders) in it.

My conclusion is that I see a monorepo approach as slightly more 
convenient. However, I don't think this is a game changes either way.

/Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/e1cc55f2/attachment.htm>