On Wed, Apr 22, 2020 at 2:02 PM Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>
> Johan Corveleyn wrote on Wed, 22 Apr 2020 13:30 +0200:
> > I don't know the exact rules, but does backporting testsuite fixes cause a
> > restart of the soak? If we can backport those and include them into the
> > final 1.14.0 without restarting the soak, that would be ideal. Otherwise ...
>
> In general, I think test suite infrastructure changes would qualify as
> restarting the soak, since they could conceivably break «make check»
> for someone out there.
>
> In this instance, however, the purpose of the fixes is to _unbreak_
> «make check» for someone in here. It's appealing to say that fixing
> a known problem should have priority over the risk of _potentially_
> introducing a new problem, but on the other hand, the arguments for not
> shortening the soak serve equally well as arguments for not making
> exceptions to it.
>
> How about a compromise: keep the test suite changes out of 1.14.0
> (unless the soak is restarted), but schedule a 1.14.1 to, say, late
> June to release them in?
Yes, I think that's fine too, and it doesn't get us on the slippery
slope of soak-restarting. And indeed, like you suggest, theoretically
it might break "make check" for some, so it would actually force y'all
that have already signed the RC to rerun your complete testsuite (and
not do the quick validation of "GA is the same as the RC which I've
already tested").
In fact, there is very little pressure on getting this in 1.14.0 GA,
because (1) it only affects testsuite-runners on Windows, of which
there are extremely few :-), and (2) the workaround is simple (just
use Py 2.7 for running the testsuite on Windows). Not worth taking
risks for IMHO.
The only actual "damage" is perhaps marketing. Now we can't claim
"Full Py3 support" in big letters, we need to add a footnote pointing
to a known issues section in the release notes or something ...
--
Johan
Received on 2020-04-22 14:15:23 CEST