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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
