Patch size and complexity thresholds should be discussed, decided, and documented.

Problem/Motivation

Drupal has become sufficiently large, complex, and multiply-interconnected that large changes, even if trivial, can carry a high cost in time when conflicting patches have to be re-rolled and re-tested.

Proposed resolution

On August 4, 2011 at 9:43am, Dries set a precedent by posting:

I've looked at this and I'm comfortable with the patch. Given that it may break a lot of patches, I'd like to propose that I commit this on November 1st, 2011.

Other senior developers, committers, and approvers have followed this example by delaying or pre-scheduling large patches that would make many patches need rerolls.

In order to promote harmony and reduce conflict, this policy should be discussed and standardized.

Remaining tasks

• Publish guidelines to help decide whether a patch is big or invasive enough to warrant a pre-announced and pre-scheduled commit. Is it possible for PIFR/PIFT to report the total number of RTBC patches which overlap or conflict with the patch being tested?
• Provide a standard workflow for coordinating, announcing, and committing such patches. For example, It should be possible for developers to check whether their patch is likely to conflict with a pre-approved patch that is waiting on a scheduled commit.
• Link to this documentation from strategic places. For example, if it is possible to programmatically determine whether a patch is large enough to be considered for a pre-scheduled commit, the relevant documentation should be linked from the test results comment in the issue queue.

User interface changes

None.

API changes

None.