Author(s):	Russell Currey
Location	Room 8
Date	jan Fri 17	Days Raw Files
Start	10:45	First Raw Start	error-in-template
Duration	0:45:0	Offset	None
End	11:30	Last Raw End
Chapters
Total cuts_time	None min.

https://lca2020.linux.org.au/schedule/presentation/106/
raw-playlist raw-mp4-playlist encoded-files-playlist mp4 svg png

assets release.pdf The_magical_fantasy_land_of_Linux_kernel_testing.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:	The Linux kernel does a lot of stuff, and runs on a lot of stuff. I'm sure we can all agree that this is a good thing, however the matrix of stuff it does and stuff it runs on continues to get bigger and bigger! With thousands of commits each release and a widely distributed and decentralised developer community, how do we make sure that the kernel still works on everything, does everything it's supposed to do, and hasn't slowed anything down in the process? In this session we're going to be looking at the huge variety of automated kernel testing projects to figure out what's going on, covering a variety of different areas, including: - per-patch CI to quickly test if a developer broke something, - built-in kernel selftests and the push for more unit testing, - performance testing of the kernel itself and userspace, - regression testing, especially for known security issues, - hardware testing, from enormous 512TB machines to huge farms of small SOCs. By understanding the huge web of projects out there, hopefully we can figure out how we could get more stuff done more effectively. It's a difficult problem in the broad and uncoordinated space of Linux kernel development, but it's all in pursuit of the dream: the magical fantasy land - with no duplication of code or effort, where everything is tested, where everyone knows where everything is, and where bugs are never introduced again. markdown
Comment:	production notes