David Woodhouse wrote:
I don't think anyone suggested that you must delay the security fix while someone debugs and fixes a compiler problem like that (although usually if it's a security fix it'll be a minimal patch, and any compiler bug you now trigger should be fairly easy to work around).
Except Firefox's codebase is large enough that a bug may be introduced in something that would have affected the previous build without the patches and it would go unnoticed as I don't produce Firefox builds daily. I understand people want to do daily? builds to catch this sort of thing sooner, which I support. Some times it affects new code, sometimes it affects old code. It's hard to predict.
Additionally, we get security fixes in chunks. Up to 30 at a time and they come bundled with other "high importance" fixes such as crash fixes, hang fixes, etc.
The only delay you currently have is the time it takes to add the ExcludeArch: to the specfile and file the ExcludeArch bug -- and then for the build system to rebuild the package itself. You can even find the test case and file the compiler bug (on which your ExcludeArch bug will depend) _after_ you've built the new package with the ExcludeArch.
Actually, no. Firefox can take up to 5 hours to build. If the build fails toward the end, it's ~4 hours PLUS 5 hours which is already a full work day. Considering that there are packages that need rebuilding currently against the new Firefox, this does have a very real impact on timing.
Has that _really_ been so much of a problem for you?
Honestly, it has been so much that QE expects it these days. The QE folks in my office hear of a firefox errata coming and start praying that the arches behave this time. Because any delays for me means delays in getting packages to them for testing. I run into some odd issue on non-x86 arches every to every other release, though I will admit that firefox has not failed while building ppc for quite some time now.
I realize that I need to support these arches for RHEL anyway, so there is some priority to fixing/working around compiler issues, but there is no reason to delay Fedora fixes while we get things resolved.
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
