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 model/ website/ java/ go/ ... 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 <[email protected]> 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?
