Monty Taylor wrote:
> [...]
> I didn’t yet talk about the reason that you *really* need speculative future state in order to do this _properly_ - but I think we should do that by the time we’re done - because let’s be honest - gating without speculative future state is just a random bug generator.
I think the site can first define gating, then move to say gating has
properties that depend on implementation: it can be leaky or waterproof,
and it can be scalable or not scalable. Then talk about the three
implementation styles (serial = unscalable/waterproof, parallel =
scalable/leaky, speculative = scalable/waterproof).
Gating is where what was tested is the final state of the target branch?
While I'm no longer working with Gerrit/Zuul on a regular basis, you can implement this in a poor way on Github by requiring all changes being up to date with the target branch before merging as well as requiring the CI checks to have passed. This works fine on relatively low traffic repos (<10 changes a day) provided the required tests are very quick (~5 mins).
Then it's a two-punch thing: you want gating, and if you do, you
probably want *proper* gating.
--
Thierry
Might be worth having some simple references for a couple of other common tools that are familiar to people, and then when you expand on how Zuul automates and scales this to allow it to apply to handle many more changes as well as facilitating more testing up front rather than after merge, it should open their eyes.
--
Darragh Bailey