Re: Policy regarding linux-next only changes

On 2026/07/24 23:51, Theodore Tso wrote:
>> In other words, the interest (by the upstream Linux kernel community) on
>> fixing kernel bugs which syzbot found are decreasing. This is a deadlock
>> situation, and just saying "Not my business." is not helpful.
> 
> Perhaps if Syzbot could be improved so we can be more selective about
> which bugs are worth fixing, it might actually be better for the
> kernel's quality.

One non-critical bug in some module can prevent other critical bugs in
different modules from being discovered. We can't expect that syzbot can
find only critical bugs, without an effort to fix non-critical bugs.

> 
> But if the goal is to get ourselves to zero bugs, or zero syzbot
> reported issues, that's not a goal I can get behind.  It certainly
> isn't something my management chain isn't willing to support that
> goal, and it's NOT going to happen out of my own personal time.

https://www.youtube.com/watch?v=qrBVXxZDVQY or
https://events19.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf 
says that the goal is "Reduce bugs/release 100x: 20'000 -> 200".

I know that individual maintainer cannot afford looking into all patches
that involve syzbot. A maintainer has the permission to accept/reject
patches on an area he/she maintains. The problem is that a maintainer
who has the permission to accept/reject patches tends to become defunctional
when syzbot is involved. What actions can the Linux kernel community take
in order to address this problem (instead of just ignoring developers
who are trying to fix bugs)?