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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.