ltp.lists.linux.it archive mirror
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Richard Palethorpe <rpalethorpe@suse.de>
Cc: "ltp@lists.linux.it" <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH 1/1] doc/maintainer: Add policy for new functionality
Date: Mon, 20 Dec 2021 18:53:16 +0100	[thread overview]
Message-ID: <YcDDDMtpKZQ8+tAa@pevik> (raw)
In-Reply-To: <87lf0ffw1y.fsf@suse.de>

Hi Richie, Cyril,

<snip>
> > Thus, first, do you agree with current policy?

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

Yes, adding flag would work.

> > If yes, how would you phrase it (do you want to add / change
> > anything)?

> Something like:

> "Tests for new functionality should only be added to the LTP once they
> are part of the stable kernel ABI. This happens when a feature is
> included in a final kernel release. Not during the RC phase where they
> can still be removed and, for example, the syscall numbers reused.

> This allows stable LTP releases to be taken directly from Git HEAD at
> any time we are ready. Without needing to remove commits for unstable
> feature tests or synchronise with the kernel releases.

> Alternatively if someone is very motivated to add tests for linux-next
> or the RC phase. We can add flags to tst_test which will prevent these
> tests being run under normal circumstances. Meaning the releases are
> unaffected."

OK, we document our willingness to add infrastructure for merging in rc,
if desired. I'm ok with this, if Cyril agree, I can send v2 for others to
ack/review it.

> > Or do you suggest to have policy when merged to rc1?
> > It would work for me, but we'd have to ask all maintainers
> > (I suggested that before, Cyril preferred kernel release).

> I'd happily accept tests for things going into linux-next if there are
> people willing to write them and they do not "throw them over the
> wall and run".

IMHO it's up to us whether we want to implement. I know just about few tests in
last 2 years - fanotify and IMA subsystems which has brought tests and they just
accepted our decision when we're going to merge it. People are happy that we
help them in tests, nobody haven't felt being put off by merging later.


Kind regards,
Petr

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

  reply	other threads:[~2021-12-20 17:53 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 [this message]
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=YcDDDMtpKZQ8+tAa@pevik \
    --to=pvorel@suse.cz \
    --cc=ltp@lists.linux.it \
    --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;
as well as URLs for NNTP newsgroup(s).