From: Cyril Hrubis <chrubis@suse.cz>
To: Richard Palethorpe <rpalethorpe@suse.de>
Cc: pvorel@suze.cz, "ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH 1/1] doc/maintainer: Add policy for new functionality
Date: Wed, 5 Jan 2022 16:29:28 +0100 [thread overview]
Message-ID: <YdW5WEXgrotentzM@yuki> (raw)
In-Reply-To: <87lf0ffw1y.fsf@suse.de>
Hi!
> Yes. Although we could add "next" and "rc" flags to tst_test (or
> similar). Then require an environment variable to be set (or check the
> kernel version) otherwise the test will return TCONF.
>
> For LTP releases we just need to check if the flags are still needed or
> if the feature has been merged. The metadata parser can generate a list
> of tests to check.
>
> This seems like quite little work to me. In fact we don't even have to
> implement it until someone wants it. We can just add it to the policy.
I was thinking of this and if we really want this feature it would make
sense to add "remove_before_use" flag to the test structure what would
render the test resultless. Ideally it would include the kernel version
the functionality is going to be included into, then we can
automatically check in the CI the test metadata against latest release
kernel version and either remove the flag or bump it in case it didn't
get in.
Maybe just .remove_after_release = "5.9"
@Ritchie feel free to go ahead if you want to implement and maintain
something like this.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
prev parent reply other threads:[~2022-01-05 15:28 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
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 [this message]
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=YdW5WEXgrotentzM@yuki \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=pvorel@suze.cz \
--cc=rpalethorpe@suse.de \
/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