On Wed, 1 Feb 2017 at 10:52 Ezio Melotti wrote:

+1 on bpo NNNN +0.5 on issue NNNN -0.5 on bug NNNN

However I wonder if there's any way to change the automatic GitHub links, or at least disable them. Even if we agree on a convention, it will take time to educate contributors, especially new or occasional ones (unless we have a way to put a disclaimer in a prominent place).

I'm not too familiar with GitHub, but: * can the link target be changed (i.e. from github.com to bugs.python.org)?

No

* can it be disabled?

No

* if the corresponding issue doesn't exist, will the link still be created?

No

* if it won't be created, will it link to PRs instead (once we have enough)?

PRs and issues are the same thing to GitHub in this instance.

* is there any mechanism (hooks/bots/etc) that allows us to convert #NNNN to an explicit link (i.e. [#NNNN](http://bugs.python.org/issueNNNN) )?

Not sure. I assume it will be overridden.

* if there is, can it be used on PR titles, PR messages, and commit messages?

Not titles, yes on messages. -Brett

Best Regards, Ezio Melotti

...

Historically commit messages for CPython have had the form of "Issue #NNNN: did something". The problem is that Github automatically links "#NNNN" to GitHub issues (which includes pull requests). To prevent incorrect

...

we need to change how we reference issue numbers.

The current candidates are:

issue NNNN (notice the lack of #)

bug NNNN

bpo NNNN ("bpo" stands for "bugs.python.org")

Whatever choice we go with it will be how we reference issues in PR

On Wed, Feb 1, 2017 at 7:43 PM, Brett Cannon wrote: linking titles

...

and comments to link the PR to the issue, and in commit messages to send a message to the issue about the commit.

To start this off, I'm -1 on "issue" (because people will out of habit add the #), +0 on "bug" (it's different but not everything is a bug), and +1 on "bpo" (as it namespaces our issues).

_______________________________________________ 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

On Wed, 1 Feb 2017 at 11:21 Matthias Bussonnier < bussonniermatthias@gmail.com> wrote:

...

...

* is there any mechanism (hooks/bots/etc) that allows us to convert #NNNN to an explicit link (i.e. [#NNNN](http://bugs.python.org/issueNNNN) )?

...

Not sure. I assume it will be overridden.

You should be able to do it in issues/PR messages with a bot that have the right permission, but not in commits. Which will be annoying. Also even after edition, the "this issue has been referenced in" will still be there.

The other annoying thing, is that if a `Fix #XXX`/`Close #XXX` message end up on the master branch it will auto close the github XXXX issue/PR. So you might even want to make sure people do not use #XXX to not autoclose by mistake. I'm unsure if # is necessary

The # is required: https://help.github.com/articles/autolinked-references-and-urls/#issues-and-...

but the following words in a commit message can trigger autoclosing of an issue/PR:

close closes closed fix fixes fixed resolve resolves resolved

I believe `issue` (maybe other things) can be put after the above words will still trigger autoclose.

https://help.github.com/articles/closing-issues-via-commit-messages/ seems to suggest that it won't work with "issue" added in.

So I would advise against using something that could be not only autolink, but would autoclose things as well.

Personally I would lean toward `bpo`.

As a reference point of how others handle this,GitHub also links GH-NNNN which obviously namespaces things (I should also mention that hg.python.org/lookup also now supports "git" and "hg" prefixes on commit IDs/hashes to easily differentiate since Python as a project continues to outlive the infrastructure it runs on :) . -Brett

Cheers, -- M

On Wed, Feb 1, 2017 at 11:09 AM, Brett Cannon wrote:

...

On Wed, 1 Feb 2017 at 10:52 Ezio Melotti wrote:

...

+1 on bpo NNNN +0.5 on issue NNNN -0.5 on bug NNNN

However I wonder if there's any way to change the automatic GitHub links, or at least disable them. Even if we agree on a convention, it will take time to educate contributors, especially new or occasional ones (unless we have a way to put a disclaimer in a prominent place).

