Re: Planned changes for to reduce the "Bugzilla blues"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 10/2/22 21:07, Linus Torvalds wrote:
On Sun, Oct 2, 2022 at 1:56 PM Artem S. Tashkinov <aros@xxxxxxx> wrote:

I just want a bugzilla where I can CC _any_ developer _if_ and _only if_
they are willing to work within its confounds. That's it.

Guess what that "add develooper to the Cc" is called?


What you do is fill in the bugzilla entry with all the data you want.

Then you use email to inform people about it.

Put enough data in the email that the developer knows whether it's
even worth looking at the bugzilla entry or not. Don't just put a link
to the bugzilla. Most developers will just go "oh, this looks like
spam"., Put the overview in the email, enough information that the
developer can go "Ahh, this is worth my time", _and_ the link to

That could work or could not work because e.g. my email provider,, is blocked by a large number of companies/people because ...
reasons. If I'm lucky I get a reply: "Mail cannot be delivered because
reasons". Sometimes I get no reply, there's no way of knowing your email
has been delivered.

More importantly there's no way of knowing an email has been read or
seen. You perfectly know that.

An email from an official bug tracker, not some random Joe on the
Internet? That will less likely be considered SPAM, fake, scam, etc.
Some people have no idea that kernel developers prefer to deal with
plain text and may simply ignore HTML messages which have long become
the default for many email providers.

You're asking people to know in advance the kernel developers email
etiquette or know English well enough to communicate your problem.
Bugzilla doesn't need that. You can dump whatever you want however you
want even in your native language.

That gives you exactly what you ask for: you can CC _any_ developer.
And it doesn't force the developer to have to go to some bugzilla web
interface unless the developer thinks it actually adds value.

This is *literally* how I end up using bugzilla. As you say, I
actually do end up looking at bugzilla entries in the end, but I only
do it once it has hit my mailbox first, and I have some fairly good
indication that it's worth my time to look at it.

And yes, for some projects and for some developers you can do that
email integration from within bugzilla itself. That's how people reach

But this is exactly the kind of part of bugzilla that is a TOTAL
HORROR-SHOW to manage, and it's impossible to expect every developer
to be somebody that can be listed on bugzilla, without bugzilla
becoming a prime way to send spam.

There are many easier ways to SPAM people ;-) I've not heard of anyone
complaining about SPAM coming from the kernel bugzilla yet.

Which is why in the general case, you really should consider email to
be the "lingua franca" of kernel development communication.  It
doesn't have the fundamental limitations and management issues that
bugzilla has. If you want to add more people to the Cc in an email,
you just do it.

Attention, Linus, the problem is attention.

Once something is filed in bugzilla, it's public, it's easily
accessible, it can easily be found, you can easily add new info.

Emails? You've flown to Japan to a conference for a week and you have
much better things than to check any email updates. A week worth of
emails have suddenly become worthless.

Here's yet another issue, how would you send a follow up if you don't
know the reference ("References" email field)? Instead of a follow up
it'll end up being a new unrelated email.

Lastly, if you're on bugzilla, your email address is a lot less likely
to be leaked. Bugzilla doesn't publish emails. Public mailing lists are
used to collect email address for SPAM databases all the time.

Since kernel developers/Linux users love privacy so much, I guess it's a
good argument for Bugzilla, not against it. Many email clients/providers
leak a ton of information about you (email client version, timezone,
even IP address) left and right.


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux