3 ms·

This is mentioned in the article, but one thing I'd call out that can't be understated is reviewing patches and testing. This has been for years and continues t

This is mentioned in the article, but one thing I'd call out that can't be understated is reviewing patches and testing. This has been for years and continues to be an area that more help is always very welcome. It's a great way to get your feet wet, and try to chip in to the overall quality of Postgres. Even now looking at the commitfest app[1] there is quite a few patches that anyone could jump in and try to help review. [1] https://commitfest.postgresql.org/33/ https://commitfest.postgresql.org/33/

mjw1007 5y ago
I think it's difficult to do review work as an 'outsider'. You might be able to report an outright bug if you find one, and you can report "this old patch still applies and passes its tests", but other than that it seems difficult for the project to make use of what you say. If you say "I read this patch and everything looks great, I'd love to see this in the next release", how much weight can the project put on that? How do they know whether you would have found problems if they were there? Or if you read the patch and conclude "I can't find any actual bugs, but I'm pretty sure most of that code is going about things the wrong way, and I don't think this is going to get past a committer as it stands", how can you write that up in a way that's actually helpful? (The last is where I ended up the one time I decided to have a go at reviewing a PostgreSQL patch. So I just said nothing and waited for an experienced reviewer to tell the author to rewrite it, which happened a month or three later.)