I'm not too familiar with GitHub, but: * can the link target be changed (i.e. from github.com to bugs.python.org)?

No

...

* can it be disabled?

No

...

* if the corresponding issue doesn't exist, will the link still be created?

No

...

* if it won't be created, will it link to PRs instead (once we have enough)?

PRs and issues are the same thing to GitHub in this instance.

...

* is there any mechanism (hooks/bots/etc) that allows us to convert #NNNN to an explicit link (i.e. [#NNNN](http://bugs.python.org/issueNNNN) )?

Not sure. I assume it will be overridden.

...

* if there is, can it be used on PR titles, PR messages, and commit messages?

Not titles, yes on messages.

-Brett

...

Best Regards, Ezio Melotti

On Wed, Feb 1, 2017 at 7:43 PM, Brett Cannon wrote:

...

Historically commit messages for CPython have had the form of "Issue #NNNN: did something". The problem is that Github automatically links "#NNNN" to GitHub issues (which includes pull requests). To prevent incorrect linking we need to change how we reference issue numbers.

The current candidates are:

issue NNNN (notice the lack of #)

bug NNNN

bpo NNNN ("bpo" stands for "bugs.python.org")

Whatever choice we go with it will be how we reference issues in PR titles and comments to link the PR to the issue, and in commit messages to

send

...

...

...

a message to the issue about the commit.

To start this off, I'm -1 on "issue" (because people will out of habit add the #), +0 on "bug" (it's different but not everything is a bug), and +1 on "bpo" (as it namespaces our issues).

_______________________________________________ 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

_______________________________________________ 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

On 01.02.2017 20:02, Ned Deily wrote:

On Feb 1, 2017, at 12:43, Brett Cannon wrote:

...

Historically commit messages for CPython have had the form of "Issue #NNNN: did something". The problem is that Github automatically links "#NNNN" to GitHub issues (which includes pull requests). To prevent incorrect linking we need to change how we reference issue numbers.

The current candidates are:

issue NNNN (notice the lack of #)

+1

That form, as well as issueNNNN (no space), is already recognized in comments on bugs.python.org and autogenerates a link to the bug.

+1

https://docs.python.org/devguide/triaging.html#generating-special-links-in-a...

-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 01 2017)

...

...

Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/

::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

On Feb 1, 2017, at 14:14, Brett Cannon wrote:

On Wed, 1 Feb 2017 at 11:02 Ned Deily wrote:

...

On Feb 1, 2017, at 12:43, Brett Cannon wrote:

...

Historically commit messages for CPython have had the form of "Issue #NNNN: did something". The problem is that Github automatically links "#NNNN" to GitHub issues (which includes pull requests). To prevent incorrect linking we need to change how we reference issue numbers.

The current candidates are:

