From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 04/11] docparse: Add README
Date: Mon, 5 Oct 2020 10:15:46 -0400 (EDT) [thread overview]
Message-ID: <135581472.16896262.1601907346856.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20201005133054.23587-5-chrubis@suse.cz>
----- Original Message -----
> +Open Points
> +===========
> +
> +There are stil some loose ends. Mostly it's not well defined where to put
> +things and how to format them.
> +
> +* Some of the hardware requirements are already listed in the tst\_test.
> Should
> + we put all of them there?
> +
> +* What would be the format for test documentation and how to store things
> such
> + as test variants there?
I'm assuming you don't mean ".test_variants" here, but runtest entries
using same binary with different parameters. Currently we have a "tag"
that can refer to binary+parameters pair. Which is also useful, for
skipping tests - e.g. they run long, they are broken, or older kernel
is known to crash - we have a list of checks that modify runtest files
before actual run to avoid running into known issues (or save time).
> +
> +So far this proof of concept generates a metadata file. I guess that we need
> +actual consumers which will help to settle things down, I will try to look
> into
> +making use of this in the runltp-ng at least as a reference implementation.
> --
> 2.26.2
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>
>
next prev parent reply other threads:[~2020-10-05 14:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 13:30 [LTP] [PATCH 00/11] Test metadata extraction Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 01/11] make: Support compiling native build tools Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 02/11] travis: Add git Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 03/11] docparse: Add test documentation parser Cyril Hrubis
2020-10-23 7:01 ` Li Wang
2020-10-23 9:36 ` Li Wang
2020-10-05 13:30 ` [LTP] [PATCH 04/11] docparse: Add README Cyril Hrubis
2020-10-05 14:15 ` Jan Stancek [this message]
2020-10-13 11:59 ` Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 05/11] syscalls: Add a few documentation comments Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 06/11] syscalls: Move needs_drivers inside of the tst_test struct Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 07/11] make: Allow {INSTALL, MAKE}_TARGETS be a directory Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 08/11] make: Allow CLEAN_TARGETS to remove directories Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 09/11] travis: Install docparse dependencies Cyril Hrubis
2020-10-21 10:38 ` Li Wang
2020-10-05 13:30 ` [LTP] [PATCH 10/11] docparse: Add configure options Cyril Hrubis
2020-10-05 13:30 ` [LTP] [PATCH 11/11] docparse: Generate html and pdf using asciidoc{, tor} Cyril Hrubis
2020-10-23 6:18 ` Li Wang
2020-10-23 7:19 ` Petr Vorel
2020-10-05 13:35 ` [LTP] [PATCH 00/11] Test metadata extraction Cyril Hrubis
2020-10-12 8:53 ` Petr Vorel
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=135581472.16896262.1601907346856.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--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