Count me as a weak -0.5 or so for altering commit messages. I think it is easy enough to understand that historical messages refer to a particular bug tracker, and false positives can be annoying, distracting, make you wonder about the sanity of the person who originally made the commit, etc.
On 7 February 2017 at 11:19, Senthil Kumaran <sent...@uthcode.com> wrote: > I did a sample migration of the repo with the change we discussed for > rewrite #NNNN to bpo-NNNN > > The migrated test-repo is here: > https://github.com/orsenthil/cpython-migration-test > > An example of commit message re-write from #NNNN to bpo-NNNN is here: This is the commit message before and after: https://hg.python.org/cpython/rev/82d1c8d15e18 Issue #29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and _PyArg_NoPositional() now are macros. > https://github.com/orsenthil/cpython-migration-test/commit/c64d263ec003f09fe4ebc50912fbe28de96fb2d3 Issue bpo-29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and _PyArg_NoPositional() now are macros. Having both "Issue" and "bpo" there is redundant. It could just be bpo-29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and _PyArg_NoPositional() now are macros. Also, I guess if you restricted the rule to "Issue #NNNN", that may reduce false positives. Modern example of a false positive, with upstream "typing" project references: https://hg.python.org/cpython/rev/794dad4b849f Issue #28556: merge 5 more typing changes from upstream (#340, #344, #348, #349, #350) https://github.com/orsenthil/cpython-migration-test/commit/8840a59 Issue bpo-28556: merge 5 more typing changes from upstream (bpo-340, bpo-344, bpo-348, bpo-349, bpo-350) On the other hand, replacing just #NNNN correctly catches other notations, e.g. to <https://bugs.python.org/issue433233>: http://svn.python.org/view?view=revision&revision=21142 Fix SF #433233: syntax error. https://github.com/orsenthil/cpython-migration-test/commit/aa4de32 Fix SF bpo-433233: syntax error. > Please review the repo and see if it has everything that we will need > after migration One other thing that I noticed: The Mercurial branch name is recorded as an annotation to the commit message, e.g. <https://github.com/orsenthil/cpython-migration-test/commit/851c48a>: ''' Substitute a more readable f-string --HG-- branch : 3.6 ''' I would prefer without this annotation, like the old <https://github.com/python/cpython> mirror. Less important (can be fixed afterwards): Probably don't need the legacy-trunk branch. I understand this is just what the 2.7 (and earlier) branches were branched from. But since there was already a separate py3k branch when 2.7 was branched, there is nothing useful in legacy-trunk that is not in 2.7. _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
