Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Squashing bugs!

[Laura Abbott <labbott@redhat.com>]

On 6/3/19 6:42 AM, Jan Kara wrote:
>> What I want to find is a way to fund on-going work in this area. It
>> just does not appear to be working to find funding within various
>> companies to do this kind of sustained bug-hunting. It's a bit of a
>> resource conflict: if a company has kernel developers on staff they
>> tend to want to have them focused on "new things".
> Well, not necessarily only "new things". Distros have kernel people that do
> bugfixing but the most focus naturally goes towards bugs customers are
> likely to get exposed to. Triaging through syzbot reports when you have
> enough bugs your customers actually hit thus does not look very appealing
> :)  But this goes back to your idea of automated way of classifying bug
> priority. Unpriviledged user triggerable kernel oops in MM is going to get
> more attention than init namespace root triggerable one in some random
> old driver (which is likely to bitrot for long and that's just a reality of
> limited resources)...

Part of it is also a matter of how much time you want to spend. There are
some bugs I can spend 30 minutes looking at and know I can either come up with
the proper fix or write up a report that's likely to get fixed by a maintainer.
Then there are others which look like they could be solvable with more time
that I don't have. The long tail of low priority bugs are the ones that
would be really good candidates for interested community kernel developers
to spend some time on.

I'll also just state straight out that just doing bug triage gets very tedious
after a while. It's valuable work but after a while you aren't actually growing
your skills very much. This might be something that would be best as a yearly
contract position. Of course, people who aren't me might also have more
patience for it long term :)

Thanks,
Laura