This change proposal was submitted after the deadline and may impact the mass rebuild
Note that the gcc update already happened.
The way that gcc-9 was introduced into rawhide was rather awkward. The compiler is still in an early version, and there seem to be various problems when compiling programs with gcc-9. Ultimately this might turn out to bugs in gcc (some were already solved in gcc-9.0.1), or in various packages, but either way, the effect is that packages suddenly FTBFS without any easy workaround. To compound those issues, gcc-9 was built in rawhide, but there was no compose, so packages would FTBFS in koji, but would pass in local mock, because the same compiler version was not available through dnf mirrors, making it even more work to diagnose those issues.
I think we can do this better next time. The idea of providing gcc in a copr was raised. Also, it seems that a side-tag with gcc-9 to do test rebuilds first would also be helpful.
All that said, I certainly want gcc-9 in F30. So I'm inclined to approve the late change, and asks the gcc maintainers to take the additional steps to make the upgrade smoother next time.
Yes, I agree that we want gcc 9 in Fedora 30. However I'd rather not break everything during FTBFS. This is not yet a proposal, but what do you think about delaying the mass rebuild? It was already delayed by days in https://pagure.io/fesco/issue/2066 but maybe we delay this even further? I don't think mass rebuilding everything now is a good idea.
Metadata Update from @churchyard: - Issue tagged with: meeting
APPROVED (+6, 0, 0)
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-02-04/fesco.2019-02-04-15.01.html
Metadata Update from @churchyard: - Issue untagged with: meeting - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)