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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
