Skip to content
This repository has been archived by the owner on Nov 13, 2023. It is now read-only.

New features

Jump to bottom
alshabib edited this page Feb 7, 2013 · 1 revision

New Feature Development

  1. Ticket is filed in Issue Tracker.
  2. Someone (any interested party) writes a feature design document and publishes it
  3. User community and core developers weigh in
  4. Document is tweaked with their feedback
  5. Someone writes an implementation and publishes a patch or repository URL (preferably with tests and documentation)
  6. Patch / Repository is maintained against the current HEAD/TIP of the active DEV branch by the original author
  7. Patch is pulled into active DEV branch by current release maintainer
  8. Maintenance is now the responsibility of the core development team (patches are of course welcome!)
  9. Eventually DEV is merged into a MAINT branch and feature makes it into stable release

Notes

  • While you may submit a patch, pull requests from your fork are generally preferred.
  • You have a better chance of getting a new feature if it is possible to disable it and take no performance hit
  • Changing fundamental behavior is hard, even if you're right - preserving old behavior as an option is often (but not always) a good goal
  • Nothing is risk-free. Trying to convince the core developers otherwise is not likely to win you any points.
  • Ultimately the person writing the design document (and then the code) is in charge - they don't have to accept user feedback they don't agree with. The core development team eventually will decide whether to pull the code into the mainline, but 100% consensus is not required for this to happen.
Clone this wiki locally