kconfirm: patch reporting guidelines?

kconfirm: patch reporting guidelines?

[Julian Braha]

Hi Greg,


*Question 1: should I acknowledge the kconfirm tool in my patches?

I've received a wide range of feedback as I've been submitting patches
from kconfirm findings. For example, Lorenzo thanked me for
acknowledging the tool when submitting a patch:
https://lore.kernel.org/all/bfdfdb05-77e2-455d-b68d-9da3fd9d1c0d@lucifer.local/

and on the other hand, Alexander asked me not to refer to the tool
until it is moved into the tree:
https://lore.kernel.org/all/3ec20142-09d1-436f-a623-21a2440ef7f0-agordeev@linux.ibm.com/


*Question 2: do bugs in kconfig deserve a Fixes tag?

I've found a few instances of dead default statements, which should not
be dead. Fortunately, these just involve the kunit tests. Nothing
crazy.

I previously sent out this patch for powerpc, which has passed 2
reviewers and 1 tester, and none of them have objected to the Fixes tag:
https://lore.kernel.org/all/20260405161545.161006-1-julianbraha@gmail.com/

and on the other hand, Alexander says that this is "no real issue" and
doesn't deserve a Fixes tag:
https://lore.kernel.org/all/3ec20142-09d1-436f-a623-21a2440ef7f0-agordeev@linux.ibm.com/

- Julian Braha

Re: kconfirm: patch reporting guidelines?

[Greg Kroah-Hartman]

On Wed, May 06, 2026 at 06:08:45PM +0100, Julian Braha wrote:
> Hi Greg,
> 
> 
> *Question 1: should I acknowledge the kconfirm tool in my patches?

What is "kconfirm"?

> I've received a wide range of feedback as I've been submitting patches
> from kconfirm findings. For example, Lorenzo thanked me for
> acknowledging the tool when submitting a patch:
> https://lore.kernel.org/all/bfdfdb05-77e2-455d-b68d-9da3fd9d1c0d@lucifer.local/
> 
> and on the other hand, Alexander asked me not to refer to the tool
> until it is moved into the tree:
> https://lore.kernel.org/all/3ec20142-09d1-436f-a623-21a2440ef7f0-agordeev@linux.ibm.com/

The issue is that you are adding Fixes: tags for something that is not
really a fix.

And each maintainer has their own opinion, but adding a line saying what
tool you are using is a requirement of ours, so this is fine to keep.

> *Question 2: do bugs in kconfig deserve a Fixes tag?

Probably not.

thanks,

greg k-h

Re: kconfirm: patch reporting guidelines?

[Julian Braha]

On 5/7/26 06:10, Greg Kroah-Hartman wrote:
> What is "kconfirm"?

Sorry again, this is becoming a recurring issue for me with lacking
context...
The introduction of kconfirm to the mailing list is here:
https://lore.kernel.org/all/6ec4df6d-1445-48ca-8f54-1d1a83c4716d@gmail.com/

> adding a line saying what
> tool you are using is a requirement of ours, so this is fine to keep.
>
>> *Question 2: do bugs in kconfig deserve a Fixes tag?
>
> Probably not.

Thank you! I will resubmit the existing patches without Fixes tags, and
continue acknowledging the tool.

- Julian Braha

Re: kconfirm: patch reporting guidelines?

[Greg Kroah-Hartman]

On Thu, May 07, 2026 at 10:19:15AM +0100, Julian Braha wrote:
> On 5/7/26 06:10, Greg Kroah-Hartman wrote:
> > What is "kconfirm"?
> 
> Sorry again, this is becoming a recurring issue for me with lacking
> context...
> The introduction of kconfirm to the mailing list is here:
> https://lore.kernel.org/all/6ec4df6d-1445-48ca-8f54-1d1a83c4716d@gmail.com/

Why not work on getting that merged?

thanks,

greg k-h