<p dir="ltr"><br>
On 28 Apr 2014 16:19, "Ezio Melotti" <<a href="mailto:ezio.melotti@gmail.com">ezio.melotti@gmail.com</a>> wrote:<br>
><br>
> On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:<br>
> > (1)  Should fixes to a docstring go in with a patch, even if they<br>
> > aren't related to the changing functionality?<br>
> ><br>
> > [...]<br>
> ><br>
> > It is best if a commit changes one small thing at a time.<br>
> > On the other hand, Nick recently posted that the minimal overhead of a<br>
> > patch commit is about half an hour.<br>
> ><br>
><br>
> It could be much less.  As an example,<br>
> <a href="http://bugs.python.org/issue19943">http://bugs.python.org/issue19943</a> has been closed 9 minutes after the<br>
> report, it didn't have a patch and the fix had to be<br>
> applied/grafted/merged on 3 branches.  The time passed between the<br>
> first commit and the push is less than a minute too.  Clearly the time<br>
> increases if you have to run the test suite or if there is a merge<br>
> conflict/push race, and further decreases if there is a simple<br>
> typo-fix on default only and a patch already available.</p>
<p dir="ltr">The 30 minute guesstimate was for doing it right for a patch you didn't write yourself:<br>
- final recheck that all the required pieces are there<br>
- patch import & merge commands<br>
- run the tests for every affected branch<br>
- coming up with the NEWS entry & commit message</p>
<p dir="ltr">It's generally much, much faster for changes I write myself - another undesirable incentive since it further encourages us to work on our own changes over incorporating patches from others.</p>
<p dir="ltr">> > Is that overhead enough to override the one-issue-per-patch guideline?<br>
><br>
> That said, if the main fix should go only on default and it has a<br>
> smaller unrelated fix that should also go on default only, then doing<br>
> it together is generally OK (for some value of "unrelated" -- the fix<br>
> should still be small and near the code you touched for the main fix).<br>
>  If the unrelated fix needs to be ported on all the branches (or in<br>
> general in branches where the main fix shouldn't go), it's better to<br>
> have two separate patches.  If you commit the smaller fix together<br>
> with the bigger one, and then decide to backport it, you will have to<br>
> do a null merge and it gets slightly more complicated.</p>
<p dir="ltr">What Ezio said :)</p>
<p dir="ltr">I definitely do coarser commits for CPython than I do for <a href="http://beaker-project.org">beaker-project.org</a>, specifically because Gerrit provides decent tools for reviewing and merging a patch series, and we don't currently have anything like that in the CPython workflow.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
><br>
> Best Regards,<br>
> Ezio Melotti<br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>