Re: [LTP] [PATCH 1/1] doc/maintainer: Add policy for new functionality

[Richard Palethorpe <rpalethorpe@suse.de>]

Hello Petr,

Petr Vorel <pvorel@suse.cz> writes:

> Suggested-by: Cyril Hrubis <chrubis@suse.cz>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
>  doc/maintainer-patch-review-checklist.txt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/doc/maintainer-patch-review-checklist.txt b/doc/maintainer-patch-review-checklist.txt
> index c7bb47810..4e2b267ac 100644
> --- a/doc/maintainer-patch-review-checklist.txt
> +++ b/doc/maintainer-patch-review-checklist.txt
> @@ -34,6 +34,9 @@ New test should
>    GPL-2.0-or-later; the licence for test (e.g. GPL-2.0) should not change
>    unless test is completely rewritten
>  * Old copyrights should be kept unless test is completely rewritten
> +* Tests for new functionality in mainline kernel should be merged after final
> +  release of kernel which contains that functionality (it's not enough when the
> +  feature gets into rc1, because it can be reverted in later rc if
> problematic).

What is the concern? All I can see is that we merge a test which is for
a feature that is never included

The issue is we may forget to merge patch sets for features which are
included (a far worse result). It's more stuff waiting around in the
queue. At the least we should have a procedure for tracking them (like
tagging github issues for review at each mainline release).

If a test requires a kernel config which doesn't exist in mainline we
could also look for that automatically.

>  
>  ### C tests
>  * Use new https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines#22-writing-a-test-in-c[C API]
> -- 
> 2.34.1


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp