git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 21, 2012, 15:46 UTC
Message-ID
<7vd2y32ys0.fsf@alter.siamese.dyndns.org>
In-Reply-To
<50D4230F.9080502@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
Show 18 quoted lines
> 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...
Previous: Stefano LattariniNext: Stefano Lattarini
Message 5 of 13 in “coloring test output after traffic signal”
  1. 0/7 coloring test output after traffic signalJunio C Hamano, Dec 21, 2012
  2. 1/7 tests: test number comes first in 'not ok $count - $message'Junio C Hamano, Dec 21, 2012
  3. 2/7 tests: paint known breakages in yellowJunio C Hamano, Dec 21, 2012
  4. Stefano LattariniDec 21, 2012
  5. Junio C HamanoDec 21, 2012
  6. Stefano LattariniDec 21, 2012
  7. 3/7 tests: paint skipped tests in blueJunio C Hamano, Dec 21, 2012
  8. 4/7 tests: change info messages from yellow/brown to cyanJunio C Hamano, Dec 21, 2012
  9. 5/7 tests: refactor mechanics of testing in a sub test-libJunio C Hamano, Dec 21, 2012
  10. 6/7 tests: test the test framework more thoroughlyJunio C Hamano, Dec 21, 2012
  11. 7/7 tests: paint unexpectedly fixed known breakages in bold redJunio C Hamano, Dec 21, 2012
  12. Jeff KingDec 21, 2012
  13. Adam SpiersDec 21, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.