Linus has broken the build more recently than I have. (In the time since bcachefs went upstream, we've both done that once, that I've seen).

Linus doesn't seem to believe in automated testing. He just seems to think that there's no way I could QA code as quickly as I do, but that's because I've invested heavily in automated testing and building up a community of people doing very good testing and QA work; bcachefs's automated testing is the best of any upstream filesystem that I've seen (there's a whole cluster of machines dedicated to this), and I have people running my latest branch on a daily basis.

Nearly all of the collaboration just happens on IRC.

For big changes I wait for explicit acks from testers that they've ran it and things look good; a lot of people read and review my code too, it's just typically less formal than the rest of the kernel.

▲

righthand 3 days ago | parent | next [-]

Yeah but you don’t get to make the calls. Linus does and your “well kernel daddy does it too” and “actually I’m doing it better than my critics understand” don’t play well with the kernel daddy (or really any bdfl). Do you not see your comment as dismissive?

All your comments are dismissive of the criticisms so far and you’re shrugging your shoulders as to why.

It’s great you’re able to reason and defend yourself but Linux as a whole is larger than you and refusing to submit to their ways will make technology move no where.

▲

motorest 3 days ago | parent | prev [-]

> 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?

	▲	rcxdude 2 days ago \| parent \| next [-]
		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?
	▲	koverstreet 3 days ago \| parent \| prev [-]
		Please, tell us about these wonderful QA processes the kernel has.