Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla blues"

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

 





On 10/2/22 12:18, Theodore Ts'o wrote:
On Sat, Oct 01, 2022 at 02:58:04PM +0000, Artem S. Tashkinov wrote:

My expectations are actually quite low:

* A central place to collect bugs (yeah, bugzilla)
* Proper up to date components (they don't change too often, so there's
not a lot of work to be done - you can refresh them probably every 12-24
months and it's gonna be totally OK)
* An ability to CC the relevant people/mailing lists (this is the only
serious missing feature)

That's it. It's a billion times better than random emails sent to random
mailing lists. Signing up once is easier that to keep track of whom and
where you've emailed or not. And of course it's a ton lot easier to find
the existing bug reports.

First of all, some of the components do CC the relevant mailing lists
automatically.  And this is the part of Bugzilla which is hand-hacked
and has no, zero, nada support upstream.  I'll defer to Konstantin
about how easy it is to keep that working.

Secondly, not everyone is happy with getting an e-mail message sent to
a mailing list that has a lot of bugzilla metadata associated with it,
and depending on how they respond, the response might not make it back
to bugzilla.

I've mentioned it a dozen times already - you're unhappy with emails
from bugzilla? Go there and unsubscribe. It takes a minute and we're
talking as if it's the actual issue we are dealing with. It's not.
Bugzilla maintenance and its up-to-date status are the issues.


Finally, in the absense of someone to actually close bugzilla entries
and do other necessary grooming, the bugzilla database will rapidly
become useless --- in which case, you might as well have a web form
that just helps the user send e-mail to the mailing list, and hope it
doesn't become a SPAM magnet.

The current ill-maintained semi-functional bugzilla has proven to be a
ton more useful than random mailing lists no sane person can keep track
of. Bug "reports", i.e. random emails are neglected and forgotten. LKML
is the worst of them probably.


Bugzilla as it is works nearly perfectly. We have a number of developers
who don't want to touch it or get emails from it - it's their right.
However it would be madness to take it from users. That will make filing
and following up on bug reports an absolutely poor experience for
absolute most users.

At the moment, developers aren't following up on the bug reports.
There is some debate as to why.  Is it because users who can't figure
out how to send e-mail, and who send web-form based e-mails send low
quality bug reports that can't be easily responded to unless someone
is paid $$$ and/or has the patience of a saint?  Is it because
components aren't being gatewayed to mailing lists?

This is not always true, some of them do, some of them actually check
new bug reports and do a tremendous job at helping people, e.g. Mario
Limonciello who helps resolve bugs which are not even his direct
responsibility. BTW, I'll now CC him since he's so active over there.
Would be great if he chimed in.


And if we force developers to get Bugzilla spam whether they want it
not, and they said, "absolutely not", is it there right to have the
mailing list gateway disabled --- and if so, what does that do to the
user experience?  Thats basically the situation we have right now.

As I've said many times already: bugzilla must be an opt-out, not opt-in
experience/option.

Let's subscribe the past six months of developers using git commits and
if someone doesn't like getting emails they go to the website and
unsubscribe _once_ which takes a minute. This is a non-issue I've no
clue why we're dwelling on it.

Let's operate with some examples:

Bugzilla gets around two dozen bug reports weekly which encompass at
most thirty emails, which equals to four emails daily on average.

LKML alone sees up to a hundred emails _daily_.

Getting worked up about it? I'm dumbfounded to be honest.

Best regards,
Artem




[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