Re: [PATCH] tests: fix tests broken under GETTEXT_POISON=YesPlease

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

 



On Tue, Apr 25, 2017 at 6:11 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> My general approach when writing & maintaining this poison has been
>> that it's fine if we skip some tests, even though we could be bending
>> over backwards to run them, or even if we don't know the root cause
>> beyond "the rebase machinery is always broken with poison".
>>
>> This is because once I'm satisfied that the breaking test isn't
>> because of some new plumbing message that got i18n'd I don't see the
>> point of keeping digging, it's fine to just skip the test, because we
>> run it when we're not under poison, and we're satisfied that it's not
>> breaking because of a new plumbing message being i18n'd we've
>> fulfilled the entire reason for why this poison facility exists in the
>> first place.
>
> As to skipping tests, I am worried mostly because it is very easy to
> mark one test as skipped under poison build, even where the side
> effect from that test left behind in the trash repository is a
> prerequisite for a later test to succeed.  For example, a test that
> creates a tag may be marked as skipped-under-poison.  Then a new
> test that is added to such a test may want to do something using
> that tag, and it will succeed in the usual test.  As most people do
> not test poison build, when somebody notices that the new test fails
> under poison build, it is unclear if the breakage is due to new i18n
> issues or something else, like a missing prerequisite tag due to
> skipping an earlier test.

Indeed, I've tried to be careful not to introduce bugs like that, but
in this skipped case the tests look completely stand-alone to me.

In any case, I like my other patch to just remove this whole thing better.




[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]