Now that #75 is done we would like package maintainers to start opting in to extra gating requirements for their packages. We want to make this process as easy as possible. I think there are a few things we can do to simplify the process of writing a gating.yaml file for package maintainers:

Greenwave requires the id attribute on policies (actually I don't think it enforces this but it will crash without it). Most likely, a package will only have a single policy in its gating.yaml file. And package maintainers may not know or care about making the id uniquely identifiable for their package. For policies loaded from dist-git, Greenwave should fill in a default id like: <package-name>-dist-git-gating-policy.

Greenwave also requires the blacklist attribute, even if it's empty (I also don't think it correctly enforces this now but will crash if it's missing). It doesn't make sense on a per-package policy anyway. It should be ignored on policies loaded from dist-git.

Even though I originally came up with idea of "rule types" in hindsight I think it is confusing and unnecessary. The RemoteOriginalSpecNvrRule type doesn't make sense in a gating.yaml file, because that's how the file got loaded from dist-git in the first place (it's really not a rule at all). And the other rule types FedoraAtomicCi and PackageSpecificBuild don't make sense either, since they are just another mechanism for package whitelisting (see #216).

Indeed, if we go ahead with the idea in #216 then it would leave us with just the original PassingTestCaseRule and I think we could remove the idea of "rule types" entirely. The policy would just have a required_test_cases attribute, containing a list of test case names. I think this will be much simpler and more self-evident for packagers who are trying to write a gating.yaml policy for their package.