On Tue, Nov 27, 2018 at 10:12 AM Stephen John Smoogen <smooge(a)gmail.com> wrote:
Define what a compose is? Currently it is a word which covers a
multitude of different processes and reasons for those processes. We
can't 'fix' or even 'replace' or parallel them without actually
knowing why someone duct taped this tool to that widget during a 2 am
release window.
Yes, that's a good point, and something I wanted to say - one of the
starting points is defining exactly what output is needed for a
particular use case and figure out how to get *that* output as fast as
possible. (Probably the normal case will be taking a new build, and
producing a single testable ostree or image containing that build.)
Being able to optimize along a single path is how you get *much*
faster than the current global compose. And why the problem is
probably not best formulated as "speed up the global compose".
Owen