archive mirror
 help / color / mirror / Atom feed
From: "Artem S. Tashkinov" <>
To: Linux Kernel Mailing List <>,
Subject: Re: [PATCH v1 (RFC)] docs: discourage users from using
Date: Fri, 5 Nov 2021 14:36:51 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


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:

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

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

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'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
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

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 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


Best regards,

  parent reply	other threads:[~2021-11-05 14:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-10 12:10 [PATCH v1 (RFC)] docs: discourage users from using Thorsten Leemhuis
2021-01-11 18:14 ` Randy Dunlap
2021-01-11 18:55   ` Thorsten Leemhuis
2021-01-11 23:42     ` Randy Dunlap
2021-01-12 17:34       ` Thorsten Leemhuis
2021-01-11 19:48 ` Konstantin Ryabitsev
2021-01-12 19:09   ` Thorsten Leemhuis
2021-01-13 11:17     ` Jani Nikula
2021-01-14 19:18       ` Konstantin Ryabitsev
2021-11-05 14:36 ` Artem S. Tashkinov [this message]
2021-11-05 14:42   ` Matthew Wilcox
2021-11-05 14:59     ` Artem S. Tashkinov
2021-11-08 11:43   ` Jani Nikula
2021-11-08 12:03     ` Artem S. Tashkinov
2021-11-08 13:00       ` Jani Nikula
2021-11-08 13:17         ` Artem S. Tashkinov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).