Author(s):	Russell Currey
Location	C1
Date	jan Tue 22	Days Raw Files
Start	15:50	First Raw Start	15:23
Duration	0:25:0	Offset	0:26:16
End	16:15	Last Raw End	16:16
Chapters	00:00
Total cuts_time	23 min.

https://2019.linux.conf.au/schedule/presentation/234/
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf Patching_through_the_snow_decentralised_kernel_CI_on_every_patch.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:	--------- borked edit encode push to queue post richard review 1 email review 2 make public tweet to-miror conf done
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	Unknown Yes No has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	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. markdown
Comment:	production notes