issue NNNN (notice the lack of #)

+1

That form, as well as issueNNNN (no space), is already recognized in comments on bugs.python.org and autogenerates a link to the bug.

https://docs.python.org/devguide/triaging.html#generating-special-links-in-a... We can change it to do whatever we want since we control bpo, so it can be updated to automatically link bpoNNNN or "bpo NNNN" as well.

Sure. My point was that IssueNNNN is a form that is already in common use: I, for one, use it all the time. Why invent another one? -- Ned Deily nad@python.org -- []

On Feb 1, 2017, at 14:56, Brett Cannon wrote:

Doomsday scenario:

- Roundup doesn't move to Python 3 (or some other reason) - We then move off of Roundup - New solution doesn't let us choose our issue #s (e.g. GitHub issues) - Now we have to namespace our issues going forward

So in my head we're going to have to deal with this someday anyway, so why not tweak it now instead of putting it off?

We've already transitioned through various bug trackers in a compatible manner. And who's to say that we might not decide to use bugs.python.org with something other than Roundup sometime in the future? But, assuming the doomsday scenario should come to pass, we could choose to add a new namespace then, gitbugnnnn or whatever, if we then need to and then decide issuennnnn refers only to old bugs. I don't see why we need to worry about this now when it may never be an issue, so to speak. And bponnnn seems really clunky. -- Ned Deily nad@python.org -- []

Perhaps I'm misunderstanding something. Are we planning to alter existing commit messages as part of the hg to fit transition? -- Ned Deily nad@python.org -- []

On Feb 1, 2017, at 16:35, Brett Cannon wrote:

On Wed, 1 Feb 2017 at 12:23 Ned Deily wrote:

...

Perhaps I'm misunderstanding something. Are we planning to alter existing commit messages as part of the hg to fit transition? No, we are not mucking with the history as part of the transition.

Sorry, I don't mean to resurrect any old discussions that I've forgotten about here but, just to be clear, that means that we will no longer be able to click through from the web pages of the tens of thousands of old commits back to their corresponding bug web pages as we can do today? For example, https://hg.python.org/cpython/rev/aa7ac93d23b2 (eventually) links back to https://bugs.python.org/issue20185 (at least it should if the SSL certificate weren't expired today), whereas the corresponding git commit (https://github.com/python/cpython/commit/9f889393ab0362229c42bc31056f3ef9735...) does not and will not provide a link back? That's ... unfortunate. -- Ned Deily nad@python.org -- []

On Wed, 1 Feb 2017 at 15:14 Berker Peksağ wrote:

On Thu, Feb 2, 2017 at 1:33 AM, Ned Deily wrote:

...

On Feb 1, 2017, at 16:35, Brett Cannon wrote:

...

On Wed, 1 Feb 2017 at 12:23 Ned Deily wrote:

...

Perhaps I'm misunderstanding something. Are we planning to alter existing commit messages as part of the hg to fit transition? No, we are not mucking with the history as part of the transition.

Sorry, I don't mean to resurrect any old discussions that I've forgotten about here but, just to be clear, that means that we will no longer be able to click through from the web pages of the tens of thousands of old commits back to their corresponding bug web pages as we can do today?

For example, https://hg.python.org/cpython/rev/aa7ac93d23b2 (eventually) links back to https://bugs.python.org/issue20185 (at least it should if the SSL certificate weren't expired today), whereas the corresponding git commit ( https://github.com/python/cpython/commit/9f889393ab0362229c42bc31056f3ef9735...) does not and will not provide a link back? That's ... unfortunate.

Correct, but that can be solved by using a small browser extension. I once wrote an extension that automatically generates bugzilla.mozilla.org/show_bug.cgi?id=NNNN links for "Bug NNNN" markers on GitHub.

Which is also another reason to add a namespace to the issue numbers to prevent accidental linking if an extension is used.

On Feb 1, 2017, at 18:14, Brett Cannon wrote:

On Wed, 1 Feb 2017 at 14:34 Ned Deily wrote:

...

On Feb 1, 2017, at 16:35, Brett Cannon wrote:

...

On Wed, 1 Feb 2017 at 12:23 Ned Deily wrote:

...

Perhaps I'm misunderstanding something. Are we planning to alter existing commit messages as part of the hg to fit transition? No, we are not mucking with the history as part of the transition.

Sorry, I don't mean to resurrect any old discussions that I've forgotten about here but, just to be clear, that means that we will no longer be able to click through from the web pages of the tens of thousands of old commits back to their corresponding bug web pages as we can do today?

Correct. You will have to copy-and-paste the issue number into a URL.

For example, https://hg.python.org/cpython/rev/aa7ac93d23b2 (eventually) links back to https://bugs.python.org/issue20185 (at least it should if the SSL certificate weren't expired today), whereas the corresponding git commit (https://github.com/python/cpython/commit/9f889393ab0362229c42bc31056f3ef9735...) does not and will not provide a link back? That's ... unfortunate.

For old issues that won't be a possibility, but for new issues it can be done. E.g. https://github.com/python/the-knights-who-say-ni/commit/aa82ec527570f8cf1b6a... links to the PR that the commit came from and the PR can have a link back to the referenced issue(s). If you really miss this then someone could always volunteer to stand up their own web server to server commit history with the desired functionality, but I don't think this is important enough to block the migration over as you're now asking that we figure out how to hack the migrated git history to embed URLs to a non-existent reflector like hg.python.org/lookup but for issue numbers. If we were also migrating the issue tracker then it would be possible as they would probably link to the GitHub issue number.

Understood. And I'm not asking that this block the migration; now that it is about to happen, I (and the rest of the community) have to wrap our brains around the way things will work. It was easier to avoid doing that earlier and let you and the others doing all the hard work figure it all out. I deeply appreciate your efforts! -- Ned Deily nad@python.org -- []

On Wed, Feb 1, 2017 at 6:14 PM, Brett Cannon wrote:

For old issues that won't be a possibility,

How hard would it be to s/#(\d+)/bpo-\1/ the commit messages during hg to git conversion? I did something like that in the past when I converted an svn-based project to git.

On Wed, Feb 1, 2017 at 7:51 PM, Brett Cannon wrote:

as the match should be probably s/issue #(\d+)/bpo-\1/ and it shows how easy it is to miss edge cases.

No, I deliberately omitted the "issue" part because AFAIK things like "Closes #NNNN" are valid references. I don't mind seeing "issue bpo-NNNN", but wouldn't want to complicate the logic by worrying about "issue" vs. "Issue" and other possible variants.

On Wed, Feb 1, 2017 at 4:51 PM, Brett Cannon wrote:

That's a question for Senthil, but I would be a little worried about editing the history as the match should be probably s/issue #(\d+)/bpo-\1/ and it shows how easy it is to miss edge cases.

It's easy to make the changes in the commit messages. It could be done at the conversion level by patching hg-git[1] that we plan to use. We will have to come a decision on if it is desirable to do it and the format that is preferable. [1]: https://github.com/schacon/hg-git

I just did a quick test and the "#NNNN" linking in commit messages only seems to occur if the issue exists at the time of pushing a commit. See https://github.com/brettcannon/gidgethub/commit/31fd4df5e3ade210fbfa39e55709... for an instance where "#2" didn't link since I didn't have an issue #2 yet, https://github.com/brettcannon/gidgethub/commit/92434150efb27c75a738c3ba3731... which did link because #2 existed, and https://github.com/brettcannon/gidgethub/commit/d2640d7fa7671049361d24a2c852... which didn't link in the title even though I created an issue after I pushed that commit. And since we will be creating a new project there will be no pre-existing issues to accidentally link to when we push the converted repo. On Fri, 3 Feb 2017 at 16:35 Ned Deily wrote:

On Feb 3, 2017, at 19:02, Senthil Kumaran wrote:

...

...

That's a question for Senthil, but I would be a little worried about editing the history as the match should be probably s/issue #(\d+)/bpo-\1/ and it shows how easy it is to miss edge cases. It's easy to make the changes in the commit messages. It could be done at the conversion level by patching hg-git[1] that we plan to use. We will have to come a decision on if it is desirable to do it and the

On Wed, Feb 1, 2017 at 4:51 PM, Brett Cannon wrote: format that is preferable.

It seems to be that this is a pretty big usability issue and that this is the one chance we might have to "painlessly" deal with it if we can, assuming github.com doesn't provide some configuration options for this in the future. So my vote would be to at least try to do a test of this and see what results pop up. OTOH, I don't want the migration to bog down for weeks in seeking a perfect solution.

It would be great if you could try something, Senthil. Other opinions?

-- Ned Deily nad@python.org -- []

_______________________________________________ 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

On Fri, 3 Feb 2017 at 17:32 Senthil Kumaran wrote:

On Fri, Feb 3, 2017 at 5:20 PM, Brett Cannon wrote:

...

And since we will be creating a new project there will be no pre-existing issues to accidentally link to when we push the converted repo.

That's a good news.. Thanks for testing this, Brett. This seems to apply to both issues and pull requests

I was not worried about issues, since we would be using b.p.o. I was thinking pull-requests could cause problems, if there was any auto hyperlink happening.

The choice is still with us. We can rewrite #NNNN to "bpo NNNN" if we want.

+ve: It seems future proof to me. -ve: Looks a bit ugly when compared to #NNNN

I say try rewriting s/#(\d+)/bpo-\1/ and let's see how it turns out if you're up for it, Senthil (notice I went with the hyphen approach for "bpo-").

On Feb 3, 2017 4:35 PM, "Ned Deily" wrote: It would be great if you could try something, Senthil. Other opinions? I am definitely in for it. I will do some test migrations with our preferences and push a test repo for review. Thanks, Senthil

On Tue, Feb 7, 2017 at 1:19 AM, Senthil Kumaran wrote:

On Fri, Feb 3, 2017 at 4:35 PM, Ned Deily wrote:

...

It would be great if you could try something, Senthil.

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: https://github.com/orsenthil/cpython-migration-test/commit/ c64d263ec003f09fe4ebc50912fbe28de96fb2d3

Please review the repo and see if it has everything that we will need after migration

Looks fine for me, thanks!

On 7 February 2017 at 18:39, Brett Cannon wrote:

Just to remind people, the migration is happening Friday, so we need to make a yay/nay on whether we are going to tweak the history as Senthil has tested very soon. So I'm putting a deadline of Wednesday night to vote on whether we should tweak the history as proposed. I'll look at the results and will make a final decision Thursday as to whether we will tweak the history or leave it as-is.

So far Maciej is +1 on the change, which puts the change in the lead. :)

