Re: Turning TESTS on by default

From: Kubilay Kocak <koobs_at_FreeBSD.org>
Date: Sat, 07 Jun 2014 11:28:45 +1000
On 7/06/2014 5:14 AM, Julio Merino wrote:
> Hello all,
> 
> 
> TL;DR
> -----
> 
> I plan to turn the TESTS src.conf knob ON by default on Tuesday once I
> have been able to perform enough sanity-checks of the build and all of
> them pass.
> 
> The impact of this is that the FreeBSD Test Suite (see tests(7)) will
> be built and installed by default under /usr/tests/ along with the
> private atf libraries and binaries. There should be no other changes
> and this should be transparent to everyone.
> 
> If this happens to break the world in any way, we can trivially roll
> the change back to fix the fallout.
> 
> 
> Some details
> ------------
> 
> TESTS was never intended to be disabled by default. However, the
> original patches that were committed months ago related to this
> feature broke the build and the easiest way out (instead of reverting
> the commits) was to set the knob to disabled. Unfortunately, it stayed
> that way even after the discovered problems were fixed.
> 
> I am confident enough now that we have ironed out all major issues
> that this might introduce, so it is about time to enable TESTS by
> default again in HEAD.
> 
> The benefits of this are that 1) we allow end users (especially
> consumers of binary releases!) to run the tests out of the box, as it
> has always been intended; and 2) we will be able to run the official
> release builds through testing via Jenkins, instead of having to issue
> custom builds.
> 
> Actual change: https://phabric.freebsd.org/D188
> 
> 
> I will update this thread when the change is committed and/or with any updates.
> 
> Please let me know if I'm missing anything.
> 
> Cheers
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 

Julio,

Awesome! I look forward to automated review lint checks that test for
addition of tests, coverage++ and issue ID's in a changeset :]

On a related note, how challenging might it be to generate and expose
coverage metrics?

This is not to say they are a perfect measure of anything in particular,
but ought to provide us a good high level idea of important candidate
areas that would benefit from coverage and don't currently.

--
Koobs
Received on Fri Jun 06 2014 - 23:29:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:49 UTC