There various special considerations around Fedora IoT and CoreOS releases.

• IoT: IoT images are composed in a separate stream from the main "Fedora" compose - there are "Fedora IoT" composes. At each release point, we need to co-ordinate with the IoT team and nominate an image from the Fedora-IoT stream for release; we should make sure the image nominated for release has all (relevant, at least) fixes from the override repository, and passes all the IoT tests. Currently this is being done just in an ad hoc way, either in the Go/No-Go meeting if we remember or in Fedora Chat conversations; we should probably make this more formal and write it into the relevant policies (e.g. the Go/No-Go process documentation).

• CoreOS: similar to IoT, CoreOS has its own build/CI/release process, using streams. Similarly to IoT, we need to make sure that all the override repo fixes reach the CoreOS releases (this should always happen as the override repo packages are pushed stable soon after the candidate is signed off, but if we ever decrease the CoreOS stable release "lag time" this could be a consideration). Right now the CoreOS team more or less decides when to kick the stable stream over to the new release, and this happens a few weeks after release; this process is generally known to the relevant teams and doesn't cause problems, but it isn't really formally documented anywhere and we do not agree the schedule as part of the release process. Doing those things might be an improvement.

@sumantrom flagged this up as an issue and wants to work on it, I'm also interested in this.