Re: [PATCH v7 2/7] tests: paint known breakages in yellow

2012-12-21 Thread Stefano Lattarini
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

2012-12-21 Thread Junio C Hamano
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

2012-12-21 Thread Stefano Lattarini
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

2012-12-20 Thread Junio C Hamano
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