[almighty] Monorepo

[Andrew Lee Rubinger]

Team:

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.

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.

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.

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.

S,
ALR

On Thu, Sep 22, 2016 at 7:36 AM, Thomas Mäder <tmader at redhat.com> wrote:

> Sabotaging my own argument....
>
> On 09/22/2016 01:15 PM, Konrad Kleine wrote:
>
>> 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.
>>
> 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.
>
> 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.
>>
> 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.
>
>>
>> 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!
>>
> I don't spend any time on this, roll outs are fully automated ;-)
>
>
> /Thomas
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>



-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/3dc527ae/attachment.htm>