I support this wholeheartedly! Having these kinds of things defined in a neutral way is super important, not just for the Googles, but also for things like wiki entries. This would be a big benefit to not just Zuul, but the CI/CD world in general :)

On Jun 14 2021, at 4:47 pm, Monty Taylor mordred@inaugust.com wrote:

...

On Jun 14, 2021, at 16:41, James E. Blair jim@acmegating.com wrote:

Hi,

I have a domain name, gating.dev, that I'd like to turn over to the Zuul community/OIF, if we're interested.

Here's my vision for it:

• A one-page site that explains/promotes the concept of project gating.

++

...

• It's not immediately focused on Zuul; if the word "Zuul" shows up,

it's probably at the bottom.

• Currently, when we talk to people about Zuul and project gating, they

don't immediately "get it". We should be able to direct people to this site, and in short order, they should "get it" (ideally, they should want it, but at the least, they should understand it).

• The simple URL makes it easy to remember and casually drop into

conversations (e.g., twitter threads, etc).

• It's not super complex. It's maybe not the place to explain the NNFI

or Tarjan's algorithms.

• Clear, direct text with images.

https://12factor.net/ and https://semver.org/ are good example of this idea. Both describe concepts, not specific pieces of software. Both are *very* specific as to what the concept means and do not try to say anything like “well, you _could_ do it this way if you want, or this other way, because this one piece of software has different opinions"

...

I think there are folks in this community that can contribute to this far better than I can. I may be kicking this off, but if we relied on me to write the text/images, we'd just end up with another copy of the reference manual, so don't do that. :)

Just to try to communicate the framework I'm thinking -- maybe a "hero" sentence at the top to set the stage, then maybe one of those things where there's a row of 3 benefits with nice graphics, then under that there's more text...

First stab: Gating is a system where: • Humans never merge changes, only computers • Computers automatically merge changes when all tests pass • Human code review approval can safely be fire and forget

Second stab: Humans are bad at boring repetitive tasks. There are no tasks more boring and repetitive than running a set of tests and waiting for them to finish.

Computers are excellent at boring and repetitive tasks, but are terrible at making judgement calls. A computer can easily run tests over and over again and consistently report success or failure.

Gating empowers humans to focus on creativity and judgement by completely removing their ability to do boring tasks like merging code if and only if if works.

In a gating system: • Humans never merge changes, only computers • Computers automatically merge changes when all tests pass • Human code review approval can safely be fire and forget

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 just described the Zuul website, so... we could use that structure -- it seems to work for a lot of folks, or maybe someone has an actual different idea. ;)

Okay, that's enough rambling from me. Do folks like this idea? Any suggestions to get started? Maybe we can brainstorm here for a bit and if it sounds like the idea has legs, we can set up a new repo for it.

-Jim

---

Zuul-discuss mailing list Zuul-discuss@lists.zuul-ci.org http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss

---

Zuul-discuss mailing list Zuul-discuss@lists.zuul-ci.org http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss

On Tue, 15 Jun 2021 at 10:09, Thierry Carrez thierry@openstack.org wrote:

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