diff mbox series

[RFC,v2] MAINTAINERS: split kselftest entry into 'framework' and 'all'

Message ID 20241115200912.1009680-1-kuba@kernel.org (mailing list archive)
State New
Headers show
Series [RFC,v2] MAINTAINERS: split kselftest entry into 'framework' and 'all' | expand

Commit Message

Jakub Kicinski Nov. 15, 2024, 8:09 p.m. UTC
The testing effort is increasing throughout the community.
The tests are generally merged into the subsystem trees,
and are of relatively narrow interest. The patch volume on
linux-kselftest@vger.kernel.org makes it hard to follow
the changes to the framework, and discuss proposals.

Create a new ML focused on the framework of kselftests,
which will hopefully be similarly low volume to the workflows@
mailing list.

From the responses to v1 I gather that the preference is to
keep the existing list for all (or create an alias to it);
the framework-only section should be the one to have a new
list created.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
Sorry for the delay, the responses to v1 weren't super positive
but I keep thinking this would be very useful :) Or at the very
least I find workflows@ very useful and informative as a maintainer.

Posting as an RFC because we need to create the new ML.

v1: https://lore.kernel.org/20241003142328.622730-1-kuba@kernel.org

CC: shuah@kernel.org
CC: Tim.Bird@sony.com
CC: linux-kselftest@vger.kernel.org
CC: workflows@vger.kernel.org
---
 MAINTAINERS | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

Comments

Shuah Khan Nov. 18, 2024, 9:02 p.m. UTC | #1
On 11/15/24 13:09, Jakub Kicinski wrote:
> The testing effort is increasing throughout the community.
> The tests are generally merged into the subsystem trees,
> and are of relatively narrow interest. The patch volume on
> linux-kselftest@vger.kernel.org makes it hard to follow
> the changes to the framework, and discuss proposals.
> 
> Create a new ML focused on the framework of kselftests,
> which will hopefully be similarly low volume to the workflows@
> mailing list.
> 
>  From the responses to v1 I gather that the preference is to
> keep the existing list for all (or create an alias to it);
> the framework-only section should be the one to have a new
> list created.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> Sorry for the delay, the responses to v1 weren't super positive
> but I keep thinking this would be very useful :) Or at the very
> least I find workflows@ very useful and informative as a maintainer.
> 
> Posting as an RFC because we need to create the new ML.
I have to repeat the same thing I said when you sent RFC v1
It is going to add the confusion - people don't cc the one mailing list
we have now.

I am going to have to say no. Sorry.

thanks,
-- Shuah
Jakub Kicinski Nov. 18, 2024, 9:23 p.m. UTC | #2
On Mon, 18 Nov 2024 14:02:29 -0700 Shuah Khan wrote:
> > Sorry for the delay, the responses to v1 weren't super positive
> > but I keep thinking this would be very useful :) Or at the very
> > least I find workflows@ very useful and informative as a maintainer.
> > 
> > Posting as an RFC because we need to create the new ML.  
> I have to repeat the same thing I said when you sent RFC v1
> It is going to add the confusion - people don't cc the one
> mailing list we have now.
> 
> I am going to have to say no. Sorry.

To me the dissonance between your admission that people don't CC the
current list (IOW status quo isn't great) and the resistance to change
is fairly apparent. But it is obviously your call.
Shuah Nov. 22, 2024, 2:56 p.m. UTC | #3
On 11/18/24 14:23, Jakub Kicinski wrote:
> On Mon, 18 Nov 2024 14:02:29 -0700 Shuah Khan wrote:
>>> Sorry for the delay, the responses to v1 weren't super positive
>>> but I keep thinking this would be very useful :) Or at the very
>>> least I find workflows@ very useful and informative as a maintainer.
>>>
>>> Posting as an RFC because we need to create the new ML.
>> I have to repeat the same thing I said when you sent RFC v1
>> It is going to add the confusion - people don't cc the one
>> mailing list we have now.
>>
>> I am going to have to say no. Sorry.
> 
> To me the dissonance between your admission that people don't CC the
> current list (IOW status quo isn't great) and the resistance to change
> is fairly apparent. But it is obviously your call.
My thinking is that people don't seem to CC the one mailing list
we have and adding one more would add to the problem.

Are there other ways to solve the problem by using prefix like
we do now for subsystem tests: selftests:framework?

thanks,
-- Shuah
Jakub Kicinski Nov. 22, 2024, 5:29 p.m. UTC | #4
On Fri, 22 Nov 2024 07:56:25 -0700 Shuah wrote:
> > To me the dissonance between your admission that people don't CC the
> > current list (IOW status quo isn't great) and the resistance to change
> > is fairly apparent. But it is obviously your call.  
> My thinking is that people don't seem to CC the one mailing list
> we have and adding one more would add to the problem.
> 
> Are there other ways to solve the problem by using prefix like
> we do now for subsystem tests: selftests:framework?

I think the ideal solution would be to let people subscribe to code
paths rather the deal with mailing lists in the first place :(
That way we can fix this on the "mailing list backend" rather than
expecting people who submit code to do the right thing.

Konstantin did some work on auto-CC based on get_maintainer output,
whether vger would just fill in the missing CCs, but AFAIR he got stuck
on the need to modify headers which would break DKIM.

I should mention that lore/lei does support filtering / subscribing 
to paths etc, but from experience bringing folks into upstream
reviews - running lore/lei doesn't work for everyone. I also don't 
use it because it doesn't support the mbox format of my MUA :(

At the current state of affairs, since we can't fix the "receiver" side
easily, we have to shift the responsibility on the "sender" side.
Hope people run get_maintainer, and have well defined lists..
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index f245573722ef..345a0657ba1d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12395,7 +12395,7 @@  S:	Supported
 F:	Documentation/admin-guide/reporting-regressions.rst
 F:	Documentation/process/handling-regressions.rst
 
-KERNEL SELFTEST FRAMEWORK
+KERNEL SELFTEST
 M:	Shuah Khan <shuah@kernel.org>
 M:	Shuah Khan <skhan@linuxfoundation.org>
 L:	linux-kselftest@vger.kernel.org
@@ -12405,6 +12405,19 @@  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git
 F:	Documentation/dev-tools/kselftest*
 F:	tools/testing/selftests/
 
+KERNEL SELFTEST FRAMEWORK
+M:	Shuah Khan <shuah@kernel.org>
+M:	Shuah Khan <skhan@linuxfoundation.org>
+L:	linux-kselftest-core@vger.kernel.org
+S:	Maintained
+F:	Documentation/dev-tools/kselftest*
+F:	tools/testing/selftests/kselftest/
+F:	tools/testing/selftests/lib/
+F:	tools/testing/selftests/lib.mk
+F:	tools/testing/selftests/Makefile
+F:	tools/testing/selftests/*.sh
+F:	tools/testing/selftests/*.h
+
 KERNEL SMB3 SERVER (KSMBD)
 M:	Namjae Jeon <linkinjeon@kernel.org>
 M:	Steve French <sfrench@samba.org>