On Sun, 16 Jun 2024 at 23:04, Robert Haas <robertmh...@gmail.com> wrote: > > On Sat, Jun 15, 2024 at 6:00 PM Melanie Plageman > <melanieplage...@gmail.com> wrote: > > Writing a new test framework in a popular language that makes it more > > likely that more people will write more tests and test infrastructure > > is such a completely different thing than suggesting we rewrite > > Postgres in Rust that I feel that this comparison is unfair and, > > frankly, a distraction from the discussion at hand. > > I don't really agree with this. > <snip> > it's not *as* problematic if some tests are > written in one language and others in another as it would be if > different parts of the backend used different languages, and it > wouldn't be *as* hard if at some point we decided we wanted to convert > all remaining code to the new language.
Honestly, it sounds like you actually do agree with each other. It seems you interpreted Melanie her use of "thing" as "people wanting to use Rust/Python in the Postgres codebase" while I believe she probably meant "all the problems and effort involved in the task making that possible''. And afaict from your response, you definitely agree that making it possible to use Rust in our main codebase is a lot more difficult than for Python for our testing code. > But, would I feel respected and valued as a participant in > that project? Would I have to use weird tools and follow arcane and > frustrating processes? If I did, *that* would make me give up. I don't > want to say that the choice of programming language doesn't matter at > all, but it seems to me that it might matter more because it's a > symptom of being unwilling to modernize things rather than for its own > sake. I can personally definitely relate to this (although I wouldn't frame it as strongly as you did). Postgres development definitely requires weird tools and arcane processes (imho) when compared to most other open source projects. The elephant in the room is of course the mailing list development flow. But we have some good reasons for using that[^1]. But most people have some limit on the amount of weirdness they are willing to accept when wanting to contribute, and the mailing list pushes us quite close to that limit for a bunch of people already. Any additional weird tools/arcane processes might push some people over that limit. We've definitely made big improvements in modernizing our development workflow over the last few years though: We now have CI (cfbot), a modern build system (meson), and working autoformatting (requiring pgindent on commit). These improvements have been very noticeable to me, and I think we should continue such efforts. I think allowing people to write tests in Python is one of the easier improvements that we can make. [^1]: Although I think those reasons apply much less to the documentation, maybe we could allow github contributions for just those.
