At the PGCon 2011 PostgreSQL Developer Meeting the CommitFest
schedule for 9.2 development was set. This called for four CFs, one
month each, to start on these dates:
- June 15
- September 15
- November 15
- January 15
We're coming up on the start of the second of those in ten days. I
have volunteered to manage the CF process for this cycle.
First, anyone with work they want reviewed during this time should be
sure to submit it before September 15th. Please follow the
guidelines here:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
Note that context diff format is preferred, and that you should
attach the patch to a post to the pgsql-hackers list. Then add an
entry to the open commitfest with a reference to the message ID of
that post.
http://commitfest.postgresql.org/action/commitfest_view/open
A major goal of the CF process is to involve more people into the
review process. This is a great way to contribute to the project,
regardless of skill level -- pretty much if you are subscribed to
this list and following along, you can make a valuable contribution.
Please read this page and follow the instructions there:
http://wiki.postgresql.org/wiki/RRReviewers
I see this CF has a great many performance-related patches, so it
would be *very* helpful if people with access to hardware suitable
for running performance tests could volunteer as reviewers. You
don't need to be an expert C coder -- if you can compile from source
and run benchmarks, you are needed!
The goal is to have all patches which are submitted by the start of
the CF disposed by the end. Disposition can be "Rejected" for
features which are determined not be desirable by the community, or
for which the patch takes a basically untenable approach.
Disposition can be "Returned with Feedback" if the feature is
desirable and the patch uses a fundamentally sound approach, but it
cannot be brought to a finished state during the CF. Most patches
need one or more rounds of revision based on review, and are then
committed. To have patches committed before the end of the one-month
cycle, both reviewers and authors must be prompt in posting (normally
within four days of the patch waiting on them), so that committers
have sufficient time to do a final review and edit within the CF.
I do recognize that sometimes events conspire to delay things, or a
good set of benchmarks may require more than four days to run. In
those cases, it would be helpful to send email off-list to me so that
I don't need to spend time checking on the status. Also, if you find
yourself in "over your head" on a review or find yourself short on
time, let me know so I can find another reviewer to help or continue
the work.
Reviewers should subscribe to both the pgsql-hackers and
pgsql-rrreviewers lists. The -rrreviewers list is for discussion of
who will take which patches, and other administrative tasks.
Discussion of the patches themselves, and the features they are
intended to implement, as well as actual reviews and revisions should
all be posted to the -hackers list.
If you can help, please sign up as outlined on the Wiki page, and
either put yourself down as reviewer for a patch or email me off-list
with an outline of your skills and interests so I can pick an
unclaimed patch that seems a good fit.
-Kevin