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 Thu, Sep 29, 2022 at 12:22:35PM +0000, Artem S. Tashkinov wrote:
> AFAIK, the kernel bugzilla is a Linux Foundation project and the
> organization receives funding from its very rich members including
> Google, Meta, Intel, and even Microsoft. The fact that no one is
> seriously working on it looks shameful and sad. We are not talking about
> a minor odd library with a dozen users we are talking about the kernel.

The bugzilla as a software platform is a Mozilla product, not Linux
Foundation. Unfortunately, it's pretty much dead:

1. all development has stopped years ago
2. it doesn't even work with recent MySQL servers
3. it is written in perl5 and can only pretty much run with mod_perl

We're committed to running it as far as we can, but we all must also admit
that the platform is near-death and probably will become an ever-increasing
burden to keep it operating. Heck, one of our IT staff is currently trying to
convert bugzilla.kernel.org to use Postgres just so we can keep operating it
past the end of 2022.

The Linux Foundation IT is in charge of running infrastructure -- we're not a
development shop. All of our software projects are pretty much "skunkworks"
efforts (and yes, this includes b4).

We do have ability to fund development efforts -- LF has been the primary
sponsor behind public-inbox.org over the past 3 years. However, there must be
a clear, strong, and well-articulated mandate from the community. From what I
heard, the vast majority of maintainers simply want a web form that would
allow someone to:

1. clearly state what kernel version they are using
2. clearly describe what they were trying to do
3. explain what they expected vs. what they got
4. attach any files
5. give this bug report a unique identifier

Then a designated person would look through the bug report and either:

a. quick-close it (with the usual "talk to your distro" or "don't use a
   tainted kernel" etc)
b. identify the responsible maintainers and notify them

The hard part is not technical -- the hard part is that "designated person."
Being a bugmaster is a thankless job that leads to burnout, regardless of how
well you are paid. Everyone is constantly irate at you from both ends -- the
users are annoyed because their stuff doesn't work, and the maintainers are
annoyed because you keep yanking them to work on dull problems that require a
ton of back-and-forth with people who aren't capable of applying patches and
booting custom kernels.

Before we try to fix/replace bugzilla, we really need to figure out the entire
process and pinpoint who is going to be the one in charge of bug reports. If
you think that LF should establish a fund for a position like that, then you
should probably approach LF fellows (Greg KH, Shuah Khan), who can then talk
to LF management. The IT team will be happy to support you with the tooling,
but tooling should come second to that -- otherwise we'll just be replacing an
old and rusty dumpster on fire with a new and shiny dumpster on fire.

-K



[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