[core-workflow] Choosing a prefix/label for issue numbers

[Ezio Melotti]

On Feb 8, 2017 3:52 AM, "Martin Panter" <vadmium+py at 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 <senthil at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20170208/e626be31/attachment.html>