[Python-Dev] API and process questions (sparked by Claudiu Popa on 16104

[Ezio Melotti]

On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett <jimjjewett at gmail.com> wrote:
> (1)  Should fixes to a docstring go in with a patch, even if they
> aren't related to the changing functionality?
>
> [...]
>
> It is best if a commit changes one small thing at a time.
> On the other hand, Nick recently posted that the minimal overhead of a
> patch commit is about half an hour.
>

It could be much less.  As an example,
http://bugs.python.org/issue19943 has been closed 9 minutes after the
report, it didn't have a patch and the fix had to be
applied/grafted/merged on 3 branches.  The time passed between the
first commit and the push is less than a minute too.  Clearly the time
increases if you have to run the test suite or if there is a merge
conflict/push race, and further decreases if there is a simple
typo-fix on default only and a patch already available.

> Is that overhead enough to override the one-issue-per-patch guideline?
>

That said, if the main fix should go only on default and it has a
smaller unrelated fix that should also go on default only, then doing
it together is generally OK (for some value of "unrelated" -- the fix
should still be small and near the code you touched for the main fix).
 If the unrelated fix needs to be ported on all the branches (or in
general in branches where the main fix shouldn't go), it's better to
have two separate patches.  If you commit the smaller fix together
with the bigger one, and then decide to backport it, you will have to
do a null merge and it gets slightly more complicated.


Best Regards,
Ezio Melotti