Choosing a prefix/label for issue numbers
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).
On Wed, Feb 1, 2017 at 11:43 AM, Brett Cannon <brett@python.org> wrote:
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).
+1 to those votes (issue -1, bug +0, bpo +1). -- Zach
Hmm... +1 bpo NNNN -1 bug NNNN, not everything is a bug +1 issue NNNN, I'm new, so I don't have any 'old habit' yet :P Mariatta Wijaya On Wed, Feb 1, 2017 at 9:43 AM, Brett Cannon <brett@python.org> 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
On Wed, Feb 1, 2017 at 8:43 PM, Brett Cannon <brett@python.org> 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
bug NNNN
As an ex-Mozillian, +1 :)
bpo NNNN ("bpo" stands for "bugs.python.org")
+0 --Berker
+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)? * can it be disabled? * if the corresponding issue doesn't exist, will the link still be created? * if it won't be created, will it link to PRs instead (once we have enough)? * 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) )? * if there is, can it be used on PR titles, PR messages, and commit messages? Best Regards, Ezio Melotti On Wed, Feb 1, 2017 at 7:43 PM, Brett Cannon <brett@python.org> 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
On Wed, 1 Feb 2017 at 10:52 Ezio Melotti <ezio.melotti@gmail.com> 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 <brett@python.org> 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
* 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 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. 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`. Cheers, -- M On Wed, Feb 1, 2017 at 11:09 AM, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 10:52 Ezio Melotti <ezio.melotti@gmail.com> 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 <brett@python.org> 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 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 <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 10:52 Ezio Melotti <ezio.melotti@gmail.com> 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 <brett@python.org> 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 Feb 1, 2017, at 12:43, Brett Cannon <brett@python.org> 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... -- Ned Deily nad@python.org -- []
On 01.02.2017 20:02, Ned Deily wrote:
On Feb 1, 2017, at 12:43, Brett Cannon <brett@python.org> 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 Wed, 1 Feb 2017 at 11:02 Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 12:43, Brett Cannon <brett@python.org> 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.
On Feb 1, 2017, at 14:14, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 11:02 Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 12:43, Brett Cannon <brett@python.org> 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 Wed, Feb 1, 2017, 11:43 Ned Deily, <nad@python.org> wrote:
On Feb 1, 2017, at 14:14, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 11:02 Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 12:43, Brett Cannon <brett@python.org> 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?
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? But if we agree to issueNNNN and stop using "issue NNNN" then I'm less bothered by this is it means we chose a very subtle namespacing (I'm still -0, though, as I see people forgetting to leave out the space). -Brett
-- 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 Feb 1, 2017, at 14:56, Brett Cannon <brett@python.org> 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 -- []
On 1 February 2017 at 21:07, Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 14:56, Brett Cannon <brett@python.org> 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.
The UX argument in favour of "bpo 12345" is that it's a nudge to *humans* used to GitHub-only workflows that the issue tracker lives somewhere other than in GitHub itself. More selfishly, it also translates nicely to redistributor systems, since it inherently namespaces *CPython* issues - "bpo 12345" is unambiguously the upstream issue number, rather than the downstream one. Not especially necessary (we're well accustomed to the existing naming scheme), but it doesn't hurt either. So +1 to allowing "bpo 12345" from me, and +0 to continuing with only issue12345 and issue 12345. Could we get a pre-commit hook that looks for the "#12345" and actively disallows it? (akin to the one that handles the whitespace check locally) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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 Wed, 1 Feb 2017 at 12:23 Ned Deily <nad@python.org> 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. -Brett
-- 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 Feb 1, 2017, at 16:35, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 12:23 Ned Deily <nad@python.org> 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 Thu, Feb 2, 2017 at 1:33 AM, Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 16:35, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 12:23 Ned Deily <nad@python.org> 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. --Berker
On Wed, 1 Feb 2017 at 15:14 Berker Peksağ <berker.peksag@gmail.com> wrote:
On Thu, Feb 2, 2017 at 1:33 AM, Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 16:35, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 12:23 Ned Deily <nad@python.org> 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 Wed, 1 Feb 2017 at 14:34 Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 16:35, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 12:23 Ned Deily <nad@python.org> 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. (And do realize that hg.python.org regularly requires restarts because it runs out of memory, so that customization comes at a price of maintenance and Benjamin's time to restart the service.)
On Feb 1, 2017, at 18:14, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 14:34 Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 16:35, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 12:23 Ned Deily <nad@python.org> 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, 1 Feb 2017 at 15:45 Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 18:14, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 14:34 Ned Deily <nad@python.org> wrote:
On Feb 1, 2017, at 16:35, Brett Cannon <brett@python.org> wrote:
On Wed, 1 Feb 2017 at 12:23 Ned Deily <nad@python.org> 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!
I'm sure you do and if I implied I thought otherwise I apologize. It's just a bit late to find something "unfortunate" unless it's so bad as to require stopping the process.
On Wed, Feb 1, 2017 at 6:14 PM, Brett Cannon <brett@python.org> 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.
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. On Wed, 1 Feb 2017 at 15:56 Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
On Wed, Feb 1, 2017 at 6:14 PM, Brett Cannon <brett@python.org> 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 <brett@python.org> 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 Thu, Feb 2, 2017 at 2:13 AM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
On Wed, Feb 1, 2017 at 7:51 PM, Brett Cannon <brett@python.org> 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.
Issue vs issues is not a problem since we're ignoring case in most of the code dealing with those, already. Personally I'd vote to bpo, but I'm biased about it, since it's the one coming from gh migration ;)
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.
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.
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.
On Wed, Feb 1, 2017 at 4:51 PM, Brett Cannon <brett@python.org> 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
On Feb 3, 2017, at 19:02, Senthil Kumaran <senthil@uthcode.com> 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 <brett@python.org> 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 -- []
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 <nad@python.org> wrote:
On Feb 3, 2017, at 19:02, Senthil Kumaran <senthil@uthcode.com> 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 <brett@python.org> 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, Feb 3, 2017 at 5:20 PM, Brett Cannon <brett@python.org> 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 -- Senthil
On Fri, 3 Feb 2017 at 17:32 Senthil Kumaran <senthil@uthcode.com> wrote:
On Fri, Feb 3, 2017 at 5:20 PM, Brett Cannon <brett@python.org> 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 4 February 2017 at 02:44, Brett Cannon <brett@python.org> wrote:
On Fri, 3 Feb 2017 at 17:32 Senthil Kumaran <senthil@uthcode.com> wrote:
On Fri, Feb 3, 2017 at 5:20 PM, Brett Cannon <brett@python.org> 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-").
There's an added UX bonus to doing this: "learn by example" from the old commit messages will nudge folks towards using the new naming scheme. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Feb 3, 2017 4:35 PM, "Ned Deily" <nad@python.org> 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 Fri, Feb 3, 2017 at 4:35 PM, Ned Deily <nad@python.org> 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/c64d263ec003f09fe... Please review the repo and see if it has everything that we will need after migration Thanks, Senthil
On Tue, Feb 7, 2017 at 1:19 AM, Senthil Kumaran <senthil@uthcode.com> wrote:
On Fri, Feb 3, 2017 at 4:35 PM, Ned Deily <nad@python.org> 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 Tue, 7 Feb 2017 at 02:32 Maciej Szulik <soltysh@gmail.com> wrote:
On Tue, Feb 7, 2017 at 1:19 AM, Senthil Kumaran <senthil@uthcode.com> wrote:
On Fri, Feb 3, 2017 at 4:35 PM, Ned Deily <nad@python.org> 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/c64d263ec003f09fe...
Please review the repo and see if it has everything that we will need after migration
Looks fine for me, thanks!
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. :)
On 7 February 2017 at 18:39, Brett Cannon <brett@python.org> 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
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@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/c64d263ec003f09fe... 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.
On Feb 8, 2017 3:52 AM, "Martin Panter" <vadmium+py@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@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.
On Wed, Feb 8, 2017 at 4:43 AM, Ezio Melotti <ezio.melotti@gmail.com> wrote:
On Feb 8, 2017 3:52 AM, "Martin Panter" <vadmium+py@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.
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
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 <senthil@uthcode.com> wrote:
On Wed, Feb 8, 2017 at 4:43 AM, Ezio Melotti <ezio.melotti@gmail.com> wrote:
On Feb 8, 2017 3:52 AM, "Martin Panter" <vadmium+py@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.
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 Thu, Feb 9, 2017 at 5:39 AM, Brett Cannon <brett@python.org> 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. ChrisA
On Wed, 8 Feb 2017 at 20:29 Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Feb 9, 2017 at 5:39 AM, Brett Cannon <brett@python.org> 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 Thu, Feb 9, 2017 at 7:40 AM, Brett Cannon <brett@python.org> wrote:
On Wed, 8 Feb 2017 at 20:29 Chris Angelico <rosuav@gmail.com> wrote:
On Thu, Feb 9, 2017 at 5:39 AM, Brett Cannon <brett@python.org> 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.
Indeed, it's difficult to keep up with all the threads :) To summarize, are these alternatives correct? 1) we don't rewrite: users will see #NNNN, issue #NNNN, etc, but those will just be plain text and won't like anywhere. This might cause minor confusions to users (they can see they are not links to GH issues/PRs, but they might not know what they refer to). Even if eventually we might have enough PRs that the numbers will start overlapping, there shouldn't be any wrong link (the link are not created retroactively, unless GH changes in the future). We will still use bpo-NNNN moving forward to avoid ambiguity, even thought it will be inconsistent with the old ids. 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.
issues/PRs, but they might not know what they refer to). Even if eventually we might have enough PRs that the numbers will start overlapping, there shouldn't be any wrong link (the link are not created retroactively, unless GH changes in the future).
Nice! Now I'm -1 for both of rewriting and hg annotations.
On 9 February 2017 at 06:55, Ezio Melotti <ezio.melotti@gmail.com> 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 10:39 AM, Brett Cannon <brett@python.org> 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.
I am +1 to this rewrite. For the consistency it brings, I see more value in doing vs not doing it. I am not not too much worried about the false positives (the typing github references are only false positives that I can think so far). Everyone, please let us know your opinion and I will get a test run today again before the final one tomorrow. -- Senthil
On Wed, Feb 8, 2017 at 9:03 PM, Senthil Kumaran <senthil@uthcode.com> 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 Thu, Feb 9, 2017 at 4:54 AM, Berker Peksağ <berker.peksag@gmail.com> wrote:
On Wed, Feb 8, 2017 at 9:03 PM, Senthil Kumaran <senthil@uthcode.com> 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 :)
If the alternative is having broken/misleading links that point to unrelated github PRs, I'd rather rewrite -- even if we miss a few edge cases. I think we can come up with a regex that matches most of them.
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.
+1 for me as well. I don't think branch info belongs in the commit message. Can it be saved in a separate field?
Thank you for working on this, Senthil!
--Berker
On Fri, Feb 03, 2017 at 04:02:43PM -0800, Senthil Kumaran <senthil@uthcode.com> wrote:
On Wed, Feb 1, 2017 at 4:51 PM, Brett Cannon <brett@python.org> 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.
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 <brett@python.org> 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:36 PM, Brett Cannon <brett@python.org> wrote:
I've never seen anyone actually use GH-NNNN in the wild
I certainly did use it even though I can't find a reference off hand. I seem to recall that some project I contributed to used gh- shortcuts consistently. That's how I first learned about it.
On 1 February 2017 at 22:36, Brett Cannon <brett@python.org> wrote:
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 <brett@python.org> 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).
For what it's worth, NAME-12345 is the way JIRA handles autolinking of references, since it assumes the JIRA instance is specific to a particular organisation and lets you specify short prefix codes for the projects. One benefit of a hyphen based syntax would be reducing the temptation to add in the "#" before the issue number. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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? On Wed, 1 Feb 2017 at 09:43 Brett Cannon <brett@python.org> 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).
On Feb 3, 2017, at 18:24, Brett Cannon <brett@python.org> 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 <soltysh@gmail.com> 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? 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. -- Ned Deily nad@python.org -- []
On Fri, 3 Feb 2017 at 16:06 Ned Deily <nad@python.org> wrote:
On Feb 3, 2017, at 18:24, Brett Cannon <brett@python.org> 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 <soltysh@gmail.com> 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 Feb 3, 2017, at 19:16, Brett Cannon <brett@python.org> wrote:
On Fri, 3 Feb 2017 at 16:06 Ned Deily <nad@python.org> 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. -- Ned Deily nad@python.org -- []
On Fri, 3 Feb 2017 at 16:25 Ned Deily <nad@python.org> wrote:
On Feb 3, 2017, at 19:16, Brett Cannon <brett@python.org> wrote:
On Fri, 3 Feb 2017 at 16:06 Ned Deily <nad@python.org> 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 Fri, 3 Feb 2017 at 16:25 Ned Deily <nad@python.org> wrote:
On Feb 3, 2017, at 19:16, Brett Cannon <brett@python.org> wrote:
On Fri, 3 Feb 2017 at 16:06 Ned Deily <nad@python.org> 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.
I checked how the changelog is automatically linked for https://docs.python.org/3/whatsnew/changelog.html and it looks like it would be easy to add support for both the old format and the new one (as well as unifying the format in the output so they all say "bpo-NNNN"; see https://github.com/python/cpython/blob/master/Doc/tools/extensions/pyspecifi...). Between that and updating the hooks on bugs.python.org for making the connection we should be able to use the new prefix from day 1.
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 Sat, Feb 4, 2017 at 12:24 AM, Brett Cannon <brett@python.org> 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.
On Wed, 1 Feb 2017 at 09:43 Brett Cannon <brett@python.org> 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).
On Mon, Feb 6, 2017 at 2:04 PM, Maciej Szulik <soltysh@gmail.com> wrote:
On Sat, Feb 4, 2017 at 12:24 AM, Brett Cannon <brett@python.org> 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 <brett@python.org> 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).
participants (16)
-
Alexander Belopolsky -
Berker Peksağ -
Brett Cannon -
Chris Angelico -
Ezio Melotti -
INADA Naoki -
M.-A. Lemburg -
Maciej Szulik -
Mariatta Wijaya -
Martin Panter -
Matthias Bussonnier -
Ned Deily -
Nick Coghlan -
Oleg Broytman -
Senthil Kumaran -
Zachary Ware