Date:   Fri, 14 Jul 2023 00:04:46 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Emanuele Giuseppe Esposito <eesposit@...hat.com>
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>, bluca@...ian.org,
        lennart@...ttering.net, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Alexander Potapenko <glider@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Daniel P. Berrangé <berrange@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

On Thu, Jul 13, 2023 at 10:49:31PM +0200, Emanuele Giuseppe Esposito wrote:
> >> I replied to the thread not to defend the idea as after the discussion
> >> it is clear there's a lot to take into consideration if anyone decides
> >> to pursue the SBAT idea ever again (and the discussion is now well
> >> preserved in the archive!). I replied to disagree with "get sign-offs
> >> from senior people before sending RFCs" idea, I believe that asking
> >> questions by sending a not-fully-ready patch as "RFC" should not be
> >> discouraged. 
> > 
> > On the contrary, this is EXACTLY what needs to happen here.
> > 
> > This developer (I'm not picking on them at all, it's not their fault),
> > should be taking advantage of the resources of their company when
> > dealing with core, critical, functionality of the kernel.
> > 
> > To just "throw them at the wolves" like Red Hat did, is a total
> > disservice to them, AND it wastes the time and resources of the
> > community, as it is not our job to train and teach them, it is the job
> > of the senior people at your company to do so.
> > 
> > We have a non-zero number of companies that right now who are in the
> > "penalty box" because their developers have had a history of throwing
> > crud over the wall, or having inexperienced developers submit changes
> > that are obviously wrong, which waste the time and energy of the kernel
> > community.  For companies that do this, we have instituted the
> > requirement that they get review and acceptance of kernel changes from
> > the experienced developers within the company BEFORE submitting their
> > changes to the community, for the basic fact that this actually saves
> > EVERYONE time and energy.
> > 
> > It allows the developer to grow and learn more quickly, it saves the
> > energy and time of the reviewers (which is our most valuable resource
> > right now) and it provides a solid path forward on the corporate ladder
> > of using mentors well, and lifting up your own employees.
> > 
> > I don't think you want us to put Red Hat into this type of policy at
> > this point in time, but if you all keep insisting that you can just "let
> > loose" inexperienced developers who wish to change the core
> > functionality of how we operate, that can easily change.
> 
> Wow, I was not aware of these policies O.O.
> What you say makes sense, but what about developers not working in a
> company? Then they are completely ignored?

Not at all, they are not ignored and are treated as someone who probably
needs help.

> Otherwise a simple way to trick you is to actually use my gmail address
> and you won't ever know that I work for RH.

If RH finds out you are misrepresenting yourself like this, I don't
think it will go over very well :)

Also, we know who almost everyone works for, this isn't a secret.  And
it would turn out to be worse overall for that developer if they were to
attempt that.

Remember, kernel development works on trusting other people.  If someone
looses their trust in you, it's very hard to get it back.

thanks,

greg k-h

Powered by blists - more mailing lists