[almighty] Monorepo

[Pete Muir]

I agree with Thomas - this should be a practical decision, not a
philosophical one - whatever is most convenient, right now. This is
also one thing where I don't think consistency really matters too
much. I'd also suggest that continually iterating on the structure is
a good idea - what works for the team today (i.e. getting the project
going) could be very different from 6 months time (e.g. onboarding
contributors).

On 22 September 2016 at 09:42, Thomas Mäder <tmader at redhat.com> wrote:
> 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:
>
> 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.
> 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.
> 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
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>