Bit more detail here: when a project opts in to packit, it keeps its spec file upstream. packit automatically does a scratch build of the package for upstream PRs. we could then schedule openQA tests for these package builds.

stuff to figure out: how to actually get the package builds (I think they're sent to COPR). how to be notified of this happening (we'd need to figure out how to subscribe to messages/signals/whatever from whichever upstream forges we want to support, I guess, or maybe COPR messages would be enough, if COPR messages are a thing). how to get results forwarded to where someone associated with the upstream project will actually see them.

this is quite a big thing and we may not get to it any time soon. there are other complications, like anaconda would actually want to carry the tests themselves upstream, which may not be practical. at that point they may be better off running their own openQA instance and plumbing it into the upstream forge themselves. we have to consider the resource impact of onboarding projects in this way, and the added burden of handling the results; I might want to set it up somehow such that these results are in their own group, separate from the Fedora Updates group, so we don't 'pollute' the updates results with these results. It's really valuable to be able to just eyeball the updates results and panic if anything is red; if these results were mixed in I'm not sure it'd be possible to do that any more.