On Fri, Apr 21, 2017 at 9:54 PM, Lars Schneider
[off-list ref] wrote:

quoted

Am 20.04.2017 um 23:58 schrieb Ævar Arnfjörð Bjarmason [off-list ref]:

As a refresh of everyone's memory (because mine needed it). This is a
feature I added back in 2011 when the i18n support was initially
added.

There was concern at the time that we would inadvertently mark
plumbing messages for translation, particularly something in a shared
code path, and this was a way to hopefully smoke out those issues with
the test suite.

However compiling with it breaks a couple of dozen tests, I stopped
digging when I saw some broke back in 2014.

What should be done about this? I think if we're going to keep them
they need to be run regularly by something like Travis (Lars CC'd),
however empirical evidence suggests that not running them is just fine
too, so should we just remove support for this test mode?

Right now we are building and testing Git in the following configurations:

1. Linux, gcc, stable Perforce an GitLFS version (used by git-p4 tests)
2. Linux, gcc, stable Perforce an GitLFS version (used by git-p4 tests) *
3. OSX, clang, latest Perforce an GitLFS version (used by git-p4 tests)
4. OSX, clang, latest Perforce an GitLFS version (used by git-p4 tests) *
5. Linux32, gcc, no git-p4 tests
6. Windows, gcc, no git-p4 tests

1-4 run the same tests right now. This was especially useful in the beginning to identify flaky tests (t0025 is still flaky!).

We could easily run the tests in 1-4 with different configurations. E.g. enable GETTEXT_POISON in 2.

If CI stays idle some time, I suggest adding a test run with valgrind
on 'pu' or 'next'. If there's still spare capacity I would add another
test run with GIT_TEST_SPLIT_INDEX=1 (but not right now, it's broken)

Off topic, is it possible to receive mail notifications from Travis
when a fault is found in either 'pu', 'next' or 'master'? I know how
to do it in Jenkins, but I'm not familiar with Travis and there's no
obvious button from the web page..
-- 
Duy