On 3/23/2014 10:04 PM, Chris Angelico wrote:
On Mon, Mar 24, 2014 at 12:26 PM, Terry Reedy <tjre...@udel.edu> wrote:
With multiple branches (as with 2.7, 3.4, and default for cpython) and
multiple active developers (20?) commiting to those brances, commits are
definitely not free. I would not exactly call them as cheap as you seem to
imply either. That said, I have occasionally pushed interim changes that put
code in an improved and stable state.
N. Coughlan has suggested improving the cpython infrastructure and
procedures to reduce the cost of commits to encourage more people to make
more commits (in the sense of more lines changed, not more pieces) and
improve cpython faster.
When I call them cheap, what I mean is that there's little difference
between a single commit and 2-3 commits as a group. Yes, there's a bit
more difference when you're cherry-picking them to other branches, and
maybe an infrastructure/procedure change could help with that; but
once they're there in history, it doesn't hurt to have three separate
commits doing related work, keeping the distinct parts distinct.
Every commit to a 3.x maintenance branch (now 3.4) must be forward
merged into the 3.(x+1) default (now the future 3.5), even if it is just
a null merge. The point of this policy is to keep the repository in a
coherent state. If a bug were fixed in maintenance but not default, it
would create a regression situation, the same as if it were fixed in
default and then broken again by a separate patch.
Part of the planned (hoped-for) change (using a system that is already
working for another project with even more code and committers) is to
automatically test patches on the buildbots before they are committed to
the central repository, rather than after. Each would be tested and
accepted or rejected separately. So each commit would have to stand on
its own even more than now.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
