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

[Nick Coghlan]

On 28 Apr 2014 16:19, "Ezio Melotti" <ezio.melotti at gmail.com> wrote:
>
> 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.

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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140429/f1be6dd9/attachment.html>