+1 from me on making the change, based on the following assessment of the two options: * Do nothing (-1): - human readers are likely to expect "#1234" on GitHub to refer to GitHub issues, but we're not using the GitHub issue tracker - we *know* the old cross-links won't work and we'll never be able to make them work due to the clash with the native issue referencing syntax * Reformat (+1): - human readers are unlikely to interpret "bpo-12345" as a GitHub issue reference - if GitHub and/or other git hosting platforms like GitLab gain a project-wide regex based link generation mechanism, we'll have a suitable format to take advantage of it - even if "#(\d+)" does misfire on a few messages, it would be relatively easy to mentally translate from "bpo-12345" back to "#12345" in context Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Feb 8, 2017 3:52 AM, "Martin Panter" 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 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.

Just a reminder that I'l make a decision about this tomorrow so Senthil has a day to test a conversion with the proposal below. So if you like what Senthil is proposing then please say so, else you can also say you don't want any history rewriting. On Wed, 8 Feb 2017 at 10:09 Senthil Kumaran wrote:

On Wed, Feb 8, 2017 at 4:43 AM, Ezio Melotti wrote:

...

On Feb 8, 2017 3:52 AM, "Martin Panter" 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.

Thanks for the valuable feedback, Martin and Ezio.

...

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

As you both pointed out and as I browse through the commits at https://github.com/orsenthil/cpython-migration-test/commits/master after the #NNNN to bpo-NNNN

