Re: [PATCH v7 2/7] tests: paint known breakages in yellow
On 12/21/2012 04:12 AM, Junio C Hamano wrote: From: Adam Spiers g...@adamspiers.org Yellow seems a more appropriate color than bold green when considering the universal traffic lights coloring scheme, where green conveys the impression that everything's OK, and amber that something's not quite right. Here are few more details about the behaviour of other testing tools, in case you want to squash them in the commit message for future references: 1. Automake (at least up to 1.13) and Autotest (at least up to the 2.69 Autoconf release) use bold green for reporting expected failures. 2. On the other hand, the 'prove' utility (as of TAP::Harness v3.23 and Perl v5.14.2) use yellow (not bold) for the same purpose. Regards, Stefano -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/7] tests: paint known breakages in yellow
Stefano Lattarini stefano.lattar...@gmail.com writes: On 12/21/2012 04:12 AM, Junio C Hamano wrote: From: Adam Spiers g...@adamspiers.org Yellow seems a more appropriate color than bold green when considering the universal traffic lights coloring scheme, where green conveys the impression that everything's OK, and amber that something's not quite right. Here are few more details about the behaviour of other testing tools, in case you want to squash them in the commit message for future references: 1. Automake (at least up to 1.13) and Autotest (at least up to the 2.69 Autoconf release) use bold green for reporting expected failures. 2. On the other hand, the 'prove' utility (as of TAP::Harness v3.23 and Perl v5.14.2) use yellow (not bold) for the same purpose. Nice to know, thanks. I re-read the above three times, trying to see how to add it to the log message, but having hard time phrasing it. The only thing the additional knowledge adds seems to be to give rationale for the old choice of bold green---it was not chosen from thin-air but can be viewed as following the automake/autotest scheme, and other systems cannot agree on what color to pick for this purpose. I do not see a need to justify why we chose differently from automake/autotest; we could say something like: Yellow seems a more appropriate color than bold green when considering the universal traffic lights coloring scheme, where green conveys the impression that everything's OK, and amber that something's not quite right. This is in line with what 'prove' uses, but different from 'automake/autotest' do. but we are not in the business of choosing which is more correct between prove and automake/autotest, and I do not see how it adds much value to tell readers that color choices are not universally agreed upon across various test software suites---that's kind of known, isn't it? So... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/7] tests: paint known breakages in yellow
On 12/21/2012 04:46 PM, Junio C Hamano wrote: [SNIP] The only thing the additional knowledge adds seems to be to give rationale for the old choice of bold green---it was not chosen from thin-air but can be viewed as following the automake/autotest scheme, and other systems cannot agree on what color to pick for this purpose. I do not see a need to justify why we chose differently from automake/autotest; we could say something like: Yellow seems a more appropriate color than bold green when considering the universal traffic lights coloring scheme, where green conveys the impression that everything's OK, and amber that something's not quite right. This is in line with what 'prove' uses, but different from 'automake/autotest' do. but we are not in the business of choosing which is more correct between prove and automake/autotest, and I do not see how it adds much value to tell readers that color choices are not universally agreed upon across various test software suites---that's kind of known, isn't it? So... That is fine with me, I just pointed it out because I suspected not everybody was aware of all these details. If you decide they don't matter, it's perfectly OK -- but at least now it's an informed choice ;-) Thanks, Stefano -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 2/7] tests: paint known breakages in yellow
From: Adam Spiers g...@adamspiers.org Yellow seems a more appropriate color than bold green when considering the universal traffic lights coloring scheme, where green conveys the impression that everything's OK, and amber that something's not quite right. Likewise, change the color of the summarized total number of known breakages from bold red to the same yellow to be less alarmist and more consistent with the above. An earlier version of this patch used bold yellow but because these are all long-known failures, reminding them to developers in bold over and over does not help encouraging them to take a look at them very much. This iteration paints them in plain yellow instead to make them less distracting. Signed-off-by: Adam Spiers g...@adamspiers.org Signed-off-by: Junio C Hamano gits...@pobox.com --- t/test-lib.sh | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index 03b86b8..72aafd0 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -183,6 +183,8 @@ then tput bold; tput setaf 1;; # bold red skip) tput bold; tput setaf 2;; # bold green + warn) + tput setaf 3;; # brown/yellow pass) tput setaf 2;;# green info) @@ -281,7 +283,7 @@ test_known_broken_ok_ () { test_known_broken_failure_ () { test_broken=$(($test_broken+1)) - say_color skip not ok $test_count - $@ # TODO known breakage + say_color warn not ok $test_count - $@ # TODO known breakage } test_debug () { @@ -375,7 +377,7 @@ test_done () { fi if test $test_broken != 0 then - say_color error # still have $test_broken known breakage(s) + say_color warn # still have $test_broken known breakage(s) msg=remaining $(($test_count-$test_broken)) test(s) else msg=$test_count test(s) -- 1.8.1.rc2.225.g8d36ab4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html