[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Splitting the repo

Hi everyone,

While IMHO it's too early to even be able to split the repo, it's not to early to talk about it, and I wanted to spin this off to keep the other thread focused.

In particular, I am trying to figure out exactly what is hoped to be gained by splitting things up. In my experience, a single project that spans multiple repos has always come with excessive overhead and pain. Of note, we recently merged the website and dataflow-worker into the main repo *exactly* to avoid this pain (though the latter was particularly bad due to one of the repos being private).

If need be, I don't see any reason we can't have a single repo with directories


possibly even with their own build system (unified only through a top-level "build everything" script that descends into each subdir and runs the appropriate command). I'm not saying we should do this (there is value in having a single consistent build system, etc.) but it's possible. We could probably even make separate releases out of this single repo (if we wanted, though given that our releases are time-based rather than feature-based, I don't see much advantage here).

Also, there was the comment.

On Wed, Oct 10, 2018 at 7:35 AM Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:
> Side note: beam portability would be saner if added on top of others than the opposite which is done today.

I think you brought this up before, Romain. I'm still trying to wrap my head around what you mean here. Could you elaborate what such a structure would look like?