<div dir="ltr">Team:<div><br></div><div>This is a great discussion, and I'm thrilled to see us finding utility for public debate as we'd set forth in the kickoff F2F last week.</div><div><br></div><div>At this point we start to see the thread splinter into several tangents, so perhaps it's time to start compiling our requirements with regards to repository setup into a more digestable form.</div><div><br></div><div>I'm of the same position already mentioned by Thomas and Pete here; let's look to the pragmatic implications of a move to monorepo, and how that affects us both positively and negatively.</div><div><br></div><div>Baiju -- as you've started this mess ;) , would you like to take the lead on seeding a document for us that brings together the arguments considered here?  Would recommend a public forum for that as well, if possible.</div><div><br></div><div>S,</div><div>ALR</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 22, 2016 at 7:36 AM, Thomas Mäder <span dir="ltr"><<a href="mailto:tmader@redhat.com" target="_blank">tmader@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sabotaging my own argument....<span class=""><br>
<br>
On 09/22/2016 01:15 PM, Konrad Kleine wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote></span>
That is true now, but as soon as we have an extension that we don't build ourselves (in an open system, that could happen), that breaks down anyway.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote></span>
Not necessarily. If nothing has changed in core, we can detect that and not trigger a rebuild of the docker image. If we are using the commit hash as a build identifier, that is simply an implementation detail.<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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!<br>
</blockquote></span>
I don't spend any time on this, roll outs are fully automated ;-)<div class="HOEnZb"><div class="h5"><br>
<br>
/Thomas<br>
<br>
<br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Red Hat Developer Programs Architecture<div>@ALRubinger</div></div></div>
</div>