On Thu, 2022-09-29 at 12:22 +0000, Artem S. Tashkinov wrote: > Let me be brutally honest here, if you're working on the kernel, > specially for a large company such as e.g. Intel, you're _expected_ > to address the issues which are related to the kernel component[s] > you're maintaining/developing otherwise it's not "development" it's > "I'm dumping my code because my employer pays me to do that". That > also means you're expected to address bug reports. > > It's correct I've tried to help people with bug reports posted on > bugzilla.kernel.org but it's a tough task considering that absolute > most kernel developers are not signed up, thus most bug reports are > never seen by respective developers. The never seen/never responded to metric is rather bogus. The sad fact is that a lot of bug reports aren't actionable, meaning the reporter can't give a reproducer and also can't easily test patches sometimes by luck the maintainers can work out what the issue is but a lot of the time they have no idea. Then there are ton's of bug reports with responses like "I think xxx commit fixes your problem, can you test it" for which the conversation dies there. There's also the thundering herd problem: some bugs get reported by many different people (as different bug reports) but usually the subsystem only engages with one to fix the issue. In theory bugzilla can mark the latter as dups, but that requires someone to spend an enormous amount of time on evaluation and admin. That's not to say we can't improve our process, it's just to set expectations that we're never going to approach anywhere near a perfect bug process. Most of the improvements that worked so far involve having someone coach bug reporters through the process of either testing patches or reproducing the problem in a more generic environment ... which I think most people would agree can't really fall wholly on maintainers. Regards, James
