new review1. review patches faster2. review patches sooner3. review every patch4. train new reviewers
8.5 (9.0) RC and Branch July 1 2009 Development Period CommitFest 1 July 15 2009 Development Period August 15 2009 CommitFest 2 September 15 2009 Development Period October 15 2009 CommitFest 3 November 15 2009 Development Period December 15 2009 CommitFest 4 January 15 2010Cleanup February 15 2010 Integration & Review (2-4 weeks)Beta Beta Testing (2-3 months)9.1 RC and Branch June-July, 2010
Many Patches == Lots of Testing● Bug Testing – can you make 9.0 crash?● Specif cation Testing i – do the features do what the docs say they do?● Performance Testing – is 9.0 really faster? How much?● Combinational Testing – what happens when you put several new features together?
Many Patches == Lots of Testing1. Take a copy of your production applications2. Port them to 9.03. Report breakage and issues4. Play with implementing new features Do It Now! Were counting on you!
Why contribute?● PostgreSQL is a community project – owned by the community, run by the community – if you contribute, you are a full participant● Tinker with cool database stuff – we are hard-core database geeks – learn a lot from top database hackers● Improve your employment prospects – database engineers are always in demand
Mailing Lists● Hackers list – pgsql-hackers – main list for development discussion – submit patches here until we move off CVS● Testers list – pgsql-testers – submit test reports here● Specif c feature lists i – pgsql-jdbc, pgsql-performance, pgsql-sql, etc. – subscribe at www.postgresql.org/community/lists
Web Sites● www.postgresql.org – main site● git.pgfoundry.org – branches, feature forks, snapshots● wiki.postgresql.org – community wiki, including TODO lists – feature specs & testing info● archives.postgresql.org – mailing list archives -- search for your idea here
Tips on submitting code● Dont get discouraged. – Be prepared to argue. – One hacker rejecting your idea doesnt mean everyone does. – Committers (esp. Tom Lane) are often more concerned about maintainability than cool stuff.● Be f exible: you will have to make changes. l – Corporate and academic coding standards are generally lower than the projects.
Other tips on submitting● Dont use the wrong arguments – “MySQL/Oracle does it this way.” – “Based on this hot academic trend.”● Some things make a patch harder to accept – New syntax – Backwards compatibility issues – High code counts● Dont get discouraged.
Also: switching to git● 9.0 was developed with both CVS and git● Probably just git in the future
Contact Information● Josh Berkus ● Upcoming Events: – firstname.lastname@example.org – PG East: March, – blogs.ittoolbox.com/ Philadelphia database/soup – pgCon: May 19, – www.pgexperts.com Ottawa Canada CfP Open!● User Groups – OSCON: July, – pugs.postgresql.org Portland OR – Wellington CfP Open! – Sydney – Adelaide – Canberra This talk is copyright 2010 Josh Berkus, and is licensed under the creative commons attribution license