Re: RFC: adding pytest as a supported test framework

On Thu, Jun 13, 2024 at 3:28 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> (that's not the proposal and I know/think you know that but having my
> original email twisted into that is making me feel a bit crispy)

I definitely did not mean to imply that. I took your original email as
a goal, rather than a proposal or plan. My statement was strictly
intended as a hypothetical because I didn't think any plan had been
proposed - I only meant to say that *if* the plan were to do X, that
would be a hard sell for me.

> I do not want to migrate, and I have stated so multiple times, which
> is why I have not proposed a migration plan. Other committers have
> already expressed resistance to the idea that we would rewrite the
> Perl stuff. I think they're right. I think we should not. I think we
> should accept the cost of both Perl and something else for the
> near-to-medium future, as long as the "something else" gives us value
> offsetting the additional cost.

I agree. It's not terribly pretty, IMHO, but it's hard to see doing
things any other way.

> For me personally, the problem is the opposite. I have done _so much_
> initial development by myself that there's no way it could ever be
> reviewed and accepted. But I had to do that to get meaningful
> development done in my style of work, which is focused on security and
> testability and verifiable implementation.

I admire this attitude. I think a lot of people who go off and do a
ton of initial work outside core show up and are like "ok, now take
all of my code." As you say, that's not realistic. One caveat here,
perhaps, is that the focus of the work you've done up until now and
the things that I and other community members may want as a condition
of merging stuff may be somewhat distinct. You will have naturally
been focused on your goals rather than other people's goals, or so I
assume.

> I am trying to carve off pieces of that and say "hey, does this look
> nice to anyone else?" That will take time, probably over multiple
> different threads.

This makes sense, but I would be a bit wary of splitting it up over
too many different threads. It may well make sense to split it up, but
it will probably be easier to review if the core work to enable this
is one patch set on one thread where someone can read just that one
thread and understand the situation, rather than many threads where
you have to read them all.

> Because of how many moving parts and competing interests and personal
> disagreements there are, I am firmly in the camp of "try something
> that many people think *might* work better, that can be undone if it
> sucks, and iterate on it." I want to build community momentum, because
> I think that's a pretty effective way to change the cultural norms
> that you're saying you're frustrated with. That doesn't mean I want to
> do this without a plan; it just means that the plan can involve saying
> "this is not working and we can undo it" which makes the uncertainty
> easier to take.

As a community, we're really bad at this. Once something gets
committed, getting a consensus to revert it is really hard, especially
if a major release has happened meanwhile, but most of the time even
if it hasn't. It might be a little easier in this case, since after
all it's not a directly user-visible feature. But historically what
happens if somebody says "hey, there are six unfixed problems with
this feature!" is that everybody says "well, you're free to fix the
problems if you want, but you're not allowed to revert the feature."
And that is *exactly* how we end up with stuff like the current TAP
test framework: ripping that out would mean removing all the TAP tests
that depend on it, and that wouldn't have achieved consensus two
months after the feature went in, let alone today.

Now, it has been suggested to me by at least one other person involved
with the project that we need to be more open to the kind of thing
that you propose here: add experimental things and take them out if it
doesn't work out. I can definitely understand that this might be a
culturally better approach than what we currently do. So maybe that's
the way forward, but it is hard (at least for me) to get past the fear
of being the one left holding the bag, and I suspect that other
committers have similar fears. What exactly we should do about that,
I'm not sure.

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