On Fri, Dec 8, 2023 at 5:40 PM KP Singh <kpsingh@xxxxxxxxxx> wrote:
> On Fri, Dec 8, 2023 at 11:05 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> > On Fri, Dec 08, 2023 at 04:43:57PM -0500, Paul Moore wrote:
> > > On Fri, Dec 8, 2023 at 4:13 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> > > > On Fri, Dec 08, 2023 at 03:51:47PM -0500, Paul Moore wrote:
> > > > > Hopefully by repeating the important bits of the conversation you now
> > > > > understand that there is nothing you can do at this moment to speed my
> > > > > review of this patchset, but there are things you, and KP, can do in
> > > > > the future if additional respins are needed. However, if you are
> > > > > still confused, it may be best to go do something else for a bit and
> > > > > then revisit this email because there is nothing more that I can say
> > > > > on this topic at this point in time.
> > > >
> > > > I moved to the list because off-list discussions (that I got involuntarily
> > > > CCed into and never replied to at all) tend to be unhelpful as no one else
> > > > can share in any context they may provide. And I'm not trying to rush
> > > > you; I'm trying to make review easier.
> > >
> > > From my perspective whatever good intentions you had at the start were
> > > completely lost when you asked "What's the right direction forward?"
> > > after I had already explained things multiple times *today*. That's
> > > the sort of thing that drives really bothers me.
> >
> > Okay, I understand now. Sorry for frustrating you! By "way forward",
> > I meant I didn't understand how to address what looked like conflicting
> > feedback. I think my confusion was over separating the goal ("this
> > feature should be automatically enabled when it is known to be useful")
> > from an interpretation of earlier feedback as "I don't want a CONFIG [that
> > leaves this up to the user]", when what you really wanted understood was
> > "I don't want a CONFIG *ever*, regardless of whether it picks the correct
> > setting automatically".
> >
> > >
> > > > While looking at the v8 again I
> > > > saw an obvious problem with it, so I commented on it so that it's clear
> > > > to you that it'll need work when you do get around to the review.
> > >
> > > That's fair. The Kconfig patch shouldn't have even been part of the
> > > v8 patchset as far as I'm concerned, both because I explained I didn't
> > > want to merge something like that (and was ignored) and because it
> > > doesn't appear to do anything. From where I sit this was, and
> > > remains, equally parts comical and frustrating.
>
>
> Paul, as I said I will include it in v3 and we can drop it if that's
> the consensus.
>
> https://lore.kernel.org/bpf/CACYkzJ7KBBJV-CWPkMCqT6rK6yVEOJzhqUjvWzp9BAm-rx3Gsg@xxxxxxxxxxxxxx/
>
> Following that, I received Acks on the patch, so I kept it. I wasn't
> sure if this was going to be perceived as "ignoring your feedback".
> Definitely not my intention. I was just giving an option for folks who
> wanted to test the patch so that we get the defaults right. I am
> totally okay with us dropping the config patch.
<heavy sarcasm>I'm glad you're okay with dropping a patch I said I
wasn't going to merge three months ago. I'm also glad you're okay
with dropping a patch that does absolutely nothing.</heavy sarcasm>
Come on KP, you're better than this. Continuing to carry a patch that
I've said I'm not going to merge only creates confusion about what
will be accepted/supported (see today's exchange as a perfect
example). There is no need to keep the patch going "for reference",
to record ACKs, or anything similar to that; all the reviews, ACKs,
etc. happened on a public list so we have that covered from a
historical perspective.
I suppose there is a worthy offshoot discussion about consensus and
maintainer discretion, but I'm too tired and annoyed to give that
discussion the attention it deserves, so let's just say that when I
say stuff like I did back in the v2 patchset that should be taken as a
"regardless of what consensus there may be, I'm not going to merge
this patch."
--
paul-moore.com