_If we decide to rewrite_, I see the following areas of improvement.

1) Rename #NNNN, Issue #NNNN, issue #NNNN, IssueNNNN, issueNNNN to bpo-NNNN 2) Looking for numbers 1000 and above which don't start with SF, is okay with me as it can reduce the false positives.

The change I did to hg-git was this:

https://bitbucket.org/orsenthil/hg-git/commits/75408e7efdbc73a4da435080f23fb...

And that other rules that we are discussing can be included.

I am +1 to change if we do it consistently for all different {IssueNNNN, issueNNNN, Issue #NNNN, issue #NNNN, #NNNN, SF #NNNN} usage. As Nick pointed out earlier in this thread, the positive aspect of rewriting includes, showing an example for how new commit messages are to be written.

If we don't want to span it across all issue formats, but restrict it only to #NNNN, then I am -1. As Martin points out, it looks half done to me.

Also, other feedback from Martin was to not have hg branch annotation. E.g: https://github.com/orsenthil/cpython-migration-test/commit/851c48a

That can be removed. I am unable to decide on the merits/de-merits. hg-git tool seems to be doing that commit extra messages by default. The annotation gives information that commit was originally done in that particular hg branch.

Thank you, Senthil _______________________________________________ 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

On Wed, 8 Feb 2017 at 20:29 Chris Angelico wrote:

On Thu, Feb 9, 2017 at 5:39 AM, Brett Cannon wrote:

...

Just a reminder that I'l make a decision about this tomorrow so Senthil has a day to test a conversion with the proposal below. So if you like what Senthil is proposing then please say so, else you can also say you don't want any history rewriting.

I'm +1 on history rewriting as part of the move. Having unambiguous clickable links is worth the risk of false positives.

I think everyone is forgetting that I did an experiment where the links don't show up if there is no pre-existing issue or PR to connect with. That means there shouldn't be any expectation of bad links from the initial push, only if we continue to use the #NNNN format going forward.

On Wed, Feb 8, 2017 at 9:55 PM, Ezio Melotti wrote:

To summarize, are these alternatives correct?

yes, that is accurate.

On 9 February 2017 at 06:55, Ezio Melotti wrote:

2) we rewrite: users will see bpo-NNNN on old commit messages and they will know that they are not links to GH issues/PRs, and they might know/guess that bpo refers to bugs.python.org. These will still be plain text and won't link to bpo (unless GH allows us to do it in the future). We will still use bpo-NNNN moving forward, and this will be consistent with the rewritten history and unambiguous with PRs ids.

