Sorry, we don't have the available infra nor people to add a koji or bodhi instances to oVirt infra.
Anyone who is interested in using those services can use the Fedora or CentOS instances.

It may be just a mismatch on terminology indeed. What I mean is that tagging is IMHO a good enough system to achieve that. For an equivalent of -candidate tag I don't really need anyone else to review that, it's good enough for nightlies and non-release usage. Sure, you need to record what you have at the exact time and you need to be able to reproduce it, so set of hashes, NVR or whatever make sense, but only as a tracking record.
And for oVirt compose, as long as project is generally accepted as "part of oVirt" I think it should be sole responsibility of the sub-project maintainer to include/tag whatever he/she sees fit.
I do not think gerrit is a good fit, I think Fedora tooling has all this sorted out in a better way.
But it's not a big deal, the "gerrit" way just looks a bit cumbersome, but it might be the most easy thing to do right now.

not sure I understand "3". Yes, when you do a compose next day you have different "latest" packages. That's typically what you want.

No its not. You don't want the outcome of the compose process to be dependant on the time in which you run it, just on the sources of the packages that were included in it (As represented by a set of git hashes). Otherwise you cannot do any effective system testing or CI because the compose the CI system would make and test on day X may end up being different from the compose you release on day Y.

I do not see a point of "review and merge it" though. Why?

A few reasons:

1. We want a git hash that represents the point in which a new package version was introduced to oVirt from the reasons stated above

2. We want the action of introducing a change to oVirt to be explicit, so it is clear who is responsible for it

3. Doing it through a review system would provide a natural place where to provide feedback about a certain change causing issues

4. Doing it through a system like Gerrit would allow for easy rolling back of changes.

5. If some cases peer feedback may be useful - for example the integration team might prefer not to have changes introduced near new release.

We might me meaning different things when we say "review and merge". I just mean that it need to end up in Gerrit (or possibly Github), and someone needs to go and explicitly click "submit". I do not mean that one has to wait for peers to come by and vote it. You will be the owner of the "link" repo, so you get to set the rules about what a review means there.

BTW it might be even possible to fully automate step 3 when we reach the point where the CI system can take unmerged patches (or PRs), run system tests on them (essentially simulate the merge) and merge if successful. This is what we refer to as "Patch Gating" in other places. I`m afraid this is still ways off.

not sure I understand "3". Yes, when you do a compose next day you have different "latest" packages. That's typically what you want.
That new feature you mention seems ok, I do not see a point of "review and merge it" though. Why?

Ok. Here is how we get this with the existing tooling, and with very little work:

1. We create a new repo that will serve as the "link" between oVirt and mom

2. We place an 'automation/build-artifacts.sh' file in the new repo that will 'wget' or 'curl' a specific build of mom and place it in 'exported-artifacts' (You can even use 'repoman' to do it and get the same file format that you've seen in 'releng-tools')

3. When a new mom is released, a patch to the repo with the url of the new build needs to be submitted.

4. The "link" repo can be branched like oVirt versions to indicate which version of mom goes into which oVirt release (You can choose any branch names you'd like as the mapping to oVirt versions happens in the project yaml file, you can also have the same branch go into multiple oVirt versions).

WRT automating step 3 - we want builds to be reproducible. e.g. given a specific set of git hashes you`re supposed to get an equivalent release no matter when you build it. If we just take the latest mom every time we compose, we will just end up with a different composition depending on when we do it. This is why we need the "link" repo - to point to the exact mom build that goes into a certain oVirt version.

We are working on a new feature that may allow semi-automating step 3 in the future - It will allow the upstream repo to be queried periodically, and when a new release is found, a patch to the "link" repo will be created. The maintainer would still need to review and merge it.

WRT ovirt-web-ui I don't see how this kind of process makes any sense for such a core component. Quite frankly I'm having a hard time understanding why prefer this to "I submit a patch and the CI system does the rest".