Yes. Always involve a human check before sending to specific individuals.
> The reality is that no human looks at all of them and triages
> all of them.
Of course. Therefore, we need people who play "frontend" role and people
who play "backend" role. The former (Alice in the example above) is a
"dispatcher" who interprets syzbot reports and decides whom to notify.
Currently syzbot is making decisions based on MAINTAINERS file. But
you are missing that persons listed there are generally too busy to
look at details. Reports which do not tell "what is happening" and
"why it is happening" at a glance are not useful for them. If I recall
correctly, many weeks ago, you were discussing with Linus regarding
what should be done before reporting (e.g. bisect).
> What happens if nobody looks at a report? It is not
> mailed at all? Who are these special people triaging all reports?
Only "frontend" people will look at reports from syzbot, and
"backend" people will triage reports from "frontend" people.
> are they different from all kernel developers? Why can't all kernel
> developers do this triage after the report has been mailed?
It is impossible for all kernel developers to read all mails.
That's why we need to use roles, like I said that I have worked at a
support center and experienced both "frontend" role and "backend" role.
> If all
> kernel developers can't cope will all bug reports, how can we expect a
> hundreds times smaller group of people will be able to do this work?
We can do this work if we use roles. And I'm rather working as "frontend".
For example, I interpreted a report from syzbot and forwarded to authors
which caused that bug as
> If we delay a report even by few days, it can actually cause a
> negative effect if the bug was already reported by somebody else
> (duplicate unuseful emails).
If we do want to send a report automatically, it should be sent to only
one mailing list. That would be either LKML or syzbot specific one
(for allowing people to find using Google search).
> Or if syzbot has already mailed one
> incarnation of a bug and kernel developers are spending time debugging
> it, but we did not mail another, more useful, incarnation of the same
> bug because we are holding it internally and don't see the relation.
> Taking into account that most of the time reports are sent to relevant
> people, any additional delays can actually be net loss.
I disagree. Mails sent to maintainers are seldom useful; again, they are
too busy to examine the bugs. Mails sent to authors which caused that bug
will be useful. Thus, sending to mailing list for Google search would be
fine, but sending to auto-generated individuals is bad.
> What I am getting at: adding people to CC after the report has been
> sent is trivial and already works (just add them to CC). Removing
> people from CC is currently missing, but very few people complained,
I am the one who is complaining about lack of ability to unsubscribe.
> guess kernel developers are used to lots of semi-relevant emails.
Are they reading semi-relevant emails?
I don't read threads which are not actionable for me.
> This all also looks exactly as a bug tracking system. See here you can
> add/remove people to CC, set assignee, note statuses and keep all
> history in one place:
> But implementing yet another bug tracking system is huge amount of
> work, it requires much more resources than we have now. And in the end
> almost nothing of this is specific to syzbot, so solving this in the
> limited context of syzbot looks wrong.
As a "frontend" people, what I want is not a bug tracking system like Bugzilla.
What I want is a column for holding free-text memo (like "sticky", or "Google
Spreadsheet") rather than structures for choosing from checkbox/combobox (for
finding from many thousands of bugs).
The "backend" people can use Bugzilla etc. if the bug is complicated enough to
require a bug tracking system. There are too many bugs left unnoticed in bug
tracking systems. I don't think that registering to bug tracking systems from
the beginning is a good choice. More trivial bugs, more difficult to manage