How to sponsor a feature

From PostgreSQL wiki

(Difference between revisions)
Jump to: navigation, search
 
Line 21: Line 21:
 
* Send the specification back to pgsql-hackers and make sure you get affirmative agreement before proceeding further.
 
* Send the specification back to pgsql-hackers and make sure you get affirmative agreement before proceeding further.
  
=== Create Patches ===
+
=== Submitting 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 ===
+
  
 +
* Review [[Submitting a Patch]] prior to submitting your patch.
 +
* During development, make sure you send patches early and often.  Giant patch dumps are a great way to get your patch rejected and/or ignored.
 
* 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.
 
* 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.
  
 
[[Category:Community]]
 
[[Category:Community]]

Latest revision as of 16:40, 25 February 2013

Contents

[edit] How to sponsor a feature

[edit] 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.

[edit] Create A Specification

You can:

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

[edit] Gather Consensus on the Specification

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

[edit] Submitting Patches

  • Review Submitting a Patch prior to submitting your patch.
  • During development, make sure you send patches early and often. Giant patch dumps are a great way to get your patch rejected and/or ignored.
  • 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