Criteria for evaluating proposed changes

Last modified: October 23, 2009 - 06:23

The following criteria are used by core developers in reviewing and approving
proposed changes:

  • The changes support and enhance Drupal project aims.
  • The proposed changes are current. New features should be filed against the most recent development version. Currently, only Drupal 8 is open for new features, with some exceptions. In keeping with Drupal's approach to backwards compatibility, new features are not candidates for backporting to stable releases.
    Bug fixes are applied to newer versions first, and then may be backported to currently supported releases.
    When submitting patches, it's best to write your patch for the appropriate CVS branch. There may have been significant changes since the last release, so developing for the CVS version means that your patch will be easiest to apply and merge in, and thus more likely to be used.
  • The proposed change doesn't raise any significant issues or risks. Specifically, issues that have been raised in the review process have been satisfactorily addressed.
  • The changes are well coded. At a minimum, this means coding in accordance with the Drupal coding standards. But it also means that the coding is intelligent and compact. Elegant solutions will have greater support than cumbersome ones that accomplish the same result.
  • There is demonstrated demand and support for the change. Demand is indicated by, e.g., comments on the drupal.org issues system or comments in forums or the drupal-dev email list.
  • The change will be used by a significant portion of the installed Drupal base as opposed being relevant only to a small subset of Drupal users.
  • The benefits of the change justifies additional code and resource demands. Every addition to the code base increases the quantity of code that must be actively maintained (e.g., updated to reflect new design changes or documentation approaches). Also, added code increases the overall Drupal footprint through, e.g., added procedure calls or database queries. Benefits of a change must outweigh these costs.

Performance and Security?

donquixote - October 26, 2009 - 17:33

The proposed changes are current. New features should be filed against the most recent development version. Currently, only Drupal 8 is open for new features, with some exceptions. In keeping with Drupal's approach to backwards compatibility, new features are not candidates for backporting to stable releases.

Bug fixes are applied to newer versions first, and then may be backported to currently supported releases.

In which cases do performance- or security-related issues count as bugs, and deserve a backport?

 
 

Drupal is a registered trademark of Dries Buytaert.