> Linus has broken the build more recently than I have.

Even taking your claims at face value (which from this thread alone is a heck of a leap) I'm baffled by the way you believe this holds any relevance.

I mean, the kernel project has in place a quality assurance process designed to minimize the odds of introducing problems when preparing a release. You were caught purposely ignoring any QA process in place and trying to circumvent the whole quality assurance process and sneak into a RC features that were untested and unverified.

There is a QA process, and you purposely decided to ignore it and plow away. And then your best argument for purposely ignoring any semblance of QA is that others may or may not have broken a build before?

Come on, man. You know better than this. How desperate are you to avoid any accountability to pull these gaslighting stunts?

I would also like to know what the QA process is, because all I can see is basically 'linus pulls in changes in the merge window, checks that the basic stuff builds, then releases the RCs and some people do some checks in some way, varying from users on the bleeding edge, some people doing manual verification on specific hardware and use-cases, and maybe some automatic tests and analysis that are not really documented anywhere, and the end result is some bug reports'. Is there anything more co-ordinated than that? Like some description of what is tested and how, or an explicit green indication that those tests have actually happened and a policy on what would hold up a release?

Please, tell us about these wonderful QA processes the kernel has.