Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 1:08 PM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> I think 1 & 3 could be addressed by more easily giving commit/merge
> access to these tools than to the main PG repo. And I think 2 could be
> addressed by writing on the relevant wiki page where to go, and
> probably putting a link to the wiki page on the actual website of the
> tool.

+1.

> But Perl is at the next level of unmaintained infrastructure. It is
> actually clear how you can contribute to it, but still no new
> community members actually want to contribute to it. Also, it's not
> only unmaintained by us but it's also pretty much unmaintained by the
> upstream community.

I feel like I already agreed to this in a previous email and you're
continuing to argue with me as if I were disagreeing.

> As you said, no one in our community wants to maintain our testsuite
> full time. But our test suite consists partially of upstream
> dependencies and partially of our own code. Right now pretty much
> no-one improves the ustream code, and pretty much no-one improves our
> own code. Using a more modern language gives up much more frequent
> upstream improvements for free, and it will allow new community
> members to contribute to our own test suite.

I also agree with this. I'm just not super optimistic about how much
of that will actually happen. And I'd like to hear you acknowledge
that concern and think about whether it can be addressed in some way,
instead of just repeating that we should do it anyway. Because I agree
we probably should do it anyway, but that doesn't mean I wouldn't like
to see the downsides mitigated as much as we can. In particular, if
the proposal is exactly "let's add the smallest possible patch that
enables people to write tests in Python and then add a few new tests
in Python while leaving almost everything else in Perl, with no
migration plan and no clear vision of how the Python support ever gets
any better than the minimum stub that is proposed for initial commit,"
then I don't know that I can vote for that plan. Honestly, that sounds
like very little work for the person proposing that minimal patch and
a whole lot of work for the rest of the community later on, and the
evidence is not in favor of volunteers showing up to take care of that
work. The plan should be more front-loaded than that: enough initial
development should get done by the people making the proposal that if
the work stops after, we don't have another big mess on our hands.

Or so I think, anyway.

--
Robert Haas
EDB: http://www.enterprisedb.com