Jesse Keating wrote:
Slight variation on this. All builds from devel/ (or master in the
new
git world) would go to the koji tag dist-rawhide-candidate. Builds
which are tagged with dist-rawhide-candidate trigger AutoQA tests, of
the nature "rawhide acceptance" (this would have to get fleshed out at
some point, but it'd be something that builds upon the tests we would
already do post-build). Builds that pass rawhide acceptance would get
tagged into dist-rawhide, would show up in the build roots, and would be
part of the nightly rawhide compose. Builds that do not remain in
dist-rawhide-candidate. A maintainer can review the failed cases and
make a decision, override the system or do a new build. Egregious use
of system overriding would trigger FESCo attention and perhaps some sort
of retraining or sanctioning.
The assumption is that automated QA catches all possible breakage, which is
not true. In fact *no* QA will catch all the Rawhide breakage as some is
caused by the mere fact of things being different, which is intentional and
part of what Rawhide is about (e.g. the libata change in the kernel, the
change from KDE 3 to 4 etc.). Releases are needed to handle this kind of
changes in a smooth way. But automated QA will also miss many actual bugs.
Kevin Kofler