And if either GitHub or other hosting platforms running mirrors gain a regex based linking capability, we'll have an easy time pointing both pre-migration and post-migration commits to the right place. Cheers, Nick. P.S. Note that all the old SF issues were imported into b.p.o with their original issue numbers, so it's entirely correct to translate "SF #433233" into bpo-433233 -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, Feb 8, 2017 at 9:03 PM, Senthil Kumaran wrote:

_If we decide to rewrite_, I see the following areas of improvement.

1) Rename #NNNN, Issue #NNNN, issue #NNNN, IssueNNNN, issueNNNN to bpo-NNNN 2) Looking for numbers 1000 and above which don't start with SF, is okay with me as it can reduce the false positives.

Count me as -1 for history rewrite. There are many different commit message styles and we probably will miss some edge cases :)

Also, other feedback from Martin was to not have hg branch annotation. E.g: https://github.com/orsenthil/cpython-migration-test/commit/851c48a

That can be removed. I am unable to decide on the merits/de-merits. hg-git tool seems to be doing that commit extra messages by default. The annotation gives information that commit was originally done in that particular hg branch.

+1 for removing the branch annotation. +0 if there is no easy way to do it. Thank you for working on this, Senthil! --Berker

On Fri, Feb 03, 2017 at 04:02:43PM -0800, Senthil Kumaran wrote:

On Wed, Feb 1, 2017 at 4:51 PM, Brett Cannon wrote:

...

That's a question for Senthil, but I would be a little worried about editing the history as the match should be probably s/issue #(\d+)/bpo-\1/ and it shows how easy it is to miss edge cases.

It's easy to make the changes in the commit messages. It could be done at the conversion level by patching hg-git[1] that we plan to use. We will have to come a decision on if it is desirable to do it and the format that is preferable.

[1]: https://github.com/schacon/hg-git

Or post-process the converted repo using git filter-branch --msg-filter '...' Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Wed, 1 Feb 2017 at 13:21 Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

On Wed, Feb 1, 2017 at 12:43 PM, Brett Cannon wrote:

bpo NNNN ("bpo" stands for "bugs.python.org")

Shouldn't it be bpo-NNNN for consistency with gh-NNNN?

