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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2012/3/7 Junio C Hamano <gitster@xxxxxxxxx>:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> On Wed, Mar 7, 2012 at 22:34, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>>>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]