LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Thorsten Leemhuis <linux@leemhuis.info>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	ksummit-discuss@lists.linuxfoundation.org,
	workflows@vger.kernel.org,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Subject: RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions
Date: Mon, 22 Mar 2021 16:18:14 +0100
Message-ID: <613fe50d-fc9c-6282-f1f3-34653acb2ee9@leemhuis.info> (raw)


Lo! I want to provide users with an easier way to search our multitude
of mailing lists for reports about issues (aka bugs), as reporting the
same kernel problem multiple times has known downsides for everyone
involved. That's why I propose to create this new mailing list:

linux-issues@lists.linux.dev

Developers and users reporting or handling issues then can CC it or
search it via lore. But this will only fly if the idea has buy-in from
at least the core kernel maintainers, to make sure they and the
developers actually use it. That's why I'm looking for feedback with
this mail and also CCed ksummit-discuss, as that's the easiest way to
make sure maintainers get aware of this idea and can raise their voice.


Note, there is a second reason why ksummit-discuss is CCed: another
reason why I want to create this new list is making it easier to find
and track regressions reported to our various mailing lists (often
without LKML in CC, as for some subsystems it's seems to be custom to
not CC it). Back on the maintainers summit in 2017 it was agreed to
create a dedicated list for this purpose
(https://lwn.net/Articles/738216/). I even requested a
"linux-regressions@vger.kernel.org" a while later, but didn't hear
anything back; and, sadly, about the same time I started having trouble
finding spare time for working on regression tracking. :-/

But I soon will get back into that area:
https://linux-regtracking.leemhuis.info/post/hello-world/ Hence it's a
good time to prepare some groundwork for that. But these days I think
having something like linux-regressions@lists.linux.dev might be over
engineered, at least for now: a linux-issues@lists.linux.dev with a
simple "[regressions]" in the subject will suffice, as that tag is
something a lot of people are used to already. And if we think we need
that list we can still create it in the future. Or what do you folks
think about it?



We can obviously bikeshed about the name for the list. I'm sure some
people will prefer to use "bugs" instead of "issues" there. I propose
"issues" for now, because the new text I've written about reporting
kernels issues/bugs uses the word "issues" in the filename, the title,
and the body while avoiding "bug" (see
Documentation/admin-guide/reporting-issues.rst or
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
). I chose this approach as users are dealing with issues that might or
might not be bugs in the kernel. We discussed this before above text was
merged, but in the end stayed with issues:
https://lore.kernel.org/linux-doc/b5f5dfad-07bb-b518-0dff-3aa340333046@infradead.org/
BTW, creating this list will partly solve the second of the "FIXME
warning boxes" currently left in that text (two others are solved by
patches that are under review currently).


The question "Why not simply LKML" will likely pop up, but the thing is:
searching for reports there will often turn up patches that improve the
kernel and don't fix anything. That makes it hard to find issue reports,
especially for users that are not used to deal with mailing lists and
their archives.

And yes, I'm quite aware that searching linux-issues@lists.linux.dev
list obviously won't turn up reports that are filed in
bugzilla.kernel.org or some other bug tracking tool. That's okay, as the
reporting-issues.rst tells users to look in those places as well.

Another "and yes, I'm quite aware" note: sure reporting issues/bugs by
mail has downsides and maybe instead of creating yet another mailing
list it would be better if all the kernel issues would be reported to a
central place like bugzilla.kernel.org. But that tracker doesn't work
that well currently, as quite a few of the issues filed there afaics
never reach the people that need to be handle them. I don't see that
changing any time soon (we had a discussion about this recently:
https://lore.kernel.org/linux-doc/20210111194822.4kvl2tx24anyu23k@chatter.i7.local/
).

Creating a new mailing list for issues OTOH is something that can be
done quickly and easily to improve the situation without too much
hassle. That's why that's my plan currently, unless the discussion that
hopefully evolved due to this mail leads to something better. :-D

Ciao, Thorsten

             reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22 15:18 Thorsten Leemhuis [this message]
2021-03-22 16:55 ` [Ksummit-discuss] " Lukas Bulwahn
2021-03-22 19:49   ` Thorsten Leemhuis
2021-03-22 17:16 ` Konstantin Ryabitsev
2021-03-22 17:57   ` [Ksummit-discuss] " James Bottomley
2021-03-22 18:34     ` Eric Wong
2021-03-22 18:55       ` Thorsten Leemhuis
2021-03-22 19:20         ` Konstantin Ryabitsev
2021-03-22 18:32 ` Linus Torvalds
2021-03-22 19:25   ` Thorsten Leemhuis
2021-03-22 21:56     ` [Ksummit-discuss] " Theodore Ts'o
2021-03-23  8:57       ` Thorsten Leemhuis
2021-03-23 15:01         ` Konstantin Ryabitsev
2021-03-23 19:09           ` Thorsten Leemhuis
2021-03-23 18:11         ` Theodore Ts'o
2021-03-23 18:51           ` Thorsten Leemhuis
2021-03-23 14:57     ` Luis Chamberlain
2021-03-23 16:20     ` Steven Rostedt
2021-03-23 16:30       ` [Ksummit-discuss] " James Bottomley
2021-03-23 21:43         ` Konstantin Ryabitsev
2021-03-23 23:11           ` Eric Wong
2021-03-23 18:07       ` Theodore Ts'o

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=613fe50d-fc9c-6282-f1f3-34653acb2ee9@leemhuis.info \
    --to=linux@leemhuis.info \
    --cc=gregkh@linuxfoundation.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lore.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git