On Feb 8, 2017 3:52 AM, "Martin Panter" <vadmium...@gmail.com> wrote:
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/c 64d263ec003f09fe4ebc50912fbe28de96fb2d3 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. I agree that this looks better. Also, I guess if you restricted the rule to "Issue #NNNN", that may reduce false positives. I always use the format '#NNNN: message' in my commits. Matching '^#\d+' too should solve the issue without increasing false positive, since rarely they happen at the beginning of the string. 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) bpo issues start from 1000, so these could be easily avoided. Limiting the range upwards using the highest number reached at the moment of the conversion will also limit false positives. 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. If the range check is implemented, this won't match. If there are low numbered SF issues and the SF prefix is commonly used, it could be added to the regex so that these numbers don't get converted. It might be worth looking for more false positives and see if they follow easily-recognizable patterns that can be added to the regex. Best Regards, Ezio Melotti > 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
