Re: pgsql: Require version 0.98 of Test::More for TAP tests - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Require version 0.98 of Test::More for TAP tests
Date
Msg-id 3389295.1637459712@sss.pgh.pa.us
Whole thread Raw
In response to pgsql: Require version 0.98 of Test::More for TAP tests  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-committers
Noah Misch <noah@leadboat.com> writes:
> On Sat, Nov 20, 2021 at 08:22:14PM -0500, Tom Lane wrote:
>> I think we need a back-patch of *something*.  It's pure luck that wrasse
>> hasn't shown problems already.  I don't want to be rediscovering this
>> issue a year from now when somebody back-patches some test requiring
>> subtests.

> If you want to allow subtests in all branches, $SUBJECT is the thing needing a
> back-patch.

Agreed, but I think we're going to want to do that as soon as the dust
has settled.  We have plenty of precedent for back-patching test
infrastructure, and I don't see why this wouldn't qualify.

> By default, they remain banned in back-patches.

They're banned only in the sense that one or two old, slow buildfarm
animals will fail on them; the odds that anyone would notice the problem
before a patch reaches the buildfarm seem poor.  I'd just as soon not
set that trap for ourselves.  It's not like we expect testing with
obsolete Perl modules to be much of a concern in non-buildfarm usage,
even for consumers of back branches.

I also note that prairiedog will soon not be in the camp that fails,
even for back branches.  Neither will wrasse unless you invent some
truly strange configuration trick for it.  So the argument that there's
a back-branch ban on subtests doesn't seem like it will have much
enforcement behind it.

            regards, tom lane



pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Require version 0.98 of Test::More for TAP tests
Next
From: Andrew Dunstan
Date:
Subject: Re: pgsql: Require version 0.98 of Test::More for TAP tests