Adding change owners on CC: @ausil , @adamwill l

This change is listed and categorized as a System Wide Change (and given the enormity, that seems right), but several of the sections which are mandatory for System Wide Changes are missing.

@mattdm What items do you think are missing?

@ausil Well, "Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)" jumps out....

@mattdm it was answered. Just bellow the question I have fixed it up now

Ok, thanks. :) Looks good to me now.

This was approved during last meeting:

• AGREED: Approve the F27 System Wide Change: No More Alphas (+1:5, 0:1, -1:0) (Rathann, 16:23:35)

@ausil @adamwill FESCO would like to see more details on the implementation of "gating Rawhide builds from landing in the compose and gating the publication of composes on automated test results."

On "gating the publication of composes on automated test results", we have compose-level automated tests already, and a very early implementation of a script for determining the release-ability of a given compose:

https://pagure.io/fedora-qa/lolz_and_roffle

That needs some cleaning up, but all the pieces are basically there.

What we mean by 'publication of composes' is simple: all the composes initially show up somewhere under https://kojipkgs.fedoraproject.org/compose/ . A compose sitting there means very little to an installed Fedora system; nothing pulls packages from that location, or anything.

At present, every time a Rawhide compose completes successfully, it is then immediately synced over to the fedora/linux/development/rawhide/ location on the master download server. From there it's synced out to all the mirrors. That's where installed Rawhide systems look for packages, so that's what we call "publishing" the compose (it also involves updating mirrormanager metadata and stuff, but no need to get into the details): as soon as that happens, that compose 'becomes' the current official state of Rawhide. Someone running 'dnf update' on a Rawhide system will get the packages from that compose, someone doing a network install will get the packages from that compose, etc.

Note this is already a very light form of 'gating', as it means we only push out composes that 'successfully composed', which effectively means we gate on the release-blocking images composing; we have Pungi configured such that if any of the critical images fails to compose, the compose is considered 'failed'. This is a departure from how we did things before Pungi 4, when so long as the basic repo creation / mash steps worked, we'd sync out the result, and so sometimes we'd be 'publishing' composes that couldn't even produce a working boot.iso.

So the idea on that level is simply to add a bit more gating to the process: instead of syncing every compose that completes 'successfully', we'd sync every compose that completes successfully and meets some requirements based on the compose-level automated tests.

Currently openQA and Autocloud run the compose-level automated tests, but it's entirely plausible to run some in Taskotron or really any other system; we're currently working to move the tests currently run by Autocloud to be run by Taskotron instead, for instance. The releng process that decides whether to sync composes will pull the results from ResultsDB, so it doesn't matter a lot where they came from. The 'lolz-and-roffle' script linked above already does this.

Note this area of the plan - as I understand it - doesn't involve any expectation that we'll write additional tests or build huge new systems that don't currently exist. We already have a reasonable set of compose-level tests, certainly enough to get started with this kind of process. Really the only piece that's needed is to iterate lolz-and-roffle a bit and hook it into the compose sync process on releng's side.

Hope this clarifies things a bit. I'm not as clear on exactly what the F27 plan is for the "gating Rawhide builds from landing in the compose" bit; I'm not sure if that's all of a piece with the bigger CI planning going on, or slightly different. Hopefully Dennis can advise.

So, this is approved, I don't think there's anything further for FESCo here, so closing.

I'd suggest perhaps a discussion or meeting soon to play out exactly what things will be enabled when and then announcing that to maintainers so there's no surprises.