Re: [PATCH/RFC] Change t0204-gettext-reencode-sanity.sh to pass under Mac OSX

Ævar Arnfjörð Bjarmason [off-list ref] writes:

On Wed, Mar 7, 2012 at 22:34, Junio C Hamano [off-list ref] wrote:

quoted

quoted

I think it's important to be pro-active about trying to spot
any issues that might affect end users before they happen.

The goal is noble, but asking the platform to perform an impossible
task and subjectively judging if the failure mode is acceptable is
not the way to do so, I would have to say.

I leave it up to you whether you want to accept the patch to remove
it, but with it included we at least *know* what the failure modes
are, since we get user reports about it.

That's the reason I put it in there to begin with. Because I have no
idea how all these pieces play together with systems in the wild, and
I'd like to pro-actively find out about that.

Are we talking about the same specific test?

What you said above all makes sense and I agreed that it is a noble
goal, *if* and only if the test is about the case we *expect* to
work.  This particular one prepares a message that cannot possibly
be transliterated to iso-8859-1 and asks the system to show it.

What scenario do you have in mind that we (or the end user for that
matter) might benefit by having this test?  What would be the next
step for us, when this test finds yet another mode of breakage that
spews out a different kind of garbage other than runs of "?", the
key used to query the message catalog ("TEST: Old English Runes"),
or the raw value stored in the message catalog (runes in UTF-8)?

2012/3/7 Junio C Hamano [off-list ref]:

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

On Wed, Mar 7, 2012 at 22:34, Junio C Hamano [off-list ref] wrote:

quoted

quoted

I think it's important to be pro-active about trying to spot
any issues that might affect end users before they happen.

The goal is noble, but asking the platform to perform an impossible
task and subjectively judging if the failure mode is acceptable is
not the way to do so, I would have to say.

I leave it up to you whether you want to accept the patch to remove
it, but with it included we at least *know* what the failure modes
are, since we get user reports about it.

That's the reason I put it in there to begin with. Because I have no
idea how all these pieces play together with systems in the wild, and
I'd like to pro-actively find out about that.

Are we talking about the same specific test?

What you said above all makes sense and I agreed that it is a noble
goal, *if* and only if the test is about the case we *expect* to
work.  This particular one prepares a message that cannot possibly
be transliterated to iso-8859-1 and asks the system to show it.

What scenario do you have in mind that we (or the end user for that
matter) might benefit by having this test?

E.g. if we find out that their implementation of gettext panics
instead of showing question marks that means we'd have to pay special
attention to that platform.

Anyway, I admit that this is an obscure edge case. I really just like
the idea of having complete knowledge (which we'll have in time since
we get ported everywhere) about how the various aspects of our i18n
implementation work.

Having that information doesn't cost us a lot, in this case we can
just amend the test to assert that on OSX the output should be the
same as under the UTF-8 output.