Re: [PATCH v1 (RFC)] docs: discourage users from using bugzilla.kernel.org

[Artem S. Tashkinov]

Hello,

Let me express an utter dissatisfaction and even contempt for this proposal.

1. Absolute most open source projects are managed via bug trackers, I
see no reason the Linux kernel should be exempt

2. LKML has historically created/used for for posting patches and
discussing kernel features. Of course, major bugs have been discussed
and resolved as well but mostly among _core_ Linux hackers who are
_subscribed_ to it and _participate_ in it which is _not_ the case for
absolute most kernel developers nowadays.

2. Even though many kernel maintainers and subsystems express their
desire to manage bug reports via e-mail it's an utterly preposterous,
nonworking and broken idea for the following reasons:

2.1 Tons of messages in various kernel related mailing lists have zero
replies and are not acted upon in any way or shape

2.2 There's no sense of accountability, no way to see what are the
current issues, what's resolved or not

2.3 Users have an extremely hard time looking for bug reports which are
spread along God knows where

2.4 It's impossible to follow up on such messages except when you were
subscribed to the original mailing list, IOW just impossible

2.5 It's extremely difficult to collaborate since e-mail totally sucks
when it comes to long discussions.

Consider this bug report: https://bugzilla.kernel.org/show_bug.cgi?id=204807

Over a hundreds of messages, multiple attachments, a flow of ideas and
patches - how on Earth this can possibly be replicated using email? Why
does pretty much no other project aside from maybe Debian has this
peculiar workflow?

2.6 You're under the impression that user will read this wonderful
document. They will not, they will google for "report bug linux kernel"
and find bugzilla.kernel.org

2.7 If you venture to work as a kernel hacker you're expected to be
_responsible_ for your code. If you submit a patch and disappear that's
going to be more a disservice to the community rather than actual help.

---

Let me continue.

Here's something which is really bad for bugzilla.kernel.org:

People _continue_ to file bug reports for graphics drivers in Linux and
we don't even have proper components for it, only

Video (AGP) - What? AGP has been dead for a decade.
Video (DRI - Non Intel)  - what? Isn't it an X.org's feature, not kernel's?
Video (Other)

This is a complete and total clusterjoy.

I don't think it's too difficult:

1) At least update Video components, let's say, have Intel, AMD, Nouveau
and Other - there's a ton more but these will suffice. Most others are
for mobile/embedded and to be honest their users are unlikely to ever
touch this bugzilla.

2) To integrate the first three with https://gitlab.freedesktop.org/drm/
and automatically crosspost over there.

3) Someone has to actually read all the bug reports and check whether
they are relevant, filed properly, filed under the proper category and
whether they should be closed.

4) And what's with the front page which says to use Distros bugzillas? I
smell some BS in this statement because among all distros maybe RedHat
and Ubuntu have the people to deal with kernel issues, and all others
simply don't in any capacity. Bugs filed in distros bug trackers will
linger for ages, get zero attention (it's my experience with Fedora and
even RHEL) and be closed since _no one cares_ and no one is experienced
enough.

I really hate how this bugzilla is treated as an afterthought which no
one really cares about. If no one cares, why does it exist in the first
place? Let's shut it down then. Let's move to mailing lists and create a
total mayhem of lack of accountability. "Bugs? Sorry, I've had no time
to read emails".

If it exists and serves some purpose, why Products and Components are
stuck as if they were created in 1995, not in 2021?

AFAIK kernel.org is a The Linux Foundation project. The organization is
heavily sponsored by tons of companies. It would be great if we had a
person actually invested in bugzilla.kernel.org

---


Best regards,
Artem