PgCon 2014 Developer Meeting
From PostgreSQL wiki
A meeting of the most active PostgreSQL developers is being planned for Wednesday 21st May, 2014 near the University of Ottawa, prior to pgCon 2014. In order to keep the numbers manageable, this meeting is by invitation only. Unfortunately it is quite possible that we've overlooked important code developers during the planning of the event - if you feel you fall into this category and would like to attend, please contact Dave Page (firstname.lastname@example.org).
Please note that this year the attendee numbers have been kept low in order to keep the meeting more productive. Invitations have been sent only to developers that have been highly active on the database server over the 9.4 release cycle. We have not invited any contributors based on their contributions to related projects, or seniority in regional user groups or sponsoring companies, unlike in previous years.
This is a PostgreSQL Community event. Room and refreshments/food sponsored by EnterpriseDB.
Time & Location
The meeting will be from 9:00AM to 5PM, and will be in the "Red Experience" room at:
Novotel Ottawa 33 Nicholas Street Ottawa Ontario K1N 9M7
Food and drink will be provided throughout the day, including breakfast from 8:30AM.
The following people have RSVPed to the meeting (in alphabetical order, by surname):
- Oleg Bartunov
- Josh Berkus
- Jeff Davis
- Andrew Dunstan
- Andres Freund
- Stephen Frost
- Peter Geoghegan
- Kevin Grittner
- Robert Haas
- Magnus Hagander
- Alvaro Herrera
- Alexander Korotkov
- Amit Kapila
- Noah Misch
- Dave Page
- Simon Riggs
Unable to attend
- Craig Ringer; regretfully declined due to date conflict with pressing personal commitments.
Proposed Agenda Items
Please list proposed agenda items here:
- External feature review (Simon)
- Commitfest and reviewing tools (Simon)
- 9.5 Commitfest schedule
- Can we officially sanction a "pull request" model for patch review (pull request is really a misnomer for what I have in mind)? (Peter Geoghegan)
There is something to be said for the LKML model, and I believe we should adopt some aspects of that model. Note that I am not proposing that we adopt merge commits, nor that we fundamentally alter our workflow in any other way; I am proposing an approved workflow that some contributors can opt for as an alternative to patch files where that makes sense.
Contributors are disinclined to submit code using a workflow that is not officially approved of. I would like to have a process formalized and approved outlining how large patches may be developed in a feature branch of a remote under the control of the author. We can version revisions of the patches using commit hash references, preserving most of the advantages of patch files (perhaps snapshotting with the CF app, so there is a patch file for each version in the archives). With large, complex patches, preserving the history of a patch as it is worked on, and the author's commit message commentary seems quite valuable. Hopefully we can come up with something that weighs everyone's concerns here.