ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Andrew G. Morgan" <morgan@kernel.org>
To: Thorsten Leemhuis <linux@leemhuis.info>
Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	users@kernel.org,  ksummit@lists.linux.dev
Subject: Re: slowly decommission bugzilla? (was: Re: kernel.org tooling update)
Date: Thu, 26 Feb 2026 06:40:23 -0800	[thread overview]
Message-ID: <CACmP8UKXwW5smbnqEcymxND0e6eLKuOTWvEtxHSU2LLH9Wn4ow@mail.gmail.com> (raw)
In-Reply-To: <b93eae05-5e40-42f0-8256-d46d411008a4@leemhuis.info>

Just want to say that the 'libcap' needs for bug reporting are quite
manageable and I find are adequately handled by its component in the
kernel.org bugzilla. If we do migrate to something else, my only
request would be that we support some redirection mechanism - old
commit messages that refer to specific bug URLs can find their way to
wherever the new bug tracker has imported them.

Thanks

Andrew

On Thu, Feb 26, 2026 at 12:45 AM Thorsten Leemhuis <linux@leemhuis.info> wrote:
>
> On 12/10/25 05:48, Konstantin Ryabitsev wrote:
> >
> > ### Bugzilla
>
> Lo! I wonder if we should slowly and publicly start decommission
> bugzilla in areas where it's not working well today. I have a few
> reasons for that:
>
> > It may be time to kill bugzilla:
> >
> >     - despite periodic "we're not dead yet" emails, it doesn't appear very
> >       active
> >     - the upgrade path to 6.0 is broken for us due to bugzilla abandoning the
> >       5.2 development branch and continuing with 5.1
>
> * It looks like we will decommission Bugzilla anyway, and a replacement
> is afaics likely quite a while (years?) away -- so what is there now
> will likely be kept running for a while.
>
> * Bugzilla at the same time since a few years now is known to not
> working well, as many reports (including good ones) never get a reply --
> among others because the list of products/components is not kept in
> sync, so many reports never reach the right developers (see
> https://lwn.net/Articles/910740/ and the second and third links there
> for the more complete backstory; things are afaics round about the same
> from what I see when occasionally looking at bugzilla for regression
> reports worth forwarding by mail – and that is really hard to watch, as
> it feels bad to see people spending time on something that is most
> likely not leading to anything).
>
> * Statements like "Dear Deity, I do wish kernel MM bugzilla would just
> go away. Sigh." (akpm recently in
> https://lore.kernel.org/all/20260206121151.dea3633d1f0ded7bbf49c22e@linux-foundation.org/)
>
> "Slowly start publicly decommissioning Bugzilla" could look like this:
>
> * Prevent new bugs from being submitted against products/components
> where the developers/subsystems are not engaging in Bugzilla (either
> directly or through replies by mail). That would make people like akpm
> happy afaics. I'm willing to help with talking to subsystems and
> adjusting settings in bugzilla.
>
> * Create a new front page that tells users that they most likely are in
> the wrong place. The text could look like this:
>
> """
> Welcome! Note: The kernel.org bugzilla is slowly being decommissioned!
>
> This bug tracker is a kind of failed experiment, which at the same time
> still is useful sometimes and thus for now kept alive. Due to this and
> how vendors utilize the Linux kernel, you are most likely in the wrong
> place to report your bug.
>
> To find the right place, check the Linux kernel's [MAINTAINERS
> file](https://docs.kernel.org/process/maintainers.html). Most of the
> time it will tell you to report bugs by email with some mailing lists in
> CC. Bugs with all the kernel's modern graphics drivers, on the other
> hand, [must be submitted to a Gitlab
> instance](https://gitlab.freedesktop.org/drm) – and a small number of
> subsystems want reports in issue trackers of dedicated Github projects
> or this bug tracker.
>
> For more details on this and reporting Linux kernel bugs in general, see
> the [official step-by-step guide on reporting
> issues](https://docs.kernel.org/admin-guide/reporting-issues.html#step-by-step-guide-how-to-report-issues-to-the-kernel-maintainers).
> It covers all the important aspects, including one that is often missed:
>
> In case somebody else compiled your Linux kernel, you most likely have
> to report bugs to said vendor – like Linux Mint, Red Hat, Ubuntu, or
> SUSE. That is because the majority of the Linux developers only care for
> bugs occurring with kernels built from Linux sources that are pristine
> (aka "vanilla") or nearly so. Kernels using independently developed
> kernel modules are therefore just as unsuitable for reporting bugs upstream.
> """
>
> Sigh, too much text, but you get the idea.
>
> Ciao, Thorsten
>
>

  reply	other threads:[~2026-02-26 14:40 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-10  4:48 kernel.org tooling update Konstantin Ryabitsev
2025-12-10  8:11 ` Mauro Carvalho Chehab
2025-12-10 13:30 ` Thorsten Leemhuis
2025-12-11  3:04   ` Theodore Tso
2025-12-12 23:48   ` Stephen Hemminger
2025-12-12 23:54     ` Randy Dunlap
2025-12-16 16:21 ` Lukas Wunner
2025-12-16 20:33   ` Jeff Johnson
2025-12-17  0:47     ` Mario Limonciello
2025-12-18 13:37       ` Jani Nikula
2025-12-18 14:09         ` Mario Limonciello
2026-01-23  9:19 ` Web of Trust work [Was: kernel.org tooling update] Uwe Kleine-König
2026-01-23  9:29   ` Greg KH
2026-01-23 11:47     ` Mauro Carvalho Chehab
2026-01-23 11:58       ` Greg KH
2026-01-23 12:24         ` Mauro Carvalho Chehab
2026-01-23 12:29           ` Greg KH
2026-01-23 13:57         ` Konstantin Ryabitsev
2026-01-23 16:24     ` James Bottomley
2026-01-23 16:33       ` Greg KH
2026-01-23 16:42         ` Joe Perches
2026-01-23 17:00           ` Steven Rostedt
2026-01-23 17:23         ` James Bottomley
2026-01-23 18:23           ` Konstantin Ryabitsev
2026-01-23 21:12             ` Uwe Kleine-König
2026-01-26 16:23               ` Konstantin Ryabitsev
2026-01-26 17:32                 ` Uwe Kleine-König
2026-01-26 21:01                   ` Konstantin Ryabitsev
2026-01-26 23:23                   ` James Bottomley
2026-01-27  8:39                     ` Uwe Kleine-König
2026-01-27 21:08                       ` Linus Torvalds
2026-02-04 10:49                         ` Uwe Kleine-König
2026-02-05 10:14                           ` James Bottomley
2026-02-05 18:07                             ` Uwe Kleine-König
2026-02-05 18:23                               ` Konstantin Ryabitsev
2026-01-26 23:33                   ` Mauro Carvalho Chehab
2026-01-26 23:06                 ` Mauro Carvalho Chehab
2026-01-23 21:38             ` James Bottomley
2026-01-23 22:55             ` Mauro Carvalho Chehab
2026-01-23 16:38       ` Konstantin Ryabitsev
2026-01-23 17:02         ` Paul Moore
2026-01-23 18:42 ` kernel.org tooling update Randy Dunlap
2026-02-26  8:44 ` slowly decommission bugzilla? (was: Re: kernel.org tooling update) Thorsten Leemhuis
2026-02-26 14:40   ` Andrew G. Morgan [this message]
2026-02-26 17:04   ` Andrew Morton

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=CACmP8UKXwW5smbnqEcymxND0e6eLKuOTWvEtxHSU2LLH9Wn4ow@mail.gmail.com \
    --to=morgan@kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=linux@leemhuis.info \
    --cc=users@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
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