[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6f980199fa07143402a9274e352711d@smtp.hushmail.com>
Date: Wed, 30 Sep 2015 22:28:19 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Proposal for --test-full logic
On 28/09/15 16:39, jfoug wrote:
> Solar,
>
> I know this has been a pet project which you have spear-headed for
> GSOC. I would like to propose this change in logic.
>
> currently, -test and -test-full both perform tests, and then perform
> benchmarks. I would propose that for -test-full, we remove that
> benchmark logic, and instead use the optional param to give indication
> for more tests to be run, where some of the 'deeper' tests may not be
> fully fixed in all formats.
>
> So --test-full or --test-full=0 would run a specific level. This would
> be all tests which we would 'expect' to run without errors (possibly
> with a format or 2 in whitelist). This would be very useful for adding
> to our CI environments, to use this vs using the --test=0 which is used
> today.
Fair enough. The downside is --test-full won't be able to give a
benchmark figure. But I can't see much reason for it to do so.
Solar, you will never merge the --test-full into core, right? So we can
change it in Jumbo?
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
