Since this seems to be a common misconception I wanted to write (once again, I think I did this before, too) about what QA actually means for Gentoo and why I’m spending so much time, effort, and – directly and indirectly – money on the tinderbox idea (remember that the maintenance of the system is up to me, and that it costs to replace disks, get bigger disks, … I also start considering upgrading the CPUs to see if I can reduce the time needed for the builds…).
As people following me on identi.ca already know, last night me and Daniel Robbins had a divergence of opinions on who has the higher QA. I am absolutely unconvinced by his arguments, that in my informed opinion are just mirror-climbing. By his replies, it seems like heshould have an higher QA standard because stuff always build, if needed with hacks like unsetting (not filtering, not counteracting, unsetting) user LDFLAGS.
I strongly disagree; as it’s often mocked up with the phrase “it builds, ship it!”, software that builds doesn’t really mean it works properly, as it should be clear by the multiple test failures that I found. And indeed for this reason, there are a series of QA tests in Gentoo that actually make stuff fail from building; it’s way too easy to “fix” the packages that fail because of that by disabling the safety measures we have implemented; yet that’s what Robbins says is the “quick fix” that improves his QA over ours.
I do agree on the fact that uses shouldn’t be seeing the failure if possible, that’s why I do use emake -j1 in ebuilds but I also do that with open bugs ; the idea is that once we know there is a problem we might temporary ignore it. But that works for stuff like parallel make or --as-needed; compiler errors, especially those related to _FORTIFY_SOURCE and similar, need to be fixed not worked around (thus why I don’t like using casts either and I request users to submit proper patches if they want).
There is a tight correlation between strictness and QA; and while Gentoo really doesn’t seem to achieve the proper QA and user experience all over the place (but I want to thanks Thilo, Samuli and Ryan for their huge efforts lately, and not just lately), we are improving our QA processes. And still they are better than Robbins’s in my opinion.
Oh and by the way this does not mean I like the Debian way of handling QA with their eternal releases (yes I know they are now trying to solve that by using time-based releases, that doesn’t make it nice anyway). This because we had quite a few packages that ere broken by Debian patches, or that Debian accepted just fine while being totally broken in code and build system (hfsplusutils anyone?).
And at the same time, I don’t really pretend that all software has the same QA levels; sometimes you have to break stuff around to be able to get some improvement for the others too, so I do accept projects like funtoo that want to try stuff without having proper QA processes or loosened QA levels. My only problem is when people like Robbins try to sell for QA what really is a bunch of mixed hacks around the place.