git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefano Lattarini <stefano.lattarini@gmail.com>
Cc: git@vger.kernel.org, Adam Spiers <git@adamspiers.org>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH v7 2/7] tests: paint known breakages in yellow
Date: Fri, 21 Dec 2012 07:46:55 -0800	[thread overview]
Message-ID: <7vd2y32ys0.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <50D4230F.9080502@gmail.com> (Stefano Lattarini's message of "Fri, 21 Dec 2012 09:51:27 +0100")

Stefano Lattarini <stefano.lattarini@gmail.com> writes:

> On 12/21/2012 04:12 AM, Junio C Hamano wrote:
>> From: Adam Spiers <git@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...

  reply	other threads:[~2012-12-21 15:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-16 18:28 [PATCH v6 0/7] make test output coloring more intuitive Adam Spiers
2012-12-16 18:28 ` [PATCH v6 1/7] tests: test number comes first in 'not ok $count - $message' Adam Spiers
2012-12-16 18:28 ` [PATCH v6 2/7] tests: paint known breakages in bold yellow Adam Spiers
2012-12-16 18:28 ` [PATCH v6 3/7] tests: paint skipped tests in bold blue Adam Spiers
2012-12-16 18:28 ` [PATCH v6 4/7] tests: change info messages from yellow/brown to bold cyan Adam Spiers
2012-12-16 18:28 ` [PATCH v6 5/7] tests: refactor mechanics of testing in a sub test-lib Adam Spiers
2012-12-16 18:28 ` [PATCH v6 6/7] tests: test the test framework more thoroughly Adam Spiers
2012-12-16 18:28 ` [PATCH v6 7/7] tests: paint unexpectedly fixed known breakages in bold red Adam Spiers
2012-12-16 18:54 ` [PATCH v6 0/7] make test output coloring more intuitive Junio C Hamano
2012-12-16 19:01   ` Adam Spiers
2012-12-16 23:11     ` Junio C Hamano
2012-12-20 15:34     ` Jeff King
2012-12-20 15:44       ` Adam Spiers
2012-12-20 16:11         ` Jeff King
2012-12-20 18:08           ` Adam Spiers
2012-12-20 19:21           ` Junio C Hamano
2012-12-20 19:50             ` Jeff King
2012-12-20 23:28             ` Adam Spiers
2012-12-21  3:12               ` [PATCH v7 0/7] coloring test output after traffic signal Junio C Hamano
2012-12-21  8:15                 ` Jeff King
2012-12-21 10:00                   ` Adam Spiers
2012-12-21  3:12               ` [PATCH v7 1/7] tests: test number comes first in 'not ok $count - $message' Junio C Hamano
2012-12-21  3:12               ` [PATCH v7 2/7] tests: paint known breakages in yellow Junio C Hamano
2012-12-21  8:51                 ` Stefano Lattarini
2012-12-21 15:46                   ` Junio C Hamano [this message]
2012-12-21 16:59                     ` Stefano Lattarini
2012-12-21  3:12               ` [PATCH v7 3/7] tests: paint skipped tests in blue Junio C Hamano
2012-12-21  3:12               ` [PATCH v7 4/7] tests: change info messages from yellow/brown to cyan Junio C Hamano
2012-12-21  3:12               ` [PATCH v7 5/7] tests: refactor mechanics of testing in a sub test-lib Junio C Hamano
2012-12-21  3:12               ` [PATCH v7 6/7] tests: test the test framework more thoroughly Junio C Hamano
2012-12-21  3:12               ` [PATCH v7 7/7] tests: paint unexpectedly fixed known breakages in bold red Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vd2y32ys0.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@adamspiers.org \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=stefano.lattarini@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).