On Tue, Nov 27, 2018 at 9:50 AM Dennis Gilmore <dennis(a)ausil.us> wrote:
> The customers RH serves have specific expectations, and in part
> dictates how delivery tooling is done. Binding the community to that
> may be counterproductive. This is especially true now that RHEL 8 Beta
> is out -- it's the perfect time for us to be rethinking at that level.
Compose tooling is largely shared, delivery tooling is not, though
there is room for improvement and convergence on both sides. We should
also consider CentOS and how we can share tooling, process and
resources, they still use something else entirely. Everything used in
Fedora is developed in the open and can be contributed to by anyone.
We have been talking about making the whole process flexible and
dynamic for years. I know internally they would like to have many of
the same things Fedora wants.
Yeah, it sounds like we're aiming in the same direction here. This is
part of what I mean by "decomposing the compose." We have one rather
monolithic process right now, all or nothing. And it does so much that
it's impossible to get any fast results from it. That doesn't mean it
doesn't work well for what it does. But it's not very flexible, as you
With a more flexible compose we could choose to do smaller tasks (as
well as capitalize on other time savings) for something like a
speculative testing build. That kind of build could be used to perform
integration testing as well as other tasks (automated, not manual!).
We could even potentially test against much of the repetitive,
time-consuming matrices manually (and heroically) run by QA. Then only
choose to do more extensive tasks based on that being "green."