Re: RFC: adding pytest as a supported test framework - Mailing list pgsql-hackers

From Robert Haas
Subject Re: RFC: adding pytest as a supported test framework
Date
Msg-id CA+TgmoZCQtUu4u7XJ1umD8k5pTuM3h2zLDyQ1uoVOP-==gJz_Q@mail.gmail.com
Whole thread Raw
In response to Re: RFC: adding pytest as a supported test framework  (Jelte Fennema-Nio <postgres@jeltef.nl>)
Responses Re: RFC: adding pytest as a supported test framework
Re: RFC: adding pytest as a supported test framework
Re: RFC: adding pytest as a supported test framework
List pgsql-hackers
On Wed, Jun 12, 2024 at 6:43 PM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> I agree it's not a technical issue. It is a people issue. There are
> very few people skilled in Perl active in the community. And most of
> those are very senior hackers that have much more important things to
> do that make our Perl testing framework significantly better. And the
> less senior people that might see improving tooling as a way to get
> help out in the community, are try to stay away from Perl with a 10
> foot pole. So the result is, nothing gets improved. Especially since
> very few people outside our community improve this tooling either.

I agree with you, but I'm skeptical that solving it will be as easy as
switching to Python. For whatever reason, it seems like every piece of
infrastructure that the PostgreSQL community has suffers from severe
neglect. Literally everything I know of either has one or maybe two
very senior hackers maintaining it, or no maintainer at all. Andrew
maintains the buildfarm and it evolves quite slowly. Andres did all
the work on meson, with some help from Peter. Thomas maintains cfbot
as a skunkworks. The Perl-based TAP test framework gets barely any
love at all. The CommitFest application is pretty much totally
stagnant, and in fact is a great example of what I'm talking about
here: I wrote an original version in Perl and somebody -- I think
Magnus -- rewrote it in a more maintainable framework -- and then the
development pace went to basically zero. All of this stuff is critical
project infrastructure and yet it feels like nobody wants to work on
it.

Now, this case may prove to be an exception to that rule and that will
be great. But what I think is a lot more likely is that we'll get a
lot of pressure to commit something as soon as parity with the Perl
TAP test system has been achieved, or maybe even before that, and then
the rate of further improvements will slow to a trickle. That's not to
say that sticking with Perl is better. A quick Google search finds a
web page that says Python is two orders of magnitude more popular than
Perl, and that's not something we should just ignore. But I still
think it's fair to question whether the preference of many developers
for Python over Perl will translate into sustained investment in
improving the infrastructure. Again, I will be thrilled if it does,
but that just doesn't seem to be the way that things go around here,
and I bet the reasons go well beyond choice of programming language.

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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Conflict Detection and Resolution
Next
From: Alvaro Herrera
Date:
Subject: Re: Keeping track of buildfarm animals' personality