<div dir="ltr">I agree with Thomas,<div><br></div><div>but I from an operations point of view it would be nice to know that the docker image for core with revision X works fine.</div><div><br></div><div>With a monorepo (and I think this is what KB mentioned on Bluejeans) we would need to rebuild the docker image for core every time someone makes a ui change. This leads to a docker image for core with revision X+1. Hence, we would need to roll out a new image even if nothing has changed.</div><div><br></div><div>I find that not only a waste of energy but a cause for problems. Just consider the amount of time we spend for useless roll outs of the exact same binary only built at different times!</div><div><br></div><div>Any thoughts on this?</div><div><br></div><div>Regards</div><div>Konrad</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 22, 2016 at 11:34 AM, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com" target="_blank">pmuir@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with Thomas - this should be a practical decision, not a<br>
philosophical one - whatever is most convenient, right now. This is<br>
also one thing where I don't think consistency really matters too<br>
much. I'd also suggest that continually iterating on the structure is<br>
a good idea - what works for the team today (i.e. getting the project<br>
going) could be very different from 6 months time (e.g. onboarding<br>
contributors).<br>
<div class="HOEnZb"><div class="h5"><br>
On 22 September 2016 at 09:42, Thomas Mäder <<a href="mailto:tmader@redhat.com">tmader@redhat.com</a>> wrote:<br>
> Hi folks,<br>
><br>
> Neither mono- nor multirepo organization is inherently better or worse. We<br>
> should look at the practical issues. From a developers perspective, some<br>
> would be:<br>
><br>
> Do we want different versions of the source code checked out at the same<br>
> time?<br>
> In the end, this comes down to whether different components have their own<br>
> release cycle, for example, we might develop the next version of the work<br>
> item storage service, but the UI still runs against a previous version of<br>
> the API. Our advertised approach is to always have master in production.<br>
> Since we have different people working on the back end and the UI, I don't<br>
> expect us to be able to make changes to the back end and front end in the<br>
> same pull request. However, we may have an integration branch where we<br>
> collect the related changes and then promote them to master atomically.<br>
> If we have multiple repositories, we will have to prevent breakage some<br>
> other way: for example with a "no breaking changes" policy (using a<br>
> deprecation window) or by good old coordination between contributors.<br>
> Tool support<br>
> I use VSCode to program in go (in my opinion, the code editor that sucks the<br>
> least ;-)). However, if I checkout both almighty-core and almighty-ui and<br>
> then open the parent folder in VSCode, I can't use the git tooling in VSCode<br>
> anymore. So for me, monorepo would work better.<br>
> The downside of monorepo is that you can't ever check out less than the<br>
> whole repo. But aside from some wasted disk space, what's the problem with<br>
> that?<br>
><br>
><br>
> Note that this is purely a git issue, if we had a svn repo, we would<br>
> naturally have a single repo with multiple projects (folders) in it.<br>
><br>
> My conclusion is that I see a monorepo approach as slightly more convenient.<br>
> However, I don't think this is a game changes either way.<br>
><br>
> /Thomas<br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> almighty-public mailing list<br>
> <a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br>
</div></div></blockquote></div><br></div>