Greetings,
I'd like to attend this year's kernel summit.
I may talk about the technical challenges and trade-offs on writeback and memcg
and IO controllers with anyone interested, perhaps in some breakout session.
And I would like a chance to talk about doing kernel tests in a timely fashion:
whenever one pushes new commits to git.kernel.org, build/boot/stress tests will
be kicked off and possible errors be notified back to the author within hours.
This fast develop-test feedback cycle is enabled by running a test
backend that is able to build 25000 kernels and runtime test 3000
kernels (assuming 10m boot+testing time for each kernel) each day.
Just capable enough to outrace our patch creation rate ;-)
On an average day, 1-2 build errors are caught in the 160 monitored kernel trees.
The runtime tests are still in active development and I'd like to ask for your
inputs on best practices and test methodology for every possible subsystems. The
target is to catch _common_ bugs early, so that a) less people are impacted and
b) when bisecting a specific bug, it's not confused by unrelated but common bugs.
I'll need your help and feedback to run this system well. In return, you'll be
able to take better advantage of it, once got some basic understandings on how
it runs for you. Hopefully, someday, these diligent machines may bring a little
happiness to our stressed life. As is the secret of happiness for us kernel
developers: if a bug is caught and fixed in my own tree, Cheers! Otherwise if
the bug has been merged in the upstream tree, OMG, it's out of control and may
well impact 1000 commits after it.. regrets, sadness, guilty, embarrassments,
bad commits with my Signed-off-by carved in stone, forever ...
Thanks,
Fengguang