On 28 Apr 2014 16:19, "Ezio Melotti" <ezio.melo...@gmail.com> wrote: > > On Mon, Apr 28, 2014 at 6:32 PM, Jim J. Jewett <jimjjew...@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.
The 30 minute guesstimate was for doing it right for a patch you didn't write yourself: - final recheck that all the required pieces are there - patch import & merge commands - run the tests for every affected branch - coming up with the NEWS entry & commit message 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. > > 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. What Ezio said :) I definitely do coarser commits for CPython than I do for beaker-project.org, 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. Cheers, Nick. > > > Best Regards, > Ezio Melotti > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com