public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: "xuyang2018.jy@fujitsu.com" <xuyang2018.jy@fujitsu.com>
To: Cyril Hrubis <chrubis@suse.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 09:09:09 +0000	[thread overview]
Message-ID: <61B70DE2.4040402@fujitsu.com> (raw)
In-Reply-To: <YbcM8xKx7G0KQxWU@yuki>

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.
>
>> 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.
>

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

  reply	other threads:[~2021-12-13  9:09 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 [this message]
2021-12-13 11:17       ` Richard Palethorpe
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=61B70DE2.4040402@fujitsu.com \
    --to=xuyang2018.jy@fujitsu.com \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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