From 9972ccec3fea7be58b4d72c0aedd306cdb2d312a Mon Sep 17 00:00:00 2001 From: Kevin Benton Date: Tue, 29 Sep 2015 09:27:33 -0700 Subject: [PATCH] Add a patch scope section to 'effective neutron' Change-Id: I99d82d25d72689b8e1212267ae346e87862a9006 --- doc/source/devref/effective_neutron.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/source/devref/effective_neutron.rst b/doc/source/devref/effective_neutron.rst index 98bf8e9fb..cd44a35a2 100644 --- a/doc/source/devref/effective_neutron.rst +++ b/doc/source/devref/effective_neutron.rst @@ -133,6 +133,20 @@ Document common pitfalls as well as good practices done when writing docstrings. Landing patches more rapidly ---------------------------- +Scoping your patch appropriately +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* Do not make multiple changes in one patch unless absolutely necessary. + Cleaning up nearby functions or fixing a small bug you noticed while working + on something else makes the patch very difficult to review. It also makes + cherry-picking and reverting very difficult. +* If a fix or feature requires code refactoring, submit the refactoring as a + separate patch than the one that changes the logic. Otherwise + it's difficult for a reviewer to tell the difference between mistakes + in the refactor and changes required for the fix/feature. If it's a bug fix, + try to implement the fix before the refactor to avoid making cherry-picks to + stable branches difficult. + Nits and pedantic comments ~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 2.45.2