From: Kevin Benton Date: Tue, 29 Sep 2015 16:27:33 +0000 (-0700) Subject: Add a patch scope section to 'effective neutron' X-Git-Url: https://review.fuel-infra.org/gitweb?a=commitdiff_plain;h=9972ccec3fea7be58b4d72c0aedd306cdb2d312a;p=openstack-build%2Fneutron-build.git Add a patch scope section to 'effective neutron' Change-Id: I99d82d25d72689b8e1212267ae346e87862a9006 --- 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~