On Tue, Nov 27, 2018 at 6:26 PM Paul Frields <stickster(a)gmail.com> wrote:
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 that
> > 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
Actually amusingly if you look back through the history post F-21 and
the massive delays that happened due to various non monolithic
processes one of the outcomes of the "get a release done with
Fedora.next" was to be able to do full composes every day because
prior to that we only did newRepo, a network install and live/cloud
images and often we'd get to Alpha TC1 right after branching to
discover a whole bunch of stuff was completely broken. We finally got
this with the move to "pungi 4" in Fedora 24, and in the intervening
releases we had huge amounts of complaints because rel-eng couldn't
provide all release artifacts to be pushed through CI/CD so
regressions could be fixed instantaneously. Yes, I'm aware things
change, and I often push them, but it's worth knowing the history how
we got to where we are!
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!).
Yes, and in some regards there's already parts of the project doing
this, the TWA release runs like this, as does the IoT release and I
mentioned above ways to break some of the bits up more.
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."
Completely agree, but there's quite a bit of work to be done to get to
that unicorn but none of the process to get there has been documented
or even proposed in this thread, it's not easy (believe me a lot of
people have looked over the years I've been involved in rel-eng) and
most of what I've seen of actual concrete means to get there won't get
us anywhere close to that, while yes it will still improve it.