Just like the development of the kernel itself, its testing is all over the place. There are countless public kernel testing projects and probably even more private ones, with hardware vendors testing what works on their own machines and maintainers automating checks for what should go into their trees. If you're a developer, you probably don't know about any of this unless someone directly tells you. The granularity of running these tests is similarly all over the place: many test environments just look at mainline, many look at linux-next or trees of specific maintainers, and some run on every patch, like the Intel 0-day bot. If you're a developer, unless your patch doesn't compile, you're probably not going to hear about it. Projects that use pull requests on GitHub as a code submission method have it easy: a developer sends a PR, some CI system magically tests it, and developers and maintainers alike can quickly see if the code has issues. The value in continuous integration is about quick feedback to the developer, and saving precious time of reviewers and maintainers. This is where snowpatch comes in, using Patchwork as the publicly visible platform for test results on patches. Tests can come in from anywhere, even an internal lab of a hardware vendor, and have their results published for the world to see within minutes of a patch being sent. It's the closest thing we have in the world of mailing lists to the simplicity of the GitHub workflow, it's easy to get going, and it can function as decentralised as the rest of kernel development. We're going to cover how snowpatch works, why it's useful, what we're doing with it currently, and look to the future to determine just how much we could tell the world about a patch, only minutes after it's been sent. Linux Australia: http://mirror.linux.org.au/pub/linux.conf.au/2019/c1/Tuesday/Patching_through_the_snow_decentralised_kernel_CI_on_every_patch.webm YouTube: https://www.youtube.com/watch?v=IRtBqPNsM9g