From: Richard Palethorpe <rpalethorpe@suse.de>
To: pvorel@suze.cz
Cc: "ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH 1/1] doc/maintainer: Add policy for new functionality
Date: Mon, 13 Dec 2021 11:17:50 +0000 [thread overview]
Message-ID: <87lf0oaeui.fsf@suse.de> (raw)
In-Reply-To: <61B70DE2.4040402@fujitsu.com>
Hello,
"xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com> writes:
> Hi!
>> Hi!
>>>> +* 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
>>
>> Not only that, the interface may change subtly.
That can always happen as plenty of changes will break LTP test
expectations, but not real programs.
>>
>>> 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.
>>
>> The main issue is that if we happen to release LTP meanwhile with a test
>> for a syscall that didn't get included in the mainline in the end we
>> have released LTP that is supposed to be stable and the test will start
>> to fail when the syscall number is allocated for something else which
>> will happen sooner or later.
> I know a example that is quotactl_path syscall.
>>
If the real issue is LTP releases, then why not exclude tests for new
features from them? I assume it's only a small number of commits which
would need to be removed. Possibly we could tag them in git when merging
so it is not a lot more work for whoever does the release (namely
Cyril) to create a branch without them.
My main concern is this will throw up a barrier to motivated
contributors working on the cutting edge.
--
Thank you,
Richard.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2021-12-13 12:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-10 13:45 [LTP] [PATCH 1/1] doc/maintainer: Add policy for new functionality Petr Vorel
2021-12-10 16:12 ` Cyril Hrubis
2021-12-11 15:19 ` Petr Vorel
2021-12-11 16:56 ` Mike Frysinger
2021-12-12 3:23 ` Enji Cooper
2021-12-12 3:49 ` Li Wang
2021-12-13 7:32 ` Jan Stancek
2021-12-13 8:22 ` Richard Palethorpe
2021-12-13 9:05 ` Cyril Hrubis
2021-12-13 9:09 ` xuyang2018.jy
2021-12-13 11:17 ` Richard Palethorpe [this message]
2021-12-13 12:14 ` Cyril Hrubis
2021-12-13 14:17 ` Richard Palethorpe
2021-12-15 10:52 ` Petr Vorel
2021-12-15 11:32 ` Richard Palethorpe
2021-12-15 16:29 ` Petr Vorel
2021-12-20 8:58 ` Richard Palethorpe
2021-12-20 17:53 ` Petr Vorel
2022-01-05 15:29 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lf0oaeui.fsf@suse.de \
--to=rpalethorpe@suse.de \
--cc=ltp@lists.linux.it \
--cc=pvorel@suze.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).