{"thread":{"id":"45766","subject":"[BUG] test suite broken with GETTEXT_POISON=YesPlease","startedAt":"2017-04-20T21:58:56Z","lastAt":"2017-04-28T08:44:56Z","messageCount":21,"participants":["Ævar Arnfjörð Bjarmason","Lars Schneider","Michael J Gruber","Junio C Hamano","Duy Nguyen","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"317426","messageId":"CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com","threadId":"45766","inReplyTo":null,"subject":"[BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-20T21:58:20Z","receivedAt":"2017-04-20T21:58:56Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"As a refresh of everyone's memory (because mine needed it). This is a\nfeature I added back in 2011 when the i18n support was initially\nadded.\n\nThere was concern at the time that we would inadvertently mark\nplumbing messages for translation, particularly something in a shared\ncode path, and this was a way to hopefully smoke out those issues with\nthe test suite.\n\nHowever compiling with it breaks a couple of dozen tests, I stopped\ndigging when I saw some broke back in 2014.\n\nWhat should be done about this? I think if we're going to keep them\nthey need to be run regularly by something like Travis (Lars CC'd),\nhowever empirical evidence suggests that not running them is just fine\ntoo, so should we just remove support for this test mode?\n\nI don't care, but I can come up with the patch either way, but would\nonly be motivated to write the one-time fix for it if some CI system\nis actually running them regularly, otherwise they'll just be subject\nto bitrotting again.\n"},{"id":"317492","messageId":"FDAE86E2-F607-4E82-8E0C-0E6DCEF7ED67@gmail.com","threadId":"45766","inReplyTo":"CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-04-21T14:54:45Z","receivedAt":"2017-04-21T15:56:04Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> Am 20.04.2017 um 23:58 schrieb Ævar Arnfjörð Bjarmason <avarab@gmail.com>:\n> \n> As a refresh of everyone's memory (because mine needed it). This is a\n> feature I added back in 2011 when the i18n support was initially\n> added.\n> \n> There was concern at the time that we would inadvertently mark\n> plumbing messages for translation, particularly something in a shared\n> code path, and this was a way to hopefully smoke out those issues with\n> the test suite.\n> \n> However compiling with it breaks a couple of dozen tests, I stopped\n> digging when I saw some broke back in 2014.\n> \n> What should be done about this? I think if we're going to keep them\n> they need to be run regularly by something like Travis (Lars CC'd),\n> however empirical evidence suggests that not running them is just fine\n> too, so should we just remove support for this test mode?\n\nRight now we are building and testing Git in the following configurations:\n\n1. Linux, gcc, stable Perforce an GitLFS version (used by git-p4 tests)\n2. Linux, gcc, stable Perforce an GitLFS version (used by git-p4 tests) *\n3. OSX, clang, latest Perforce an GitLFS version (used by git-p4 tests)\n4. OSX, clang, latest Perforce an GitLFS version (used by git-p4 tests) *\n5. Linux32, gcc, no git-p4 tests\n6. Windows, gcc, no git-p4 tests\n\n1-4 run the same tests right now. This was especially useful in the beginning to identify flaky tests (t0025 is still flaky!).\n\nWe could easily run the tests in 1-4 with different configurations. E.g. enable GETTEXT_POISON in 2.\n\nCheers,\nLars\n\n*) 2 and 4 use the wrong compiler right now. 2 should use clang on Linux and 4 should use gcc. A patch is on my todo list."},{"id":"317494","messageId":"e7aed763-cf46-4d7e-1b11-0a7a65b8f496@grubix.eu","threadId":"45766","inReplyTo":"CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-04-21T14:47:12Z","receivedAt":"2017-04-21T17:01:28Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Ævar Arnfjörð Bjarmason venit, vidit, dixit 20.04.2017 23:58:\n> As a refresh of everyone's memory (because mine needed it). This is a\n> feature I added back in 2011 when the i18n support was initially\n> added.\n> \n> There was concern at the time that we would inadvertently mark\n> plumbing messages for translation, particularly something in a shared\n> code path, and this was a way to hopefully smoke out those issues with\n> the test suite.\n> \n> However compiling with it breaks a couple of dozen tests, I stopped\n> digging when I saw some broke back in 2014.\n> \n> What should be done about this? I think if we're going to keep them\n> they need to be run regularly by something like Travis (Lars CC'd),\n> however empirical evidence suggests that not running them is just fine\n> too, so should we just remove support for this test mode?\n> \n> I don't care, but I can come up with the patch either way, but would\n> only be motivated to write the one-time fix for it if some CI system\n> is actually running them regularly, otherwise they'll just be subject\n> to bitrotting again.\n> \n\nI use that switch when I change something that involves l10n, but\nusually I run specific tests only. To be honest: I have to make sure not\nto get confused by (nor forget one of) the build flag GETTEXT_POISON and\nthe environment variable GIT_GETTEXT_POISON. I'm not sure I always\ntested what I meant to test...\n\nMichael\n"},{"id":"317497","messageId":"CACBZZX5h90jM4B8GOjt6-L+YNb7vR4qtxHmRwQMFCmHLHRqMKg@mail.gmail.com","threadId":"45766","inReplyTo":"FDAE86E2-F607-4E82-8E0C-0E6DCEF7ED67@gmail.com","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-21T18:05:11Z","receivedAt":"2017-04-21T18:07:08Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Apr 21, 2017 at 4:54 PM, Lars Schneider\n<larsxschneider@gmail.com> wrote:\n>\n>> Am 20.04.2017 um 23:58 schrieb Ævar Arnfjörð Bjarmason <avarab@gmail.com>:\n>>\n>> As a refresh of everyone's memory (because mine needed it). This is a\n>> feature I added back in 2011 when the i18n support was initially\n>> added.\n>>\n>> There was concern at the time that we would inadvertently mark\n>> plumbing messages for translation, particularly something in a shared\n>> code path, and this was a way to hopefully smoke out those issues with\n>> the test suite.\n>>\n>> However compiling with it breaks a couple of dozen tests, I stopped\n>> digging when I saw some broke back in 2014.\n>>\n>> What should be done about this? I think if we're going to keep them\n>> they need to be run regularly by something like Travis (Lars CC'd),\n>> however empirical evidence suggests that not running them is just fine\n>> too, so should we just remove support for this test mode?\n>\n> Right now we are building and testing Git in the following configurations:\n>\n> 1. Linux, gcc, stable Perforce an GitLFS version (used by git-p4 tests)\n> 2. Linux, gcc, stable Perforce an GitLFS version (used by git-p4 tests) *\n> 3. OSX, clang, latest Perforce an GitLFS version (used by git-p4 tests)\n> 4. OSX, clang, latest Perforce an GitLFS version (used by git-p4 tests) *\n> 5. Linux32, gcc, no git-p4 tests\n> 6. Windows, gcc, no git-p4 tests\n>\n> 1-4 run the same tests right now. This was especially useful in the beginning to identify flaky tests (t0025 is still flaky!).\n>\n> We could easily run the tests in 1-4 with different configurations. E.g. enable GETTEXT_POISON in 2.\n>\n> Cheers,\n> Lars\n>\n> *) 2 and 4 use the wrong compiler right now. 2 should use clang on Linux and 4 should use gcc. A patch is on my todo list.\n\nGreat, thanks. I'll fixup the poison tests then.\n"},{"id":"317501","messageId":"CACBZZX5t43FWGOFeOEZs9gv3sGrv4Y1ZbapHXY2wLEC18ZU-HA@mail.gmail.com","threadId":"45766","inReplyTo":"e7aed763-cf46-4d7e-1b11-0a7a65b8f496@grubix.eu","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-21T17:28:22Z","receivedAt":"2017-04-21T18:29:25Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Apr 21, 2017 at 4:47 PM, Michael J Gruber <git@grubix.eu> wrote:\n> Ævar Arnfjörð Bjarmason venit, vidit, dixit 20.04.2017 23:58:\n>> As a refresh of everyone's memory (because mine needed it). This is a\n>> feature I added back in 2011 when the i18n support was initially\n>> added.\n>>\n>> There was concern at the time that we would inadvertently mark\n>> plumbing messages for translation, particularly something in a shared\n>> code path, and this was a way to hopefully smoke out those issues with\n>> the test suite.\n>>\n>> However compiling with it breaks a couple of dozen tests, I stopped\n>> digging when I saw some broke back in 2014.\n>>\n>> What should be done about this? I think if we're going to keep them\n>> they need to be run regularly by something like Travis (Lars CC'd),\n>> however empirical evidence suggests that not running them is just fine\n>> too, so should we just remove support for this test mode?\n>>\n>> I don't care, but I can come up with the patch either way, but would\n>> only be motivated to write the one-time fix for it if some CI system\n>> is actually running them regularly, otherwise they'll just be subject\n>> to bitrotting again.\n>>\n>\n> I use that switch when I change something that involves l10n, but\n> usually I run specific tests only. To be honest: I have to make sure not\n> to get confused by (nor forget one of) the build flag GETTEXT_POISON and\n> the environment variable GIT_GETTEXT_POISON. I'm not sure I always\n> tested what I meant to test...\n\nFor any of the built-in tests, you just need to compile git with\nGETTEXT_POISON=YesPlease, the env var is set by test-lib.sh for you,\nyou only need to set GIT_GETTEXT_POISON=1 if you're ad-hoc running\nsome git command yourself, e.g.:\n\n$ ./git status\nOn branch master\nYour branch is up-to-date with 'origin/master'.\nnothing to commit, working tree clean\n$ GIT_GETTEXT_POISON=1 ./git status\n# GETTEXT POISON #master\n# GETTEXT POISON #\n"},{"id":"317508","messageId":"20170421185757.28978-1-avarab@gmail.com","threadId":"45766","inReplyTo":"FDAE86E2-F607-4E82-8E0C-0E6DCEF7ED67@gmail.com","subject":"[PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-21T18:57:57Z","receivedAt":"2017-04-21T18:58:13Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"The GETTEXT_POISON=YesPlease compile-time testing option added in my\nbb946bba76 (\"i18n: add GETTEXT_POISON to simulate unfriendly\ntranslator\", 2011-02-22) has been slowly bitrotting as strings have\nbeen marked for translation, and new tests have been added without\nrunning it.\n\nI brought this up on the list (\"[BUG] test suite broken with\nGETTEXT_POISON=YesPlease\", [1]) asking whether this mode was useful at\nall anymore. At least one person occasionally uses it, and Lars\nSchneider offered to change one of the the Travis builds to run in\nthis mode, so fix up the failing ones.\n\nMy test setup runs most of the tests, with the notable exception of\nskipping all the p4 tests, so it's possible that there's still some\nlurking regressions I haven't fixed.\n\n1. <CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com>\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n t/t1309-early-config.sh          |  2 +-\n t/t1430-bad-ref-name.sh          |  2 +-\n t/t3203-branch-output.sh         |  2 +-\n t/t3404-rebase-interactive.sh    | 14 +++++++-------\n t/t3415-rebase-autosquash.sh     | 10 +++++-----\n t/t3903-stash.sh                 |  4 ++--\n t/t4205-log-pretty-formats.sh    |  4 ++--\n t/t5316-pack-delta-depth.sh      |  8 ++++++--\n t/t6134-pathspec-in-submodule.sh |  4 ++--\n t/t7004-tag.sh                   |  4 ++--\n t/t7406-submodule-update.sh      |  2 +-\n t/t7509-commit.sh                |  4 ++--\n t/t7800-difftool.sh              |  4 ++--\n 13 files changed, 34 insertions(+), 30 deletions(-)\n\ndiff --git a/t/t1309-early-config.sh b/t/t1309-early-config.sh\nindex b97357b8ab..016e43b8d5 100755\n--- a/t/t1309-early-config.sh\n+++ b/t/t1309-early-config.sh\n@@ -59,7 +59,7 @@ test_with_config () {\n \n test_expect_success 'ignore .git/ with incompatible repository version' '\n \ttest_with_config \"[core]repositoryformatversion = 999999\" 2>err &&\n-\tgrep \"warning:.* Expected git repo version <= [1-9]\" err\n+\ttest_i18ngrep \"warning:.* Expected git repo version <= [1-9]\" err\n '\n \n test_expect_failure 'ignore .git/ with invalid repository version' '\ndiff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh\nindex 8937e25e49..2003ec7907 100755\n--- a/t/t1430-bad-ref-name.sh\n+++ b/t/t1430-bad-ref-name.sh\n@@ -122,7 +122,7 @@ test_expect_success 'push cannot create a badly named ref' '\n \t! grep -e \"broken\\.\\.\\.ref\" output\n '\n \n-test_expect_failure 'push --mirror can delete badly named ref' '\n+test_expect_failure !GETTEXT_POISON 'push --mirror can delete badly named ref' '\n \ttop=$(pwd) &&\n \tgit init src &&\n \tgit init dest &&\ndiff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh\nindex 5778c0afe1..a428ae6703 100755\n--- a/t/t3203-branch-output.sh\n+++ b/t/t3203-branch-output.sh\n@@ -236,7 +236,7 @@ test_expect_success 'git branch --format option' '\n \tRefname is refs/heads/ref-to-remote\n \tEOF\n \tgit branch --format=\"Refname is %(refname)\" >actual &&\n-\ttest_cmp expect actual\n+\ttest_i18ncmp expect actual\n '\n \n test_done\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex 33d392ba11..e07d6d8cd2 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -366,7 +366,7 @@ test_expect_success 'verbose flag is heeded, even after --continue' '\n \tgrep \"^ file1 | 2 +-$\" output\n '\n \n-test_expect_success 'multi-squash only fires up editor once' '\n+test_expect_success !GETTEXT_POISON 'multi-squash only fires up editor once' '\n \tbase=$(git rev-parse HEAD~4) &&\n \tset_fake_editor &&\n \tFAKE_COMMIT_AMEND=\"ONCE\" FAKE_LINES=\"1 squash 2 squash 3 squash 4\" \\\n@@ -376,7 +376,7 @@ test_expect_success 'multi-squash only fires up editor once' '\n \ttest 1 = $(git show | grep ONCE | wc -l)\n '\n \n-test_expect_success 'multi-fixup does not fire up editor' '\n+test_expect_success !GETTEXT_POISON 'multi-fixup does not fire up editor' '\n \tgit checkout -b multi-fixup E &&\n \tbase=$(git rev-parse HEAD~4) &&\n \tset_fake_editor &&\n@@ -426,7 +426,7 @@ D\n ONCE\n EOF\n \n-test_expect_success 'squash and fixup generate correct log messages' '\n+test_expect_success !GETTEXT_POISON 'squash and fixup generate correct log messages' '\n \tgit checkout -b squash-fixup E &&\n \tbase=$(git rev-parse HEAD~4) &&\n \tset_fake_editor &&\n@@ -439,7 +439,7 @@ test_expect_success 'squash and fixup generate correct log messages' '\n \tgit branch -D squash-fixup\n '\n \n-test_expect_success 'squash ignores comments' '\n+test_expect_success !GETTEXT_POISON 'squash ignores comments' '\n \tgit checkout -b skip-comments E &&\n \tbase=$(git rev-parse HEAD~4) &&\n \tset_fake_editor &&\n@@ -452,7 +452,7 @@ test_expect_success 'squash ignores comments' '\n \tgit branch -D skip-comments\n '\n \n-test_expect_success 'squash ignores blank lines' '\n+test_expect_success !GETTEXT_POISON 'squash ignores blank lines' '\n \tgit checkout -b skip-blank-lines E &&\n \tbase=$(git rev-parse HEAD~4) &&\n \tset_fake_editor &&\n@@ -860,7 +860,7 @@ test_expect_success 'rebase -ix with several instances of --exec' '\n \ttest_cmp expected actual\n '\n \n-test_expect_success 'rebase -ix with --autosquash' '\n+test_expect_success !GETTEXT_POISON 'rebase -ix with --autosquash' '\n \tgit reset --hard execute &&\n \tgit checkout -b autosquash &&\n \techo second >second.txt &&\n@@ -943,7 +943,7 @@ test_expect_success 'rebase -i --root fixup root commit' '\n \ttest 0 = $(git cat-file commit HEAD | grep -c ^parent\\ )\n '\n \n-test_expect_success 'rebase --edit-todo does not works on non-interactive rebase' '\n+test_expect_success !GETTEXT_POISON 'rebase --edit-todo does not work on non-interactive rebase' '\n \tgit reset --hard &&\n \tgit checkout conflict-branch &&\n \tset_fake_editor &&\ndiff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh\nindex 48346f1cc0..b7265460f5 100755\n--- a/t/t3415-rebase-autosquash.sh\n+++ b/t/t3415-rebase-autosquash.sh\n@@ -234,23 +234,23 @@ test_auto_fixup_fixup () {\n \tfi\n }\n \n-test_expect_success 'fixup! fixup!' '\n+test_expect_success !GETTEXT_POISON 'fixup! fixup!' '\n \ttest_auto_fixup_fixup fixup fixup\n '\n \n-test_expect_success 'fixup! squash!' '\n+test_expect_success !GETTEXT_POISON 'fixup! squash!' '\n \ttest_auto_fixup_fixup fixup squash\n '\n \n-test_expect_success 'squash! squash!' '\n+test_expect_success !GETTEXT_POISON 'squash! squash!' '\n \ttest_auto_fixup_fixup squash squash\n '\n \n-test_expect_success 'squash! fixup!' '\n+test_expect_success !GETTEXT_POISON 'squash! fixup!' '\n \ttest_auto_fixup_fixup squash fixup\n '\n \n-test_expect_success 'autosquash with custom inst format' '\n+test_expect_success !GETTEXT_POISON 'autosquash with custom inst format' '\n \tgit reset --hard base &&\n \tgit config --add rebase.instructionFormat \"[%an @ %ar] %s\"  &&\n \techo 2 >file1 &&\ndiff --git a/t/t3903-stash.sh b/t/t3903-stash.sh\nindex b71d1e659e..3b4bed5c9a 100755\n--- a/t/t3903-stash.sh\n+++ b/t/t3903-stash.sh\n@@ -865,7 +865,7 @@ test_expect_success 'stash push -p with pathspec shows no changes only once' '\n \tgit stash push -p foo >actual &&\n \techo \"No local changes to save\" >expect &&\n \tgit reset --hard HEAD~ &&\n-\ttest_cmp expect actual\n+\ttest_i18ncmp expect actual\n '\n \n test_expect_success 'stash push with pathspec shows no changes when there are none' '\n@@ -875,7 +875,7 @@ test_expect_success 'stash push with pathspec shows no changes when there are no\n \tgit stash push foo >actual &&\n \techo \"No local changes to save\" >expect &&\n \tgit reset --hard HEAD~ &&\n-\ttest_cmp expect actual\n+\ttest_i18ncmp expect actual\n '\n \n test_expect_success 'stash push with pathspec not in the repository errors out' '\ndiff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh\nindex 21eb8c8587..1322bd461b 100755\n--- a/t/t4205-log-pretty-formats.sh\n+++ b/t/t4205-log-pretty-formats.sh\n@@ -126,12 +126,12 @@ test_expect_success 'NUL separation with --stat' '\n \ttest_i18ncmp expected actual\n '\n \n-test_expect_failure 'NUL termination with --stat' '\n+test_expect_failure !GETTEXT_POISON 'NUL termination with --stat' '\n \tstat0_part=$(git diff --stat HEAD^ HEAD) &&\n \tstat1_part=$(git diff-tree --no-commit-id --stat --root HEAD^) &&\n \tprintf \"add bar\\n$stat0_part\\n\\0$(commit_msg)\\n$stat1_part\\n0\" >expected &&\n \tgit log -z --stat --pretty=\"tformat:%s\" >actual &&\n-\ttest_i18ncmp expected actual\n+\ttest_cmp expected actual\n '\n \n test_expect_success 'setup more commits' '\ndiff --git a/t/t5316-pack-delta-depth.sh b/t/t5316-pack-delta-depth.sh\nindex 37143ea0ac..2ed479b712 100755\n--- a/t/t5316-pack-delta-depth.sh\n+++ b/t/t5316-pack-delta-depth.sh\n@@ -82,12 +82,16 @@ test_expect_success 'packing produces a long delta' '\n \t# Use --window=0 to make sure we are seeing reused deltas,\n \t# not computing a new long chain.\n \tpack=$(git pack-objects --all --window=0 </dev/null pack) &&\n-\ttest 9 = \"$(max_chain pack-$pack.pack)\"\n+\techo 9 >expect &&\n+\tmax_chain pack-$pack.pack >actual &&\n+\ttest_i18ncmp expect actual\n '\n \n test_expect_success '--depth limits depth' '\n \tpack=$(git pack-objects --all --depth=5 </dev/null pack) &&\n-\ttest 5 = \"$(max_chain pack-$pack.pack)\"\n+\techo 5 >expect &&\n+\tmax_chain pack-$pack.pack >actual &&\n+\ttest_i18ncmp expect actual\n '\n \n test_done\ndiff --git a/t/t6134-pathspec-in-submodule.sh b/t/t6134-pathspec-in-submodule.sh\nindex fd401ca605..99a8982ab1 100755\n--- a/t/t6134-pathspec-in-submodule.sh\n+++ b/t/t6134-pathspec-in-submodule.sh\n@@ -21,7 +21,7 @@ EOF\n test_expect_success 'error message for path inside submodule' '\n \techo a >sub/a &&\n \ttest_must_fail git add sub/a 2>actual &&\n-\ttest_cmp expect actual\n+\ttest_i18ncmp expect actual\n '\n \n cat <<EOF >expect\n@@ -30,7 +30,7 @@ EOF\n \n test_expect_success 'error message for path inside submodule from within submodule' '\n \ttest_must_fail git -C sub add . 2>actual &&\n-\ttest_cmp expect actual\n+\ttest_i18ncmp expect actual\n '\n \n test_done\ndiff --git a/t/t7004-tag.sh b/t/t7004-tag.sh\nindex bb2e4d704d..0ef7b94394 100755\n--- a/t/t7004-tag.sh\n+++ b/t/t7004-tag.sh\n@@ -87,7 +87,7 @@ test_expect_success 'creating a tag with --create-reflog should create reflog' '\n \tgit tag --create-reflog tag_with_reflog &&\n \tgit reflog exists refs/tags/tag_with_reflog &&\n \tsed -e \"s/^.*\t//\" .git/logs/refs/tags/tag_with_reflog >actual &&\n-\ttest_cmp expected actual\n+\ttest_i18ncmp expected actual\n '\n \n test_expect_success 'annotated tag with --create-reflog has correct message' '\n@@ -98,7 +98,7 @@ test_expect_success 'annotated tag with --create-reflog has correct message' '\n \tgit tag -m \"annotated tag\" --create-reflog tag_with_reflog &&\n \tgit reflog exists refs/tags/tag_with_reflog &&\n \tsed -e \"s/^.*\t//\" .git/logs/refs/tags/tag_with_reflog >actual &&\n-\ttest_cmp expected actual\n+\ttest_i18ncmp expected actual\n '\n \n test_expect_success '--create-reflog does not create reflog on failure' '\ndiff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh\nindex 4ac386d98b..034914a14f 100755\n--- a/t/t7406-submodule-update.sh\n+++ b/t/t7406-submodule-update.sh\n@@ -447,7 +447,7 @@ test_expect_success 'submodule update - command run for initial population of su\n \tEOF\n \trm -rf super/submodule &&\n \ttest_must_fail git -C super submodule update 2>actual &&\n-\ttest_cmp expect actual &&\n+\ttest_i18ncmp expect actual &&\n \tgit -C super submodule update --checkout\n '\n \ndiff --git a/t/t7509-commit.sh b/t/t7509-commit.sh\nindex db9774e345..ddef7ea6b0 100755\n--- a/t/t7509-commit.sh\n+++ b/t/t7509-commit.sh\n@@ -101,7 +101,7 @@ test_expect_success '--amend option with empty author' '\n \techo \"Empty author test\" >>foo &&\n \ttest_tick &&\n \ttest_must_fail git commit -a -m \"empty author\" --amend 2>err &&\n-\tgrep \"empty ident\" err\n+\ttest_i18ngrep \"empty ident\" err\n '\n \n test_expect_success '--amend option with missing author' '\n@@ -114,7 +114,7 @@ test_expect_success '--amend option with missing author' '\n \techo \"Missing author test\" >>foo &&\n \ttest_tick &&\n \ttest_must_fail git commit -a -m \"malformed author\" --amend 2>err &&\n-\tgrep \"empty ident\" err\n+\ttest_i18ngrep \"empty ident\" err\n '\n \n test_expect_success '--reset-author makes the commit ours even with --amend option' '\ndiff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh\nindex 7f09867478..668bbee73c 100755\n--- a/t/t7800-difftool.sh\n+++ b/t/t7800-difftool.sh\n@@ -25,14 +25,14 @@ prompt_given ()\n \n test_expect_success 'basic usage requires no repo' '\n \ttest_expect_code 129 git difftool -h >output &&\n-\tgrep ^usage: output &&\n+\ttest_i18ngrep ^usage: output &&\n \t# create a ceiling directory to prevent Git from finding a repo\n \tmkdir -p not/repo &&\n \ttest_when_finished rm -r not &&\n \ttest_expect_code 129 \\\n \tenv GIT_CEILING_DIRECTORIES=\"$(pwd)/not\" \\\n \tgit -C not/repo difftool -h >output &&\n-\tgrep ^usage: output\n+\ttest_i18ngrep ^usage: output\n '\n \n # Create a file on master and change it on branch\n-- \n2.11.0\n\n"},{"id":"317624","messageId":"xmqq1ssi4nci.fsf@gitster.mtv.corp.google.com","threadId":"45766","inReplyTo":"20170421185757.28978-1-avarab@gmail.com","subject":"Re: [PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-24T01:15:57Z","receivedAt":"2017-04-24T01:16:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:\n\n> The GETTEXT_POISON=YesPlease compile-time testing option added in my\n> bb946bba76 (\"i18n: add GETTEXT_POISON to simulate unfriendly\n> translator\", 2011-02-22) has been slowly bitrotting as strings have\n> been marked for translation, and new tests have been added without\n> running it.\n>\n> I brought this up on the list (\"[BUG] test suite broken with\n> GETTEXT_POISON=YesPlease\", [1]) asking whether this mode was useful at\n> all anymore. At least one person occasionally uses it, and Lars\n> Schneider offered to change one of the the Travis builds to run in\n> this mode, so fix up the failing ones.\n>\n> My test setup runs most of the tests, with the notable exception of\n> skipping all the p4 tests, so it's possible that there's still some\n> lurking regressions I haven't fixed.\n>\n> 1. <CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com>\n\nTo be honest, I feel quite uneasy about this patch.  It is no\nbrainer to take fixes like the one to 1309 where we used grep on a\nlocalizable string to use test_i18ngrep instead---they are obviously\ngood changes.\n\nBut changes that skip tests with !GETTEXT_POISON look suspicious.\n\n> diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh\n> index 8937e25e49..2003ec7907 100755\n> --- a/t/t1430-bad-ref-name.sh\n> +++ b/t/t1430-bad-ref-name.sh\n> @@ -122,7 +122,7 @@ test_expect_success 'push cannot create a badly named ref' '\n>  \t! grep -e \"broken\\.\\.\\.ref\" output\n>  '\n>  \n> -test_expect_failure 'push --mirror can delete badly named ref' '\n> +test_expect_failure !GETTEXT_POISON 'push --mirror can delete badly named ref' '\n>  \ttop=$(pwd) &&\n>  \tgit init src &&\n>  \tgit init dest &&\n\nThis test affects only src and dest repositories that does not seem\nto be looked at by later tests, so skipping it is presumably safe.\n\nI am guessing that the reason why this is skipped is because the\nerror message is looked at with \"! grep \", not \"grep\", but by\nskipping the entire test, we are not checking that \"push\" succeeds\n(which should happen regardless of the locale).\n\nIt also is VERY curious that the test before this one (whose tail is\nvisible in the pre-context) does not need to be skipped.  Is that\nbecause we can expect \"broken...ref\", which is litrally a part of a\nrefname, would be emitted intact in any locale (including the\npoisoned one)?  If that is the case it is curous why this one needs\nto be skipped.\n\n> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh\n> index 5778c0afe1..a428ae6703 100755\n> --- a/t/t3203-branch-output.sh\n> +++ b/t/t3203-branch-output.sh\n> @@ -236,7 +236,7 @@ test_expect_success 'git branch --format option' '\n>  \tRefname is refs/heads/ref-to-remote\n>  \tEOF\n>  \tgit branch --format=\"Refname is %(refname)\" >actual &&\n> -\ttest_cmp expect actual\n> +\ttest_i18ncmp expect actual\n>  '\n\nThis is a strange change.  Filling the placeholder in a format\nstring \"Refname is %(refname)\" should be affeced by i18n???\n\n> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\n> index 33d392ba11..e07d6d8cd2 100755\n> --- a/t/t3404-rebase-interactive.sh\n> +++ b/t/t3404-rebase-interactive.sh\n> @@ -366,7 +366,7 @@ test_expect_success 'verbose flag is heeded, even after --\n> ...\n> -test_expect_success 'multi-squash only fires up editor once' '\n> +test_expect_success !GETTEXT_POISON 'multi-squash only fires up editor once' '\n>  \tbase=$(git rev-parse HEAD~4) &&\n>  \tset_fake_editor &&\n>  \tFAKE_COMMIT_AMEND=\"ONCE\" FAKE_LINES=\"1 squash 2 squash 3 squash 4\" \\\n\nThis is also curious.  Is this because the poison locale does not substitute\nanything passed to format template and literal strings like ONCE and\nthe instructions do not reach the edited file?\n\n (skipping many changes, not because I find nothing to comment on them)\n\n> diff --git a/t/t5316-pack-delta-depth.sh b/t/t5316-pack-delta-depth.sh\n> index 37143ea0ac..2ed479b712 100755\n> --- a/t/t5316-pack-delta-depth.sh\n> +++ b/t/t5316-pack-delta-depth.sh\n> @@ -82,12 +82,16 @@ test_expect_success 'packing produces a long delta' '\n>  \t# Use --window=0 to make sure we are seeing reused deltas,\n>  \t# not computing a new long chain.\n>  \tpack=$(git pack-objects --all --window=0 </dev/null pack) &&\n> -\ttest 9 = \"$(max_chain pack-$pack.pack)\"\n> +\techo 9 >expect &&\n> +\tmax_chain pack-$pack.pack >actual &&\n> +\ttest_i18ncmp expect actual\n>  '\n\nThis is also curious.  Why do we needto protect comparision with a\nline whose contents is '9' from poison locale?  If the last one were\ntest_cmp I think this is a good change, by the way.\n\n>  test_expect_success '--depth limits depth' '\n>  \tpack=$(git pack-objects --all --depth=5 </dev/null pack) &&\n> -\ttest 5 = \"$(max_chain pack-$pack.pack)\"\n> +\techo 5 >expect &&\n> +\tmax_chain pack-$pack.pack >actual &&\n> +\ttest_i18ncmp expect actual\n>  '\n\nLikewise.\n\n"},{"id":"317625","messageId":"xmqqwpaa38o2.fsf@gitster.mtv.corp.google.com","threadId":"45766","inReplyTo":"e7aed763-cf46-4d7e-1b11-0a7a65b8f496@grubix.eu","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-24T01:18:21Z","receivedAt":"2017-04-24T01:18:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@grubix.eu> writes:\n\n> Ævar Arnfjörð Bjarmason venit, vidit, dixit 20.04.2017 23:58:\n>> As a refresh of everyone's memory (because mine needed it). This is a\n>> feature I added back in 2011 when the i18n support was initially\n>> added.\n>> \n>> There was concern at the time that we would inadvertently mark\n>> plumbing messages for translation, particularly something in a shared\n>> code path, and this was a way to hopefully smoke out those issues with\n>> the test suite.\n>> \n>> However compiling with it breaks a couple of dozen tests, I stopped\n>> digging when I saw some broke back in 2014.\n>> \n>> What should be done about this? I think if we're going to keep them\n>> they need to be run regularly by something like Travis (Lars CC'd),\n>> however empirical evidence suggests that not running them is just fine\n>> too, so should we just remove support for this test mode?\n>> \n>> I don't care, but I can come up with the patch either way, but would\n>> only be motivated to write the one-time fix for it if some CI system\n>> is actually running them regularly, otherwise they'll just be subject\n>> to bitrotting again.\n>\n> I use that switch when I change something that involves l10n, but\n> usually I run specific tests only. To be honest: I have to make sure not\n> to get confused by (nor forget one of) the build flag GETTEXT_POISON and\n> the environment variable GIT_GETTEXT_POISON. I'm not sure I always\n> tested what I meant to test...\n\nTo be quite honest, I have always felt that we are just as likely\ninadvertently use test_i18ncmp when we should use test_cmp (and vice\nversa) as we would mark plumbing messages with _() by mistake with\nthis approach, and even with constant monitoring by something like\nTravis, GETTEXT_POISON may be able to catch mistakes only some of\nthe time (i.e. when we do not make mistakes in writing our tests).\nWithout constant monitoring, I agree that the mechanism does not\nwork well to catch our mistakes.\n\n"},{"id":"317651","messageId":"CACBZZX63VQK4fLSB2T8onXJ_hQE8dkOCAyFFM-C_yOfoMwxLMA@mail.gmail.com","threadId":"45766","inReplyTo":"xmqq1ssi4nci.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-24T08:18:15Z","receivedAt":"2017-04-24T08:20:40Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Apr 24, 2017 at 3:15 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:\n>\n>> The GETTEXT_POISON=YesPlease compile-time testing option added in my\n>> bb946bba76 (\"i18n: add GETTEXT_POISON to simulate unfriendly\n>> translator\", 2011-02-22) has been slowly bitrotting as strings have\n>> been marked for translation, and new tests have been added without\n>> running it.\n>>\n>> I brought this up on the list (\"[BUG] test suite broken with\n>> GETTEXT_POISON=YesPlease\", [1]) asking whether this mode was useful at\n>> all anymore. At least one person occasionally uses it, and Lars\n>> Schneider offered to change one of the the Travis builds to run in\n>> this mode, so fix up the failing ones.\n>>\n>> My test setup runs most of the tests, with the notable exception of\n>> skipping all the p4 tests, so it's possible that there's still some\n>> lurking regressions I haven't fixed.\n>>\n>> 1. <CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com>\n>\n> To be honest, I feel quite uneasy about this patch.  It is no\n> brainer to take fixes like the one to 1309 where we used grep on a\n> localizable string to use test_i18ngrep instead---they are obviously\n> good changes.\n>\n> But changes that skip tests with !GETTEXT_POISON look suspicious.\n>\n>> diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh\n>> index 8937e25e49..2003ec7907 100755\n>> --- a/t/t1430-bad-ref-name.sh\n>> +++ b/t/t1430-bad-ref-name.sh\n>> @@ -122,7 +122,7 @@ test_expect_success 'push cannot create a badly named ref' '\n>>       ! grep -e \"broken\\.\\.\\.ref\" output\n>>  '\n>>\n>> -test_expect_failure 'push --mirror can delete badly named ref' '\n>> +test_expect_failure !GETTEXT_POISON 'push --mirror can delete badly named ref' '\n>>       top=$(pwd) &&\n>>       git init src &&\n>>       git init dest &&\n>\n> This test affects only src and dest repositories that does not seem\n> to be looked at by later tests, so skipping it is presumably safe.\n>\n> I am guessing that the reason why this is skipped is because the\n> error message is looked at with \"! grep \", not \"grep\", but by\n> skipping the entire test, we are not checking that \"push\" succeeds\n> (which should happen regardless of the locale).\n>\n> It also is VERY curious that the test before this one (whose tail is\n> visible in the pre-context) does not need to be skipped.  Is that\n> because we can expect \"broken...ref\", which is litrally a part of a\n> refname, would be emitted intact in any locale (including the\n> poisoned one)?  If that is the case it is curous why this one needs\n> to be skipped.\n\nThis turns out to just be a mistake of mine that didn't need\n!GETTEXT_POISON at all. Are you OK with fixing that up, or do you want\na v2 due to comments below...?\n\n>> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh\n>> index 5778c0afe1..a428ae6703 100755\n>> --- a/t/t3203-branch-output.sh\n>> +++ b/t/t3203-branch-output.sh\n>> @@ -236,7 +236,7 @@ test_expect_success 'git branch --format option' '\n>>       Refname is refs/heads/ref-to-remote\n>>       EOF\n>>       git branch --format=\"Refname is %(refname)\" >actual &&\n>> -     test_cmp expect actual\n>> +     test_i18ncmp expect actual\n>>  '\n>\n> This is a strange change.  Filling the placeholder in a format\n> string \"Refname is %(refname)\" should be affeced by i18n???\n\nIt's because %(refname) itself will get i18n'd:\n\n    -Refname is (HEAD detached from fromtag)\n    +Refname is # GETTEXT POISON #\n\nSee c8183cd285 (\"branch: show more information when HEAD is detached\",\n2013-03-13).\n\n>> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\n>> index 33d392ba11..e07d6d8cd2 100755\n>> --- a/t/t3404-rebase-interactive.sh\n>> +++ b/t/t3404-rebase-interactive.sh\n>> @@ -366,7 +366,7 @@ test_expect_success 'verbose flag is heeded, even after --\n>> ...\n>> -test_expect_success 'multi-squash only fires up editor once' '\n>> +test_expect_success !GETTEXT_POISON 'multi-squash only fires up editor once' '\n>>       base=$(git rev-parse HEAD~4) &&\n>>       set_fake_editor &&\n>>       FAKE_COMMIT_AMEND=\"ONCE\" FAKE_LINES=\"1 squash 2 squash 3 squash 4\" \\\n>\n> This is also curious.  Is this because the poison locale does not substitute\n> anything passed to format template and literal strings like ONCE and\n> the instructions do not reach the edited file?\n\nI don't know the root cause for why that fails, I spent some time\nre-digging into that for ~10m and didn't come up with anything.\n\nWe've marked many of these rebase messages in the past, it's usually\nsome stray newline being needed which the poison machinery didn't emit\nor something like that.\n\nMy general approach when writing & maintaining this poison has been\nthat it's fine if we skip some tests, even though we could be bending\nover backwards to run them, or even if we don't know the root cause\nbeyond \"the rebase machinery is always broken with poison\".\n\nThis is because once I'm satisfied that the breaking test isn't\nbecause of some new plumbing message that got i18n'd I don't see the\npoint of keeping digging, it's fine to just skip the test, because we\nrun it when we're not under poison, and we're satisfied that it's not\nbreaking because of a new plumbing message being i18n'd we've\nfulfilled the entire reason for why this poison facility exists in the\nfirst place.\n\n>  (skipping many changes, not because I find nothing to comment on them)\n>\n>> diff --git a/t/t5316-pack-delta-depth.sh b/t/t5316-pack-delta-depth.sh\n>> index 37143ea0ac..2ed479b712 100755\n>> --- a/t/t5316-pack-delta-depth.sh\n>> +++ b/t/t5316-pack-delta-depth.sh\n>> @@ -82,12 +82,16 @@ test_expect_success 'packing produces a long delta' '\n>>       # Use --window=0 to make sure we are seeing reused deltas,\n>>       # not computing a new long chain.\n>>       pack=$(git pack-objects --all --window=0 </dev/null pack) &&\n>> -     test 9 = \"$(max_chain pack-$pack.pack)\"\n>> +     echo 9 >expect &&\n>> +     max_chain pack-$pack.pack >actual &&\n>> +     test_i18ncmp expect actual\n>>  '\n>\n> This is also curious.  Why do we needto protect comparision with a\n> line whose contents is '9' from poison locale?  If the last one were\n> test_cmp I think this is a good change, by the way.\n>\n>>  test_expect_success '--depth limits depth' '\n>>       pack=$(git pack-objects --all --depth=5 </dev/null pack) &&\n>> -     test 5 = \"$(max_chain pack-$pack.pack)\"\n>> +     echo 5 >expect &&\n>> +     max_chain pack-$pack.pack >actual &&\n>> +     test_i18ncmp expect actual\n>>  '\n\nThe 9/5 value here is the number of lines that match /chain length/ as\ndetermined my max_chain, that message is i18n'd.\n"},{"id":"317678","messageId":"CACsJy8BceB96D39gbjTFx=XQZ6ATHYYQGMRSeV=u4C3jEvTDbQ@mail.gmail.com","threadId":"45766","inReplyTo":"FDAE86E2-F607-4E82-8E0C-0E6DCEF7ED67@gmail.com","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-04-24T13:22:36Z","receivedAt":"2017-04-24T13:23:13Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Apr 21, 2017 at 9:54 PM, Lars Schneider\n<larsxschneider@gmail.com> wrote:\n>\n>> Am 20.04.2017 um 23:58 schrieb Ævar Arnfjörð Bjarmason <avarab@gmail.com>:\n>>\n>> As a refresh of everyone's memory (because mine needed it). This is a\n>> feature I added back in 2011 when the i18n support was initially\n>> added.\n>>\n>> There was concern at the time that we would inadvertently mark\n>> plumbing messages for translation, particularly something in a shared\n>> code path, and this was a way to hopefully smoke out those issues with\n>> the test suite.\n>>\n>> However compiling with it breaks a couple of dozen tests, I stopped\n>> digging when I saw some broke back in 2014.\n>>\n>> What should be done about this? I think if we're going to keep them\n>> they need to be run regularly by something like Travis (Lars CC'd),\n>> however empirical evidence suggests that not running them is just fine\n>> too, so should we just remove support for this test mode?\n>\n> Right now we are building and testing Git in the following configurations:\n>\n> 1. Linux, gcc, stable Perforce an GitLFS version (used by git-p4 tests)\n> 2. Linux, gcc, stable Perforce an GitLFS version (used by git-p4 tests) *\n> 3. OSX, clang, latest Perforce an GitLFS version (used by git-p4 tests)\n> 4. OSX, clang, latest Perforce an GitLFS version (used by git-p4 tests) *\n> 5. Linux32, gcc, no git-p4 tests\n> 6. Windows, gcc, no git-p4 tests\n>\n> 1-4 run the same tests right now. This was especially useful in the beginning to identify flaky tests (t0025 is still flaky!).\n>\n> We could easily run the tests in 1-4 with different configurations. E.g. enable GETTEXT_POISON in 2.\n\nIf CI stays idle some time, I suggest adding a test run with valgrind\non 'pu' or 'next'. If there's still spare capacity I would add another\ntest run with GIT_TEST_SPLIT_INDEX=1 (but not right now, it's broken)\n\nOff topic, is it possible to receive mail notifications from Travis\nwhen a fault is found in either 'pu', 'next' or 'master'? I know how\nto do it in Jenkins, but I'm not familiar with Travis and there's no\nobvious button from the web page..\n-- \nDuy\n"},{"id":"317717","messageId":"20170424203710.cijg3bjdrb2eywmh@sigill.intra.peff.net","threadId":"45766","inReplyTo":"CACsJy8BceB96D39gbjTFx=XQZ6ATHYYQGMRSeV=u4C3jEvTDbQ@mail.gmail.com","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-24T20:37:11Z","receivedAt":"2017-04-24T20:37:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 24, 2017 at 08:22:36PM +0700, Duy Nguyen wrote:\n\n> Off topic, is it possible to receive mail notifications from Travis\n> when a fault is found in either 'pu', 'next' or 'master'? I know how\n> to do it in Jenkins, but I'm not familiar with Travis and there's no\n> obvious button from the web page..\n\nI looked into this a bit for my personal builds. Notification config has\nto go into the .travis.yml file[1].  So I think the best we could do is\nsend a notification email to some mailing list, and then let people\nsubscribe to that (or it could go to git@vger; I don't know how noisy it\nwould be).\n\n-Peff\n\n[1] I wanted to set up an email just to me for my personal fork, but I\n    couldn't make it work. AFAICT there's no way to override upstream's\n    config short of adding another commit, which would mean I'd have to\n    base all my branches on a \"fix up .travis.yml\" commit.\n"},{"id":"317768","messageId":"xmqqmvb5w2hj.fsf@gitster.mtv.corp.google.com","threadId":"45766","inReplyTo":"CACBZZX63VQK4fLSB2T8onXJ_hQE8dkOCAyFFM-C_yOfoMwxLMA@mail.gmail.com","subject":"Re: [PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-25T04:11:20Z","receivedAt":"2017-04-25T04:11:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> My general approach when writing & maintaining this poison has been\n> that it's fine if we skip some tests, even though we could be bending\n> over backwards to run them, or even if we don't know the root cause\n> beyond \"the rebase machinery is always broken with poison\".\n>\n> This is because once I'm satisfied that the breaking test isn't\n> because of some new plumbing message that got i18n'd I don't see the\n> point of keeping digging, it's fine to just skip the test, because we\n> run it when we're not under poison, and we're satisfied that it's not\n> breaking because of a new plumbing message being i18n'd we've\n> fulfilled the entire reason for why this poison facility exists in the\n> first place.\n\nAs to skipping tests, I am worried mostly because it is very easy to\nmark one test as skipped under poison build, even where the side\neffect from that test left behind in the trash repository is a\nprerequisite for a later test to succeed.  For example, a test that\ncreates a tag may be marked as skipped-under-poison.  Then a new\ntest that is added to such a test may want to do something using\nthat tag, and it will succeed in the usual test.  As most people do\nnot test poison build, when somebody notices that the new test fails\nunder poison build, it is unclear if the breakage is due to new i18n\nissues or something else, like a missing prerequisite tag due to\nskipping an earlier test.\n\n"},{"id":"317789","messageId":"054E67A2-56B0-4C91-89F5-F33E8C00ED61@gmail.com","threadId":"45766","inReplyTo":"20170424203710.cijg3bjdrb2eywmh@sigill.intra.peff.net","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-04-25T08:51:20Z","receivedAt":"2017-04-25T08:51:29Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 24 Apr 2017, at 22:37, Jeff King <peff@peff.net> wrote:\n> \n> On Mon, Apr 24, 2017 at 08:22:36PM +0700, Duy Nguyen wrote:\n> \n>> Off topic, is it possible to receive mail notifications from Travis\n>> when a fault is found in either 'pu', 'next' or 'master'? I know how\n>> to do it in Jenkins, but I'm not familiar with Travis and there's no\n>> obvious button from the web page..\n> \n> I looked into this a bit for my personal builds. Notification config has\n> to go into the .travis.yml file[1].  So I think the best we could do is\n> send a notification email to some mailing list, and then let people\n> subscribe to that (or it could go to git@vger; I don't know how noisy it\n> would be).\n\nA separate mailing list sounds like a very good idea to me!\nMaybe \"git-builds@vger.kernel.org\" or something?\nWhat would it take to set something up like this?\n\n- Lars\n"},{"id":"317790","messageId":"CACBZZX494g8CKoN0V1N4xRuDsErPtJcMjaZcLFAqJgDQ+Mz+yA@mail.gmail.com","threadId":"45766","inReplyTo":"xmqqmvb5w2hj.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-25T08:56:43Z","receivedAt":"2017-04-25T08:57:13Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Apr 25, 2017 at 6:11 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> My general approach when writing & maintaining this poison has been\n>> that it's fine if we skip some tests, even though we could be bending\n>> over backwards to run them, or even if we don't know the root cause\n>> beyond \"the rebase machinery is always broken with poison\".\n>>\n>> This is because once I'm satisfied that the breaking test isn't\n>> because of some new plumbing message that got i18n'd I don't see the\n>> point of keeping digging, it's fine to just skip the test, because we\n>> run it when we're not under poison, and we're satisfied that it's not\n>> breaking because of a new plumbing message being i18n'd we've\n>> fulfilled the entire reason for why this poison facility exists in the\n>> first place.\n>\n> As to skipping tests, I am worried mostly because it is very easy to\n> mark one test as skipped under poison build, even where the side\n> effect from that test left behind in the trash repository is a\n> prerequisite for a later test to succeed.  For example, a test that\n> creates a tag may be marked as skipped-under-poison.  Then a new\n> test that is added to such a test may want to do something using\n> that tag, and it will succeed in the usual test.  As most people do\n> not test poison build, when somebody notices that the new test fails\n> under poison build, it is unclear if the breakage is due to new i18n\n> issues or something else, like a missing prerequisite tag due to\n> skipping an earlier test.\n\nIndeed, I've tried to be careful not to introduce bugs like that, but\nin this skipped case the tests look completely stand-alone to me.\n\nIn any case, I like my other patch to just remove this whole thing better.\n"},{"id":"317796","messageId":"20170425100155.zvfxyvd3egw463xe@sigill.intra.peff.net","threadId":"45766","inReplyTo":"054E67A2-56B0-4C91-89F5-F33E8C00ED61@gmail.com","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-25T10:01:55Z","receivedAt":"2017-04-25T10:02:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Apr 25, 2017 at 10:51:20AM +0200, Lars Schneider wrote:\n\n> >> Off topic, is it possible to receive mail notifications from Travis\n> >> when a fault is found in either 'pu', 'next' or 'master'? I know how\n> >> to do it in Jenkins, but I'm not familiar with Travis and there's no\n> >> obvious button from the web page..\n> > \n> > I looked into this a bit for my personal builds. Notification config has\n> > to go into the .travis.yml file[1].  So I think the best we could do is\n> > send a notification email to some mailing list, and then let people\n> > subscribe to that (or it could go to git@vger; I don't know how noisy it\n> > would be).\n> \n> A separate mailing list sounds like a very good idea to me!\n> Maybe \"git-builds@vger.kernel.org\" or something?\n> What would it take to set something up like this?\n\nI suspect that emailing the vger admins is the right place (or that they\ncan point us in the right direction, or tell us to get lost). The best\naddress is probably postmaster@vger.kernel.org.\n\n(I resisted just cc-ing them here to see if other people had opinions on\njust sending the output to the regular list).\n\n-Peff\n"},{"id":"317890","messageId":"xmqqmvb4szef.fsf@gitster.mtv.corp.google.com","threadId":"45766","inReplyTo":"CACBZZX494g8CKoN0V1N4xRuDsErPtJcMjaZcLFAqJgDQ+Mz+yA@mail.gmail.com","subject":"Re: [PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-26T01:58:32Z","receivedAt":"2017-04-26T01:58:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> Indeed, I've tried to be careful not to introduce bugs like that, but\n> in this skipped case the tests look completely stand-alone to me.\n\nYes, the ones I commented on in the upthread looked like their side\neffect were not felt in the later tests.\n\n> In any case, I like my other patch to just remove this whole thing better.\n\nHmph, did I miss a patch message?\n"},{"id":"317906","messageId":"CACBZZX5PgC3CjCrhhFb5d0z6-uMw2oR36-6H=78Q5eN20pKthg@mail.gmail.com","threadId":"45766","inReplyTo":"xmqqmvb4szef.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-26T07:56:15Z","receivedAt":"2017-04-26T07:57:12Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 26, 2017 at 3:58 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> Indeed, I've tried to be careful not to introduce bugs like that, but\n>> in this skipped case the tests look completely stand-alone to me.\n>\n> Yes, the ones I commented on in the upthread looked like their side\n> effect were not felt in the later tests.\n>\n>> In any case, I like my other patch to just remove this whole thing better.\n>\n> Hmph, did I miss a patch message?\n\nI sent it to you & CC'd the list, but it looks like it didn't make it\non-list. It's \"[PATCH] tests: remove the GETTEXT_POISON compile-time\noption to test i18n marking\"\n(<20170424110434.27689-1-avarab@gmail.com>). It's 240K & 6k lines, so\nperhaps the list is rejecting it, here's the patch:\n\nhttps://raw.githubusercontent.com/avar/git-patches/master/remove-gettext-poison/0001-tests-remove-the-GETTEXT_POISON-compile-time-option-.patch\n"},{"id":"317911","messageId":"4bd88c83-1892-8fc2-981f-f31cfd1b4c87@grubix.eu","threadId":"45766","inReplyTo":"20170424110434.27689-1-avarab@gmail.com","subject":"Re: [PATCH] tests: remove the GETTEXT_POISON compile-time option to test i18n marking","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-04-26T09:17:10Z","receivedAt":"2017-04-26T09:29:13Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"[Turns out I still can't operate gmail's web interface. Sorry for the dupe.]\n\n2017-04-24 13:04 GMT+02:00 Ævar Arnfjörð Bjarmason <avarab@gmail.com>:\n> Remove the GETTEXT_POISON=YesPlease compile-time which turns all of\n> git's LC_*=C output into strings like \"# GETTEXT POISON #\" instead of\n> gettext(msgid).\n>\n> See commit bb946bba76 (\"i18n: add GETTEXT_POISON to simulate\n> unfriendly translator\", 2011-02-22) for what this was originally\n> intended for.\n>\n> This facility has been broken for quite a while and has been subjected\n> to frequent bitrot. The initial idea behind it back when it was added\n> in 2011 was to prevent the accidental translation of plumbing\n> messages.\n>\n> This isn't a big concern anymore as git isn't mass-adding i18n\n> messages for a newly developed i18n facility as it was back then,\n> maintaining this facility incurs a burden, and in actuality this has\n> often been broken long enough for potential plumbing messages to be\n> translated & make their way into major releases anyway.\n>\n> Most of this patch consists of search/replacing the test suite for:\n>\n>     test_i18ngrep ! -> ! grep\n>     test_i18ngrep   -> grep\n>     test_i18ncmp    -> test_cmp\n>\n> 1. <AANLkTi=5MrU-JyeQ3UVNbVwzn-8FbstUXafgcQaLWXDB@mail.gmail.com>\n>    (https://public-inbox.org/git/AANLkTi=5MrU-JyeQ3UVNbVwzn-8FbstUXafgcQaLWXDB@mail.gmail.com/)\n>\n> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n> ---\n>\n> On Mon, Apr 24, 2017 at 3:18 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Michael J Gruber <git@grubix.eu> writes:\n>>\n>>> Ævar Arnfjörð Bjarmason venit, vidit, dixit 20.04.2017 23:58:\n>>>> As a refresh of everyone's memory (because mine needed it). This is a\n>>>> feature I added back in 2011 when the i18n support was initially\n>>>> added.\n>>>>\n>>>> There was concern at the time that we would inadvertently mark\n>>>> plumbing messages for translation, particularly something in a shared\n>>>> code path, and this was a way to hopefully smoke out those issues with\n>>>> the test suite.\n>>>>\n>>>> However compiling with it breaks a couple of dozen tests, I stopped\n>>>> digging when I saw some broke back in 2014.\n>>>>\n>>>> What should be done about this? I think if we're going to keep them\n>>>> they need to be run regularly by something like Travis (Lars CC'd),\n>>>> however empirical evidence suggests that not running them is just fine\n>>>> too, so should we just remove support for this test mode?\n>>>>\n>>>> I don't care, but I can come up with the patch either way, but would\n>>>> only be motivated to write the one-time fix for it if some CI system\n>>>> is actually running them regularly, otherwise they'll just be subject\n>>>> to bitrotting again.\n>>>\n>>> I use that switch when I change something that involves l10n, but\n>>> usually I run specific tests only. To be honest: I have to make sure not\n>>> to get confused by (nor forget one of) the build flag GETTEXT_POISON and\n>>> the environment variable GIT_GETTEXT_POISON. I'm not sure I always\n>>> tested what I meant to test...\n>>\n>> To be quite honest, I have always felt that we are just as likely\n>> inadvertently use test_i18ncmp when we should use test_cmp (and vice\n>> versa) as we would mark plumbing messages with _() by mistake with\n>> this approach, and even with constant monitoring by something like\n>> Travis, GETTEXT_POISON may be able to catch mistakes only some of\n>> the time (i.e. when we do not make mistakes in writing our tests).\n>> Without constant monitoring, I agree that the mechanism does not\n>> work well to catch our mistakes.\n>\n> Here's an alternate patch to just remove it entirely. I think we\n> should apply this instead, the only reason I sent the patch to fix it\n> up was because of Michael's comment that he was occasionally using it.\n\nYes, I think test_i18ngrep and test_i18ncmp gave the impression that\nthey are i18n-aware grep and cmp, whereas in fact they turned off\nthese tese test lines completely.\nCombined with the fact that GETTEXT_POSON builds turned on\nGIT_GETTEXT_POISON, this sounds somewhat dangerous - we test more\naspects of plumbing commands but turn off (some) tests for porcelain.\n\nI'm still wondering wether we couldn't generate a test locale\nautomatically by mangling the english strings (but preserving format\nspecifiers). That way, tests that test porcelain output could require\nLANG=C while others could run in the mangled locale. (tt_TT is taken,\nthough ;) )\n\nMichael\n"},{"id":"317932","messageId":"CACBZZX4opSbALKGQXcXsp2=698rxbx8+1GBSJ6H0TvRriaNk9A@mail.gmail.com","threadId":"45766","inReplyTo":"4bd88c83-1892-8fc2-981f-f31cfd1b4c87@grubix.eu","subject":"Re: [PATCH] tests: remove the GETTEXT_POISON compile-time option to test i18n marking","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-04-26T14:27:35Z","receivedAt":"2017-04-26T14:28:03Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 26, 2017 at 11:17 AM, Michael J Gruber <git@grubix.eu> wrote:\n> [Turns out I still can't operate gmail's web interface. Sorry for the dupe.]\n>\n> 2017-04-24 13:04 GMT+02:00 Ævar Arnfjörð Bjarmason <avarab@gmail.com>:\n>> Remove the GETTEXT_POISON=YesPlease compile-time which turns all of\n>> git's LC_*=C output into strings like \"# GETTEXT POISON #\" instead of\n>> gettext(msgid).\n>>\n>> See commit bb946bba76 (\"i18n: add GETTEXT_POISON to simulate\n>> unfriendly translator\", 2011-02-22) for what this was originally\n>> intended for.\n>>\n>> This facility has been broken for quite a while and has been subjected\n>> to frequent bitrot. The initial idea behind it back when it was added\n>> in 2011 was to prevent the accidental translation of plumbing\n>> messages.\n>>\n>> This isn't a big concern anymore as git isn't mass-adding i18n\n>> messages for a newly developed i18n facility as it was back then,\n>> maintaining this facility incurs a burden, and in actuality this has\n>> often been broken long enough for potential plumbing messages to be\n>> translated & make their way into major releases anyway.\n>>\n>> Most of this patch consists of search/replacing the test suite for:\n>>\n>>     test_i18ngrep ! -> ! grep\n>>     test_i18ngrep   -> grep\n>>     test_i18ncmp    -> test_cmp\n>>\n>> 1. <AANLkTi=5MrU-JyeQ3UVNbVwzn-8FbstUXafgcQaLWXDB@mail.gmail.com>\n>>    (https://public-inbox.org/git/AANLkTi=5MrU-JyeQ3UVNbVwzn-8FbstUXafgcQaLWXDB@mail.gmail.com/)\n>>\n>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>> ---\n>>\n>> On Mon, Apr 24, 2017 at 3:18 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>> Michael J Gruber <git@grubix.eu> writes:\n>>>\n>>>> Ævar Arnfjörð Bjarmason venit, vidit, dixit 20.04.2017 23:58:\n>>>>> As a refresh of everyone's memory (because mine needed it). This is a\n>>>>> feature I added back in 2011 when the i18n support was initially\n>>>>> added.\n>>>>>\n>>>>> There was concern at the time that we would inadvertently mark\n>>>>> plumbing messages for translation, particularly something in a shared\n>>>>> code path, and this was a way to hopefully smoke out those issues with\n>>>>> the test suite.\n>>>>>\n>>>>> However compiling with it breaks a couple of dozen tests, I stopped\n>>>>> digging when I saw some broke back in 2014.\n>>>>>\n>>>>> What should be done about this? I think if we're going to keep them\n>>>>> they need to be run regularly by something like Travis (Lars CC'd),\n>>>>> however empirical evidence suggests that not running them is just fine\n>>>>> too, so should we just remove support for this test mode?\n>>>>>\n>>>>> I don't care, but I can come up with the patch either way, but would\n>>>>> only be motivated to write the one-time fix for it if some CI system\n>>>>> is actually running them regularly, otherwise they'll just be subject\n>>>>> to bitrotting again.\n>>>>\n>>>> I use that switch when I change something that involves l10n, but\n>>>> usually I run specific tests only. To be honest: I have to make sure not\n>>>> to get confused by (nor forget one of) the build flag GETTEXT_POISON and\n>>>> the environment variable GIT_GETTEXT_POISON. I'm not sure I always\n>>>> tested what I meant to test...\n>>>\n>>> To be quite honest, I have always felt that we are just as likely\n>>> inadvertently use test_i18ncmp when we should use test_cmp (and vice\n>>> versa) as we would mark plumbing messages with _() by mistake with\n>>> this approach, and even with constant monitoring by something like\n>>> Travis, GETTEXT_POISON may be able to catch mistakes only some of\n>>> the time (i.e. when we do not make mistakes in writing our tests).\n>>> Without constant monitoring, I agree that the mechanism does not\n>>> work well to catch our mistakes.\n>>\n>> Here's an alternate patch to just remove it entirely. I think we\n>> should apply this instead, the only reason I sent the patch to fix it\n>> up was because of Michael's comment that he was occasionally using it.\n>\n> Yes, I think test_i18ngrep and test_i18ncmp gave the impression that\n> they are i18n-aware grep and cmp, whereas in fact they turned off\n> these tese test lines completely.\n> Combined with the fact that GETTEXT_POSON builds turned on\n> GIT_GETTEXT_POISON, this sounds somewhat dangerous - we test more\n> aspects of plumbing commands but turn off (some) tests for porcelain.\n\nIt gives us no less test coverage because we still run the tests\nwithout GETTEXT_POSON. Thus running first without that & then with\ngives 100% coverage.\n\nThe entire point of the GETTEXT_POSON mode is that we've already\nmanually gone over things that broke in the past, and are skipping\nthem with C_LOCALE_OUTPUT or one of these i18n functions, and when\nadding new translations we keep an eye out for new breakages that\nhaven't been marked yet.\n\nThese are then a candidate either for marking to skip, if they're\nporcelain commands using our new gettext()-utilizing code, or we've\nmade a mistake and translated some plumbing, in which case that would\nhopefully be caught by list review or Travis.\n\nI still think it's better to just get rid of it, but this aspect of it\nis working exactly as intended.\n\n> I'm still wondering wether we couldn't generate a test locale\n> automatically by mangling the english strings (but preserving format\n> specifiers). That way, tests that test porcelain output could require\n> LANG=C while others could run in the mangled locale. (tt_TT is taken,\n> though ;) )\n\nIf we wanted to keep GETTEXT_POSON this would be going further in the\nwrong direction. The reason the message starts with a \"#\", has no\ntrailing \\n & most importantly ignores any format specifiers the real\ntranslation would have is exactly because we'd like as many things as\ncan break break under this mode.\n\nIf anything we should consider changing \"# GETTEXT_POISON #\" to\n\"<random binary garbage>\" if we keep it.\n\nIncluding format specifiers would just reduce the set of things that\nwould break, consider e.g. a test that merely greps for some substring\nthat would be emitted by a \"%s branch %d commits ahead\" format, now we\nchange that to \"%s GIBBER %d ISH\", but the test still passes because\nit just does $(awk '{print $1}'), but it might be a plumbing message\nthat could be translated as e.g. \"%d WORD1 %s WORD2 WORD3\", breaking\nthe API.\n"},{"id":"318128","messageId":"73F100B8-776A-4FF8-B23B-8DF413AB3288@gmail.com","threadId":"45766","inReplyTo":"20170425100155.zvfxyvd3egw463xe@sigill.intra.peff.net","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-04-28T08:42:10Z","receivedAt":"2017-04-28T08:42:28Z","isPatch":false,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 25 Apr 2017, at 12:01, Jeff King <peff@peff.net> wrote:\n> \n> On Tue, Apr 25, 2017 at 10:51:20AM +0200, Lars Schneider wrote:\n> \n>>>> Off topic, is it possible to receive mail notifications from Travis\n>>>> when a fault is found in either 'pu', 'next' or 'master'? I know how\n>>>> to do it in Jenkins, but I'm not familiar with Travis and there's no\n>>>> obvious button from the web page..\n>>> \n>>> I looked into this a bit for my personal builds. Notification config has\n>>> to go into the .travis.yml file[1].  So I think the best we could do is\n>>> send a notification email to some mailing list, and then let people\n>>> subscribe to that (or it could go to git@vger; I don't know how noisy it\n>>> would be).\n>> \n>> A separate mailing list sounds like a very good idea to me!\n>> Maybe \"git-builds@vger.kernel.org\" or something?\n>> What would it take to set something up like this?\n> \n> I suspect that emailing the vger admins is the right place (or that they\n> can point us in the right direction, or tell us to get lost). The best\n> address is probably postmaster@vger.kernel.org.\n> \n> (I resisted just cc-ing them here to see if other people had opinions on\n> just sending the output to the regular list).\n\nOK, I'll send them an email. I just realized a strong reason for a\nseparate mailing list: I haven't found a knob to make TravisCI\nsend plain text emails.\n\n- Lars\n"},{"id":"318129","messageId":"20170428084418.kfovri32rpy3wet2@sigill.intra.peff.net","threadId":"45766","inReplyTo":"73F100B8-776A-4FF8-B23B-8DF413AB3288@gmail.com","subject":"Re: [BUG] test suite broken with GETTEXT_POISON=YesPlease","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-04-28T08:44:19Z","receivedAt":"2017-04-28T08:44:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Apr 28, 2017 at 10:42:10AM +0200, Lars Schneider wrote:\n\n> >> A separate mailing list sounds like a very good idea to me!\n> >> Maybe \"git-builds@vger.kernel.org\" or something?\n> >> What would it take to set something up like this?\n> > \n> > I suspect that emailing the vger admins is the right place (or that they\n> > can point us in the right direction, or tell us to get lost). The best\n> > address is probably postmaster@vger.kernel.org.\n> > \n> > (I resisted just cc-ing them here to see if other people had opinions on\n> > just sending the output to the regular list).\n> \n> OK, I'll send them an email. I just realized a strong reason for a\n> separate mailing list: I haven't found a knob to make TravisCI\n> send plain text emails.\n\nI think that's going to be a problem for any list on vger. I suspect the\nspam filtering all happens at an early stage.\n\nYou might consider just setting up a google group or some other list as\nan initial experiment. It wouldn't be that hard to switch the list\nlater (people will need to resubscribe, but you can notify them by\nsending an email to...the list).\n\n-Peff\n"}]}