Greg K-H

If you're involved in fuzzing on any side (i.e. also developers) I highly recommend this talk about non-technical aspects of making fuzzing useful part of dev process ("ninja style" deployment, "that's not a bug", fuzzblockers, priorities, expectations). I am guilty of all DONTs.https://twitter.com/mozdeco/status/1303998253336326144 …

Fun fact: first email from @mozdeco in my inbox is dated by Feb 2013 and is about deploying ThreadSanitizer on Firefox (obviously "benign data races" :): https://groups.google.com/g/thread-sanitizer/c/nbuuWSo2xzc/m/o45sYMOSNC0J …

But I have a Q: so how do you call a meeting with all #linux kernel developers and management? and how do you allocate resources on all kernel dev's side? and how do you deliver just any bit of info to all of them (current/future/inactive)? make all of them agree on something?

There is no "management" for kernel developers, you know this :)

Yes, thus Q: how "setup meeting w/ all devs+mgmt,get buy-in & time allocated" recommendation should be adopted for projects like kernel? Such changes are notoriously hard even in corp env, if they are double-notoriously hard, lots of possible improvements aren't happening.

You don't approach it from a "we must get a mandate from above" method, that's not how successful open source projects work. To try to do that, would only result in resistance and avoidance as no one likes to be told what to do.

Instead, present an option that is so compelling and useful that anyone who did not take advantage of it would be wasting time and effort.

Like the adoption of git for kernel development, no one was forced, but almost everyone changed once they realized it made their life easier. But even then it took 5+ years for people to do that. Change is slow, for good reason.