lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzWb6xVBdiMjSfjF@kroah.com>
Date:   Thu, 29 Sep 2022 15:21:47 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Artem S. Tashkinov" <aros@....com>
Cc:     Thorsten Leemhuis <linux@...mhuis.info>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        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:09:35PM +0000, Artem S. Tashkinov wrote:
> 
> 
> On 9/29/22 12:52, Greg KH wrote:
> > On Thu, Sep 29, 2022 at 12:22:35PM +0000, Artem S. Tashkinov wrote:
> > > Let me be brutally honest here, if you're working on the kernel,
> > > specially for a large company such as e.g. Intel, you're _expected_ to
> > > address the issues which are related to the kernel component[s] you're
> > > maintaining/developing otherwise it's not "development" it's "I'm
> > > dumping my code because my employer pays me to do that". That also means
> > > you're expected to address bug reports.
> > 
> > I wish that were the case, unfortunately it is quite rare that
> > maintainers of subsystems of the kernel are allowed to work on upstream
> > issues like this all the time.  Heck, part of the time would be
> > wonderful too, but that is also quite rare.  So while maintainers would
> > love to be able to work like this, getting their management to agree to
> > this is not very common, sadly.
> 
> Understood but it's illogical and I cannot/will not accept it.

Wonderful, please work with the companies involved to get them to change
their internal structures to support this.  Have fun! :)

Seriously, many of us have been working with many companies to try to
change this, but it's slow going and requires constant retraining of new
managers when they get moved around.  It's a thankless job, please reach
out to any contacts that you have to help out.

> For
> instance, here's a very common scenario: you work for company X. The
> company tells you to fix a bug/add a new feature/etc. You write the
> code, submit it and it results in a regression for other use cases. Are
> you saying it's alright and shouldn't be addressed? That's _exactly_ how
> many if not _most_ regressions in the kernel are introduced.

True, but the time of a report of a regression is usually much delayed
from the original development, and sometimes the original developers
have moved on.

But the topic here was the maintainers of the subsystems, not the people
who did the original development effort.  That's two totally different
groups of people, with different managers, working for different
companies.  Please don't get them confused.

> > > 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.
> > 
> > bugzilla.kernel.org is _hosted_ by the LF, and does a great job of
> > keeping it running and alive.  The LF has nothing to do with the content
> > of the bugs in it, the reporting, the response of people to reported
> > bugs, assigning bugs to anyone, getting them fixed, or anything else
> > related to the content in the database at all.  Please don't get
> > confused with the resources provided to host the system vs. the people
> > who actually do the kernel development itself.
> > 
> > Note, the LF does sponsor a few kernel developers to do work on the
> > kernel, including myself, but we are a tiny drop in the bucket compared
> > to the 4000+ developers who contribute to the kernel every year.
> >
> > thanks,
> >
> > greg k-h
> 
> Keeping the website up and running requires next to zero human
> time/resources, that's not proper maintenance.

Um, no, not at all.  See Konstantin's response for just a small snippet
of what is involved here.

> The
> components/subsystems/developers haven't been updated in over a decade
> which results in a bug tracker which is nearly useless. People often
> file bug reports under "Other/Other" and no one is notified of anything.
> I don't even want to touch on the fact that the  Bugzilla version the
> website is running is terribly outdated.
> 
> That's the issue I thought we're trying to resolve - making bugzilla
> useful. Under no circumstances I want to engage kernel developers or
> blame them for anything. I'm grateful you exist and do your work :-)

I agree, making bugzilla, or something else, useful would be wonderful,
but so far no one has stepped up to do that work except for Thorsten
here.  And it will involve getting 700+ different maintainers to agree
what to do, that's going to be "fun" :)

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