It could be. It's really up to us as I've never seen anyone actually use GH-NNNN in the wild (I honestly didn't know about it until I pulled up the docs to respond to Matthias).

On Wed, Feb 1, 2017 at 4:51 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

I seem to recall that some project I contributed to used gh- shortcuts consistently.

Actually, that project was NumPy.

On Fri, 3 Feb 2017 at 16:06 Ned Deily wrote:

On Feb 3, 2017, at 18:24, Brett Cannon wrote:

...

It looks like people in general prefer "bpo-NNNN" (sorry, Ned and MAL).

I'll live. :)

...

Maciej, can we update the requisite regexes so that bpo-NNNN is acceptable in PR titles, PR comments, and commit messages?

Two things:

1. What about Maciej's earlier comment:

On Feb 2, 2017, at 16:20, Maciej Szulik wrote:

...

Hmm... for all the #NNN in commits we'll get quite a few false links in github, so maybe removing the # would be valuable, or replacing it with issue/bpo.

I'm guessing that's gonna be a ugly usability issue if all the old github commit pages offer invalid links for all of the old #nnnnn references. Or am I missing something there?

See Senthil's comment. It seems doable if we want to do it and can agree on the regex to use to transform them.

2. What about Misc/NEWS entries? Are we going to continue to ask committers to use the old format (Issue #nnnnn) there? Note these are currently auto-linked in the docs builds, e.g. https://docs.python.org/3.6/whatsnew/changelog.html.

Don't know. My expectation is that long term we won't even specify them in the entry itself and it will be part of the filename when we move to a file-per-entry solution.

On Fri, 3 Feb 2017 at 16:25 Ned Deily wrote:

On Feb 3, 2017, at 19:16, Brett Cannon wrote:

...

On Fri, 3 Feb 2017 at 16:06 Ned Deily wrote:

...

2. What about Misc/NEWS entries? Are we going to continue to ask committers to use the old format (Issue #nnnnn) there? Note these are currently auto-linked in the docs builds, e.g. https://docs.python.org/3.6/whatsnew/changelog.html. Don't know. My expectation is that long term we won't even specify them in the entry itself and it will be part of the filename when we move to a file-per-entry solution.

That would be nice long-term. I guess we just need to be clear during the immediate transition what the expectation for committers are about what forms they need to use in the commit messages and in Misc/NEWS. That needs to be spelled out in transition announcements and in the devguide to minimize confusion, especially if they will no longer be the same, e.g "bpo-NNNNN" in the commit message but "Issue #NNNNN" in Misc/NEWS.

Yes. I guess if we want to minimize tool churn on this and not impact bugfix releases we should keep Misc/NEWS as-is until we make an actual Misc/NEWS change. Once Maciej says he has changed the appropriate regexes the devguide can be updated in the github branch and all of this will be in any announcement email I make about what has changed in the migration (e.g. CLA bot, cherrypicking, etc.). I'll probably start that as a doc next week when I'm not sick so people can help me fill in gaps.

On 04.02.2017 00:24, Brett Cannon wrote:

It looks like people in general prefer "bpo-NNNN" (sorry, Ned and MAL).

No worries. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 06 2017)

...

...

Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/

::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

On Mon, Feb 6, 2017 at 2:04 PM, Maciej Szulik wrote:

On Sat, Feb 4, 2017 at 12:24 AM, Brett Cannon wrote:

...

It looks like people in general prefer "bpo-NNNN" (sorry, Ned and MAL).

Maciej, can we update the requisite regexes so that bpo-NNNN is acceptable in PR titles, PR comments, and commit messages?

Sorry, was out this weekend. Sure I'll handle this later today.

The fix was applied yesterday and is already live.

...

On Wed, 1 Feb 2017 at 09:43 Brett Cannon wrote:

...

Historically commit messages for CPython have had the form of "Issue #NNNN: did something". The problem is that Github automatically links "#NNNN" to GitHub issues (which includes pull requests). To prevent incorrect linking we need to change how we reference issue numbers.

The current candidates are:

issue NNNN (notice the lack of #)

bug NNNN

bpo NNNN ("bpo" stands for "bugs.python.org")

Whatever choice we go with it will be how we reference issues in PR titles and comments to link the PR to the issue, and in commit messages to send a message to the issue about the commit.

To start this off, I'm -1 on "issue" (because people will out of habit add the #), +0 on "bug" (it's different but not everything is a bug), and +1 on "bpo" (as it namespaces our issues).