Message-ID: <YzWg/GjvPGvhhPkB@kroah.com>
Date:   Thu, 29 Sep 2022 15:43:24 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Artem S. Tashkinov" <aros@....com>
Cc:     Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        workflows@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        ksummit@...ts.linux.dev
Subject: Re: Planned changes for bugzilla.kernel.org to reduce the "Bugzilla
 blues"

On Thu, Sep 29, 2022 at 01:31:49PM +0000, Artem S. Tashkinov wrote:
> 
> 
> On 9/29/22 13:04, Konstantin Ryabitsev wrote:
> > 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
> 
> To me it sounds like the best way to keep moving forward is simply
> convert git.kernel.org + patchwork.kernel.org + bugzilla to
> gitlab.kernel.org and that will solve all the issues immediately. That
> will require of course a ton of work but:

For loads of reasons that have been stated before, we aren't going to
move everything to gitlab, sorry.  That's a non-starter for a wide range
of reasons, not the least being you are trying to solve a "we have no
one who wants to wrangle bugs in bugzilla" problem with "move all of our
code hosting infrastructure to a totally different thing that can't even
provide the basic things that we have today".

Sorry, not going to happen, gitlab is not the solution here.

greg k-h

Powered by blists - more mailing lists