From: "Bird, Timothy" <Tim.Bird@sony.com>
To: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>,
"fuego@lists.linuxfoundation.org"
<fuego@lists.linuxfoundation.org>
Subject: Re: [Fuego] [PATCH 2/3] cyclictest: modify specs
Date: Wed, 1 Nov 2017 17:16:27 +0000 [thread overview]
Message-ID: <ECADFF3FD767C149AD96A924E7EA6EAF40ACD26D@USCULXMSG01.am.sony.com> (raw)
In-Reply-To: <1509438715-14039-3-git-send-email-daniel.sangorrin@toshiba.co.jp>
> -----Original Message-----
> From: fuego-bounces@lists.linuxfoundation.org [mailto:fuego-
> bounces@lists.linuxfoundation.org] On Behalf Of Daniel Sangorrin
> Sent: Tuesday, October 31, 2017 1:32 AM
> To: fuego@lists.linuxfoundation.org
> Subject: [Fuego] [PATCH 2/3] cyclictest: modify specs
>
> cyclictest params can be very flexible so instead of
> giving a fixed pattern we use a single variable PARAMS
> to hold them.
>
> TODO: make builds parameterizable so that users can
> modify the PARAMS from ftc without needing to create
> a new spec.
Just a comment on this. I support this idea, and it's actually
pretty easy to do. We just need to be careful that this doesn't negatively
affect another of Fuego's goal, which is sharing of 1) methods of invoking
test programs, and 2) ability to compare results from multiple systems.
Test specs are one of the primary ways that Fuego users can share their
experience with each other - by creating canonical sets of build variables
that produce meaningful results for particular test scenarios.
If use of custom parameters for tests becomes widespread, then it becomes
less useful to compare results between different Fuego sites.
I'm not saying we shouldn't add the feature, just be judicious in it's
use, and possibly provide recommendations for when it would be
appropriate or not.
-- Tim
next prev parent reply other threads:[~2017-11-01 17:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-31 8:31 [Fuego] cyclictest patches Daniel Sangorrin
2017-10-31 8:31 ` [Fuego] [PATCH 1/3] cyclictest: update build function Daniel Sangorrin
2017-10-31 17:30 ` Bird, Timothy
2017-10-31 18:53 ` Bird, Timothy
2017-10-31 17:49 ` Bird, Timothy
2017-10-31 8:31 ` [Fuego] [PATCH 2/3] cyclictest: modify specs Daniel Sangorrin
2017-10-31 19:56 ` Bird, Timothy
2017-11-01 0:28 ` Daniel Sangorrin
2017-11-01 17:52 ` Bird, Timothy
2017-11-07 7:27 ` Daniel Sangorrin
2017-11-01 17:16 ` Bird, Timothy [this message]
2017-11-07 7:33 ` Daniel Sangorrin
2017-11-08 0:44 ` Bird, Timothy
2017-10-31 8:31 ` [Fuego] [PATCH 3/3] cyclictest: modify parsing and test measures Daniel Sangorrin
2017-11-01 0:43 ` Bird, Timothy
2017-11-01 17:11 ` Bird, Timothy
2017-10-31 8:39 ` [Fuego] cyclictest patches Daniel Sangorrin
2017-10-31 17:27 ` Bird, Timothy
2017-10-31 19:32 ` Bird, Timothy
2017-11-01 0:25 ` Daniel Sangorrin
2017-10-31 16:45 ` Bird, Timothy
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=ECADFF3FD767C149AD96A924E7EA6EAF40ACD26D@USCULXMSG01.am.sony.com \
--to=tim.bird@sony.com \
--cc=daniel.sangorrin@toshiba.co.jp \
--cc=fuego@lists.linuxfoundation.org \
/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.