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. -- KoobsReceived 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