Should non-security 2.7 bugs be fixed?

[Chris Angelico]

On Tue, Jul 21, 2015 at 1:15 PM, Rustom Mody <rustompmody at gmail.com> wrote:
> [Chris already showed that this list is inaccurate -- probably related
> to hg not having sighoff distinct from commit like git]

It's also the manner of workflow. If you want to accept patches and
have them acknowledged to their original authors, the patches need to
carry metadata identifying the authors. I went to the tracker and hit
"Random Issue" and got one with an attached file as the first hit:

http://bugs.python.org/issue12982
http://bugs.python.org/file26008/issue12982.diff

Repeated the exercise and won again:

http://bugs.python.org/issue4733
http://bugs.python.org/file12437/urlopen_text.diff

Notice how the patch files start straight in with content. There's no
authorship information retained.

By comparison, a patch created with 'git format-patch' and applied
with 'git am' starts with RFC 822 headers, provides a commit message,
and generally is intended as a way of transmitting a *commit*, rather
than simply some changes. I'm not overly familiar with Mercurial
workflows, but I think 'hg export' and 'hg import' give the same sort
of information; I tried on CPython and got this:

# HG changeset patch
# User Robert Collins <rbtcollins at hp.com>
# Date 1436838700 -43200
#      Tue Jul 14 13:51:40 2015 +1200
# Branch 3.5
# Node ID 7021d46c490e8d9d3422737c69980dc1602f90db
# Parent  0127b0cad5ecb83c39ce58a4be27bf6d43a78d91
Issue #23661: unittest.mock side_effects can now be exceptions again.

This was a regression vs Python 3.4. Patch from Ignacio Rossi

diff -r 0127b0cad5ec -r 7021d46c490e Lib/unittest/mock.py
--- a/Lib/unittest/mock.py      Sat Jul 11 16:33:39 2015 -0700
+++ b/Lib/unittest/mock.py      Tue Jul 14 13:51:40 2015 +1200
@@ -506,7 +506,8 @@
         if delegated is None:

(chomp actual details)

Whether it's possible to have authorship retained or not, though, a
lot of patches can logically be credited to multiple people. Whose
name goes on it? With the CPython workflow, it's always the core
committer who applied it, nobody else. (That's consistent, at least.)
So the names in the log are of the people who have write access to the
repo, and nobody else.

ChrisA