Message-ID: <e495599a-7a5c-15d0-34b1-3470ad0986ca@redhat.com>
Date:   Fri, 14 Jul 2023 08:57:03 +0200
From:   Emanuele Giuseppe Esposito <eesposit@...hat.com>
To:     Greg KH <gregkh@...uxfoundation.org>
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



Am 14/07/2023 um 00:04 schrieb Greg KH:
> 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 :)

By "my gmail address" I mean any potential employee of any company
reading this thread of course. I think after this you'll remember my
name for a while ;) So no way to hide for me. Also my private email
address has my name and surname in it, so it won't be hard to identify me.

Anyways, I think you need to clarify better what you mean with
"inexperienced developers submit changes that are obviously wrong", more
specifically the "obviously wrong" part.
If you refer to the commit message wrongly made, ok you have a point. I
take responsibility on this, it already happened that I wrote non clear
commits and I am working on this. Working on different communities that
have less commit rules and rarely sending stuff to kernel doesn't help
though (my only excuse). If it's that, the issue can be closed here and
I will definitely be more careful in the future, as well as all I work with.

If you refer to the fact that the patch is wrong technically, 1) as I
wrote it is indeed not working properly, I have clearly documented in
the commit message that if you run make twice with this patch it won't
work, and 2) the aim of this patch that we thought was clear with RFC
and "Important:..." was to ask opinions because we don't have experts on
this matter, the technology is new and would like to hear opinions from
outside. You gave the opinion we were looking for, it's just that the
whole thing escalated dramatically because IMHO intentions were
misunderstood and again IMHO the wrong tones and wordings were used.

Thank you,
Emanuele
> 
> 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