How to sponsor a feature

From PostgreSQL wiki

(Difference between revisions)
Jump to: navigation, search
(+cat)
Line 23: Line 23:
 
=== Create Patches ===
 
=== Create Patches ===
  
* Patches should be in the form of context-style diffs.
+
* Patches should be in a diff format which includes context, either context or unified.  Patches in 'normal' or 'plain' format, which don't include any context, are not acceptable.
 
* They should apply cleanly to CVS TIP.
 
* They should apply cleanly to CVS TIP.
 
* Make sure you send patches early and often.  Giant patch dumps are a great way to get your patch rejected and/or ignored.
 
* Make sure you send patches early and often.  Giant patch dumps are a great way to get your patch rejected and/or ignored.

Revision as of 16:37, 25 February 2013

Contents

How to sponsor a feature

Propose the Feature

  • Write a detailed proposal. Here is a proposal template
  • Send it to the pgsql-hackers list.
  • Ask for feedback, and pay attention both to what comes back and to silence.
  • Lather, rinse, repeat.
  • Avoid sending such proposals during a CommitFest.

Create A Specification

You can:

  • Create this on your own.
  • Solicit community help.
  • Hire people to create the specification.

Gather Consensus on the Specification

  • Send the specification back to pgsql-hackers and make sure you get affirmative agreement before proceeding further.

Create Patches

  • Patches should be in a diff format which includes context, either context or unified. Patches in 'normal' or 'plain' format, which don't include any context, are not acceptable.
  • They should apply cleanly to CVS TIP.
  • Make sure you send patches early and often. Giant patch dumps are a great way to get your patch rejected and/or ignored.

Submit Patches

  • Send patches to the pgsql-hackers list along with a reminder of what has gone before. Pointers into the archives are good if some time has elapsed.
Personal tools