+39 0574 159 3000
Help us make a better PostgreSQL 9.3!
As interest in PostgreSQL grows, so does the rate at which new patches are proposed. To maintain the high level of quality in PostgreSQL it is important that all patches be checked and reviewed, so that what gets added to the codebase is good quality.
Some of this evaluation requires a lot of expertise in the PostgreSQL core code, but most of it requires little development experience at all. The more initial checking and review gets done before patches get evaluated by the experts, the less work those experts have to do. So: please step up and review a patch. There are patch review guidelines on the wiki, and it’s quite an accessible process. Step right up if you want to contribute a little back to the software you use and rely on, or if there’s a particular enhancement you want to make sure goes into 9.3.
If you don’t feel up to reviewing the feature you’re interested in, you can still help by testing and initially reviewing something else, so others have more time to examine the complicated stuff. You can still help out.
I’ll be posting a series on patches proposed for 9.3, starting with today’s patch, Peter Eisentraut’s addition of a ALTER ROLE extension to change PostgreSQL settings (like work_mem, search_path, etc) for all users on all databases. The initial post explaining the patch is here and this is the commitfest entry.
To get involved, visit the current commitfest page, sign in with your PostgreSQL community login, and have a look at the list of patches needing review. If there’s one there that doesn’t have an existing reviewer listed, or that interests you, please get involved! Grab the patch, read the reviewer guidelines, and help make PostgreSQL better.
I guess the “patch review guidelines on the wiki” link should point to https://wiki.postgresql.org/wiki/Reviewing_a_Patch ?
Thankyou; corrected. “” isn’t a particularly useful link…
Thankyou for reviewing this post 😉
Thanks for that, I’ve been looking for things to do but haven’t been sure where to start.
Has the group ever considered making use of something like this http://www.reviewboard.org/ to possibly help stream line the code review process?
A few of us in the PostgreSQL community have looked at software like Review Board before. A related regular discussion point is using formal bug tracking software.
The PostgreSQL developers are very oriented around using e-mail and traditional code editors for their work. Many of the people doing review start by reading the patch in their editor of choice, customized the way they want. The small CommitFest app works in terms of the message ids used for discussion. It’s not clear that Review Board helps out the people doing the majority of the work enough to justify using it yet. It would need to patched to have a similar level of integration with the PostgreSQL archives to make a lot of people happy. Certainly possible and maybe useful, but it’s not seen as a highly valuable project to most reviewers.
Is there a dead-simple tutorial on how to build postgresql for a commitfest and to apply a patch to make sure the patch 1. builds, 2. behaves as intended. (I saw this as the easiest and lowest hanging fruits people can do to help out the project (for non programmers))?
eg) building postgresql so that it does not affect your primary installation etc..
The patch review guidelines on the wiki are the main resource right now, but you’re right that it’d be good to have something explaining how to build and run a test copy of Pg that doesn’t tread on the toes of anything already running. Added to my blog queue.
I hope this post – and the comments – help: https://blog.2ndquadrant.com/help-us-make-a-better-postgresql-9-3/