From brett at python.org Wed Feb 1 12:43:58 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 17:43:58 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers Message-ID: 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: From terri at toybox.ca Wed Feb 1 03:02:19 2017 From: terri at toybox.ca (Terri Oda) Date: Wed, 1 Feb 2017 00:02:19 -0800 Subject: [core-workflow] Planning the GitHub migration In-Reply-To: References: Message-ID: On 2017-01-31 1:24 PM, Ezio Melotti wrote: > On Tue, Jan 31, 2017 at 11:21 PM, Alexander Belopolsky > wrote: >> >> On Tue, Jan 31, 2017 at 3:52 PM, Ezio Melotti >> wrote: >>> >>> you can submit a project idea for GSoC by the 7th of >>> February. >> >> >> Where can I find instructions on how to do it? I may have an idea to >> submit. > > See http://python-gsoc.org/#mentors and/or ask on #python-gsoc on Freenode. > A good project idea is something well-described that a student can make a plan to complete within the 3 month coding period, with the help of mentors. We usually ask for two mentors per project, but it's usually not too hard to find a backup mentor if you ask on the mailing lists or ask me (I usually have a few spare volunteers.) Basically, write a paragraph or two, provide links to related bugs or discussions, some information about difficulty, and any other information student would need to know is what we're looking for. (For a more specific checklist, there's an ideas page template that might help: https://wiki.python.org/moin/SummerOfCode/OrgIdeasPageTemplate) We get up to PhD level students with various levels of real project experience, but there are a huge number of students browsing ideas who are *maybe* 1st year university students without work experience. So when you're explaining difficulty, remember it's relative to those students who are young, inexperienced, and need to know what ideas are suitable for them. There's a currently very blank template for python core ideas here: https://wiki.python.org/moin/SummerOfCode/2017/python-core (If that's not convenient for you to edit, we also keep stuff on github, or you can just email me with the data you want on there.) Feel free to ask me more questions or drop by #python-gsoc (or our new zulip instance: https://zulip.python-gsoc.org/ ) to chat. Terri From zachary.ware+pydev at gmail.com Wed Feb 1 12:56:18 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Wed, 1 Feb 2017 11:56:18 -0600 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 11:43 AM, Brett Cannon 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 From mariatta.wijaya at gmail.com Wed Feb 1 12:57:39 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Wed, 1 Feb 2017 09:57:39 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berker.peksag at gmail.com Wed Feb 1 13:14:35 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Wed, 1 Feb 2017 21:14:35 +0300 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 8: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 #) +1 > bug NNNN As an ex-Mozillian, +1 :) > bpo NNNN ("bpo" stands for "bugs.python.org") +0 --Berker From ezio.melotti at gmail.com Wed Feb 1 13:52:34 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Wed, 1 Feb 2017 20:52:34 +0200 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: +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 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 at 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 From nad at python.org Wed Feb 1 14:02:37 2017 From: nad at python.org (Ned Deily) Date: Wed, 1 Feb 2017 14:02:37 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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-comment -- Ned Deily nad at python.org -- [] From mal at egenix.com Wed Feb 1 14:07:18 2017 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 1 Feb 2017 20:07:18 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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-comment -- 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/ From brett at python.org Wed Feb 1 14:09:32 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 19:09:32 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 1 14:14:43 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 19:14:43 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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-comment 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bussonniermatthias at gmail.com Wed Feb 1 14:21:35 2017 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Wed, 1 Feb 2017 11:21:35 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: >> * 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 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 at 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 at 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 From brett at python.org Wed Feb 1 14:36:29 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 19:36:29 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: On Wed, 1 Feb 2017 at 11:21 Matthias Bussonnier < bussonniermatthias at 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-pull-requests > 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 at 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Wed Feb 1 14:43:19 2017 From: nad at python.org (Ned Deily) Date: Wed, 1 Feb 2017 14:43:19 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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-comment > 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 at python.org -- [] From brett at python.org Wed Feb 1 14:56:05 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 19:56:05 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017, 11:43 Ned Deily, wrote: > 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-comment > > 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 at python.org -- [] > > _______________________________________________ > core-workflow mailing list > core-workflow at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Wed Feb 1 15:07:36 2017 From: nad at python.org (Ned Deily) Date: Wed, 1 Feb 2017 15:07:36 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: <3CA04B34-8536-4B41-9F55-8B270A6966E7@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 at python.org -- [] From ncoghlan at gmail.com Wed Feb 1 15:18:19 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 1 Feb 2017 21:18:19 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> Message-ID: On 1 February 2017 at 21:07, Ned Deily wrote: > 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. 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 at gmail.com | Brisbane, Australia From nad at python.org Wed Feb 1 15:22:55 2017 From: nad at python.org (Ned Deily) Date: Wed, 1 Feb 2017 15:22:55 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> Message-ID: Perhaps I'm misunderstanding something. Are we planning to alter existing commit messages as part of the hg to fit transition? -- Ned Deily nad at python.org -- [] From alexander.belopolsky at gmail.com Wed Feb 1 16:21:05 2017 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 1 Feb 2017 16:21:05 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 1 16:35:46 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 21:35:46 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> Message-ID: 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. -Brett > > -- > Ned Deily > nad at python.org -- [] > > > _______________________________________________ > core-workflow mailing list > core-workflow at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed Feb 1 16:51:11 2017 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 1 Feb 2017 16:51:11 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 4:36 PM, Brett Cannon 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed Feb 1 16:52:54 2017 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 1 Feb 2017 16:52:54 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: On Wed, Feb 1, 2017 at 4:51 PM, Alexander Belopolsky < alexander.belopolsky at gmail.com> wrote: > I seem to recall that some project I contributed to used gh- shortcuts > consistently. Actually, that project was NumPy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 1 16:36:43 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 21:36:43 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: On Wed, 1 Feb 2017 at 13:21 Alexander Belopolsky < alexander.belopolsky at 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Wed Feb 1 17:29:51 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 1 Feb 2017 23:29:51 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: On 1 February 2017 at 22:36, Brett Cannon wrote: > On Wed, 1 Feb 2017 at 13:21 Alexander Belopolsky > 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). 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 at gmail.com | Brisbane, Australia From nad at python.org Wed Feb 1 17:33:45 2017 From: nad at python.org (Ned Deily) Date: Wed, 1 Feb 2017 17:33:45 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> Message-ID: <41E4F1BD-1806-4843-8E19-959C405F5061@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/9f889393ab0362229c42bc31056f3ef9735a1d27) does not and will not provide a link back? That's ... unfortunate. -- Ned Deily nad at python.org -- [] From berker.peksag at gmail.com Wed Feb 1 18:14:09 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Thu, 2 Feb 2017 02:14:09 +0300 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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/9f889393ab0362229c42bc31056f3ef9735a1d27) 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 From brett at python.org Wed Feb 1 18:14:41 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 23:14:41 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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/9f889393ab0362229c42bc31056f3ef9735a1d27) > 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/aa82ec527570f8cf1b6ae13037ba6535afe26e5a 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 1 18:19:10 2017 From: brett at python.org (Brett Cannon) Date: Wed, 01 Feb 2017 23:19:10 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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/9f889393ab0362229c42bc31056f3ef9735a1d27) > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Wed Feb 1 18:45:03 2017 From: nad at python.org (Ned Deily) Date: Wed, 1 Feb 2017 18:45:03 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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/9f889393ab0362229c42bc31056f3ef9735a1d27) 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/aa82ec527570f8cf1b6ae13037ba6535afe26e5a 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 at python.org -- [] From alexander.belopolsky at gmail.com Wed Feb 1 18:56:06 2017 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 1 Feb 2017 18:56:06 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 1 19:51:46 2017 From: brett at python.org (Brett Cannon) Date: Thu, 02 Feb 2017 00:51:46 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 at gmail.com> wrote: > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 1 19:53:12 2017 From: brett at python.org (Brett Cannon) Date: Thu, 02 Feb 2017 00:53:12 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On Wed, 1 Feb 2017 at 15:45 Ned Deily wrote: > 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/9f889393ab0362229c42bc31056f3ef9735a1d27) > 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/aa82ec527570f8cf1b6ae13037ba6535afe26e5a > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.belopolsky at gmail.com Wed Feb 1 20:13:24 2017 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Wed, 1 Feb 2017 20:13:24 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From soltysh at gmail.com Thu Feb 2 16:20:44 2017 From: soltysh at gmail.com (Maciej Szulik) Date: Thu, 2 Feb 2017 22:20:44 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On Thu, Feb 2, 2017 at 2:13 AM, Alexander Belopolsky < alexander.belopolsky at gmail.com> wrote: > > 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. > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Feb 3 18:24:37 2017 From: brett at python.org (Brett Cannon) Date: Fri, 03 Feb 2017 23:24:37 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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 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). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Fri Feb 3 19:02:43 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 3 Feb 2017 16:02:43 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 From nad at python.org Fri Feb 3 19:06:05 2017 From: nad at python.org (Ned Deily) Date: Fri, 3 Feb 2017 19:06:05 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: <2C8D3884-6DBD-4755-8D4C-14AC96964CA4@python.org> 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? 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 at python.org -- [] From brett at python.org Fri Feb 3 19:16:34 2017 From: brett at python.org (Brett Cannon) Date: Sat, 04 Feb 2017 00:16:34 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: <2C8D3884-6DBD-4755-8D4C-14AC96964CA4@python.org> References: <2C8D3884-6DBD-4755-8D4C-14AC96964CA4@python.org> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Fri Feb 3 19:24:39 2017 From: nad at python.org (Ned Deily) Date: Fri, 3 Feb 2017 19:24:39 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <2C8D3884-6DBD-4755-8D4C-14AC96964CA4@python.org> Message-ID: <7B92DA85-1CD9-46E1-9293-6D4C624F9A0A@python.org> 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. -- Ned Deily nad at python.org -- [] From brett at python.org Fri Feb 3 19:31:01 2017 From: brett at python.org (Brett Cannon) Date: Sat, 04 Feb 2017 00:31:01 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: <7B92DA85-1CD9-46E1-9293-6D4C624F9A0A@python.org> References: <2C8D3884-6DBD-4755-8D4C-14AC96964CA4@python.org> <7B92DA85-1CD9-46E1-9293-6D4C624F9A0A@python.org> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nad at python.org Fri Feb 3 19:35:42 2017 From: nad at python.org (Ned Deily) Date: Fri, 3 Feb 2017 19:35:42 -0500 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On Feb 3, 2017, at 19:02, 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. 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 at python.org -- [] From brett at python.org Fri Feb 3 20:20:50 2017 From: brett at python.org (Brett Cannon) Date: Sat, 04 Feb 2017 01:20:50 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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/31fd4df5e3ade210fbfa39e557095c1516c02c27 for an instance where "#2" didn't link since I didn't have an issue #2 yet, https://github.com/brettcannon/gidgethub/commit/92434150efb27c75a738c3ba37311ea2590952e7 which did link because #2 existed, and https://github.com/brettcannon/gidgethub/commit/d2640d7fa7671049361d24a2c85203c50ce98882 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: > > 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. > > 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 at python.org -- [] > > _______________________________________________ > core-workflow mailing list > core-workflow at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Fri Feb 3 20:22:44 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 3 Feb 2017 17:22:44 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Fri Feb 3 20:32:29 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 3 Feb 2017 17:32:29 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 -- Senthil From brett at python.org Fri Feb 3 20:44:54 2017 From: brett at python.org (Brett Cannon) Date: Sat, 04 Feb 2017 01:44:54 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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-"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From phd at phdru.name Sat Feb 4 05:36:10 2017 From: phd at phdru.name (Oleg Broytman) Date: Sat, 4 Feb 2017 11:36:10 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: <20170204103610.GA8858@phdru.name> 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 at phdru.name Programmers don't die, they just GOSUB without RETURN. From brett at python.org Sun Feb 5 18:08:39 2017 From: brett at python.org (Brett Cannon) Date: Sun, 05 Feb 2017 23:08:39 +0000 Subject: [core-workflow] GitHub migration scheduled for Friday, Feb 10 Message-ID: I plan to start writing a doc covering workflow changes today or tomorrow in preparation for Friday. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Mon Feb 6 00:05:27 2017 From: brett at python.org (Brett Cannon) Date: Mon, 06 Feb 2017 05:05:27 +0000 Subject: [core-workflow] Draft of letter announcing migration Message-ID: I have written up what I will say to python-committers once the migration is complete: https://paper.dropbox.com/doc/CPython-workflow-changes-mx1k8G6M0rg5JLy80F1r6 . Feel free to leave comments if you think there is something I missed (which can include thanking you; this has taken so long I'm sure I have forgotten someone who has done work towards making this happen). -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Mon Feb 6 05:08:25 2017 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 6 Feb 2017 11:08:25 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: <882a62c5-3d03-b8d2-e939-c76a615cdad2@egenix.com> 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/ From soltysh at gmail.com Mon Feb 6 08:04:02 2017 From: soltysh at gmail.com (Maciej Szulik) Date: Mon, 6 Feb 2017 14:04:02 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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. > > 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). >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Mon Feb 6 09:19:51 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 6 Feb 2017 15:19:51 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On 4 February 2017 at 02:44, Brett Cannon wrote: > > > 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-"). 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 at gmail.com | Brisbane, Australia From brett at python.org Mon Feb 6 12:58:18 2017 From: brett at python.org (Brett Cannon) Date: Mon, 06 Feb 2017 17:58:18 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: <7B92DA85-1CD9-46E1-9293-6D4C624F9A0A@python.org> References: <2C8D3884-6DBD-4755-8D4C-14AC96964CA4@python.org> <7B92DA85-1CD9-46E1-9293-6D4C624F9A0A@python.org> Message-ID: 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. > 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/pyspecific.py#L226). 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Mon Feb 6 19:19:37 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Mon, 6 Feb 2017 16:19:37 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 Thanks, Senthil From soltysh at gmail.com Tue Feb 7 05:29:22 2017 From: soltysh at gmail.com (Maciej Szulik) Date: Tue, 7 Feb 2017 11:29:22 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: Message-ID: 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). >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From soltysh at gmail.com Tue Feb 7 05:31:54 2017 From: soltysh at gmail.com (Maciej Szulik) Date: Tue, 7 Feb 2017 11:31:54 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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! -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Tue Feb 7 12:39:57 2017 From: brett at python.org (Brett Cannon) Date: Tue, 07 Feb 2017 17:39:57 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On Tue, 7 Feb 2017 at 02:32 Maciej Szulik wrote: > > 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! > 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. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Tue Feb 7 16:30:40 2017 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 7 Feb 2017 22:30:40 +0100 Subject: [core-workflow] Draft of letter announcing migration References: Message-ID: <20170207223040.1f52114f@fsol> On Mon, 06 Feb 2017 05:05:27 +0000 Brett Cannon wrote: > I have written up what I will say to python-committers once the migration > is complete: > https://paper.dropbox.com/doc/CPython-workflow-changes-mx1k8G6M0rg5JLy80F1r6 . > Feel free to leave comments if you think there is something I missed (which > can include thanking you; this has taken so long I'm sure I have forgotten > someone who has done work towards making this happen). I may have missed something, but I don't see the URL of the GitHub repo in that announcement. Sounds like a useful thing to add :-) Regards Antoine. From brett at python.org Tue Feb 7 16:55:54 2017 From: brett at python.org (Brett Cannon) Date: Tue, 07 Feb 2017 21:55:54 +0000 Subject: [core-workflow] Block direct pushes to the cpython repo? Message-ID: I opened https://github.com/python/core-workflow/issues/16 to track the idea of turning off direct pushes to the git repo after the migration at some point. But immediately both Senthil and Barry voted to say they thought we should just start off on the proper footing and just block direct pushes to begin with. If you have a +1/-1 reaction to this then please add the appropriate reaction to https://github.com/python/core-workflow/issues/16#issue-205987825 (i.e. add a thumbs up or down reaction depending on how you care to vote). If things obviously lean in one way or the other will help me decide how we want to start the repo set as (we can obviously turn it off if it turns out to be a problem). -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Tue Feb 7 19:35:45 2017 From: brett at python.org (Brett Cannon) Date: Wed, 08 Feb 2017 00:35:45 +0000 Subject: [core-workflow] Choosing a label format for cherry-picking reminders Message-ID: Since we are going to need reminders of what versions of Python to cherry-pick a PR into, I figured this was a perfect use of labels. If you want to provide feedback on possible formats for the label, add appropriate reactios to https://github.com/python/core-workflow/issues/17 . -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Wed Feb 8 03:41:39 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 8 Feb 2017 09:41:39 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 at gmail.com | Brisbane, Australia From vadmium+py at gmail.com Wed Feb 8 06:52:37 2017 From: vadmium+py at gmail.com (Martin Panter) Date: Wed, 8 Feb 2017 11:52:37 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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/c64d263ec003f09fe4ebc50912fbe28de96fb2d3 Issue bpo-29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and _PyArg_NoPositional() now are macros. Having both "Issue" and "bpo" there is redundant. It could just be bpo-29460: _PyArg_NoKeywords(), _PyArg_NoStackKeywords() and _PyArg_NoPositional() now are macros. Also, I guess if you restricted the rule to "Issue #NNNN", that may reduce false positives. Modern example of a false positive, with upstream "typing" project references: https://hg.python.org/cpython/rev/794dad4b849f Issue #28556: merge 5 more typing changes from upstream (#340, #344, #348, #349, #350) https://github.com/orsenthil/cpython-migration-test/commit/8840a59 Issue bpo-28556: merge 5 more typing changes from upstream (bpo-340, bpo-344, bpo-348, bpo-349, bpo-350) On the other hand, replacing just #NNNN correctly catches other notations, e.g. to : 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. : ''' Substitute a more readable f-string --HG-- branch : 3.6 ''' I would prefer without this annotation, like the old 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. From ezio.melotti at gmail.com Wed Feb 8 07:43:27 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Wed, 8 Feb 2017 14:43:27 +0200 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 : 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. : ''' Substitute a more readable f-string --HG-- branch : 3.6 ''' I would prefer without this annotation, like the old mirror. Less important (can be fixed afterwards): Probably don't need the legacy-trunk branch. I understand this is just what the 2.7 (and earlier) branches were branched from. But since there was already a separate py3k branch when 2.7 was branched, there is nothing useful in legacy-trunk that is not in 2.7. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Feb 8 12:56:24 2017 From: brett at python.org (Brett Cannon) Date: Wed, 08 Feb 2017 17:56:24 +0000 Subject: [core-workflow] Draft of letter announcing migration In-Reply-To: <20170207223040.1f52114f@fsol> References: <20170207223040.1f52114f@fsol> Message-ID: On Tue, 7 Feb 2017 at 13:31 Antoine Pitrou wrote: > On Mon, 06 Feb 2017 05:05:27 +0000 > Brett Cannon wrote: > > > I have written up what I will say to python-committers once the migration > > is complete: > > > https://paper.dropbox.com/doc/CPython-workflow-changes-mx1k8G6M0rg5JLy80F1r6 > . > > Feel free to leave comments if you think there is something I missed > (which > > can include thanking you; this has taken so long I'm sure I have > forgotten > > someone who has done work towards making this happen). > > I may have missed something, but I don't see the URL of the GitHub repo > in that announcement. Sounds like a useful thing to add :-) > :) Done. Been going to the mirror for so long now it didn't occur to me people might not know where it is. -Brett > > Regards > > Antoine. > > > _______________________________________________ > core-workflow mailing list > core-workflow at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Wed Feb 8 13:03:43 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 8 Feb 2017 10:03:43 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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/75408e7efdbc73a4da435080f23fb0f1194e23b6 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 From brett at python.org Wed Feb 8 13:39:14 2017 From: brett at python.org (Brett Cannon) Date: Wed, 08 Feb 2017 18:39:14 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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/75408e7efdbc73a4da435080f23fb0f1194e23b6 > > 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berker.peksag at gmail.com Wed Feb 8 21:54:49 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Thu, 9 Feb 2017 05:54:49 +0300 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 From ezio.melotti at gmail.com Wed Feb 8 22:43:50 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Thu, 9 Feb 2017 05:43:50 +0200 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On Thu, Feb 9, 2017 at 4:54 AM, Berker Peksa? wrote: > > 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 :) > 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 From rosuav at gmail.com Wed Feb 8 23:28:57 2017 From: rosuav at gmail.com (Chris Angelico) Date: Thu, 9 Feb 2017 15:28:57 +1100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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. ChrisA From brett at python.org Thu Feb 9 00:40:03 2017 From: brett at python.org (Brett Cannon) Date: Thu, 09 Feb 2017 05:40:03 +0000 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Thu Feb 9 00:55:14 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Thu, 9 Feb 2017 07:55:14 +0200 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On Thu, Feb 9, 2017 at 7:40 AM, Brett Cannon wrote: > > > 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. 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. From senthil at uthcode.com Thu Feb 9 01:11:39 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 8 Feb 2017 22:11:39 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On Wed, Feb 8, 2017 at 9:55 PM, Ezio Melotti wrote: > To summarize, are these alternatives correct? yes, that is accurate. From songofacandy at gmail.com Thu Feb 9 01:19:23 2017 From: songofacandy at gmail.com (INADA Naoki) Date: Thu, 9 Feb 2017 15:19:23 +0900 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: > 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. From ncoghlan at gmail.com Thu Feb 9 09:08:13 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 9 Feb 2017 15:08:13 +0100 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: 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 at gmail.com | Brisbane, Australia From senthil at uthcode.com Thu Feb 9 10:22:37 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 9 Feb 2017 07:22:37 -0800 Subject: [core-workflow] Choosing a prefix/label for issue numbers In-Reply-To: References: <3CA04B34-8536-4B41-9F55-8B270A6966E7@python.org> <41E4F1BD-1806-4843-8E19-959C405F5061@python.org> Message-ID: On Wed, Feb 8, 2017 at 10: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. 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 From brett at python.org Thu Feb 9 12:37:10 2017 From: brett at python.org (Brett Cannon) Date: Thu, 09 Feb 2017 17:37:10 +0000 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s Message-ID: +1: Nick, Senthil, Chris +0: ... -0: Martin, Brett -1: Naoki, Berker (Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't a valid vote, so I rounded up for him; I'm personally on the fence so voting conservatively now but can switch that view) If you have an opinion please express them now so Senthil has a chance to test this today before we do the official move tomorrow. Otherwise Senthil and I will make the final decision ourselves. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.ware+pydev at gmail.com Thu Feb 9 12:42:34 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Thu, 9 Feb 2017 11:42:34 -0600 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote: > +1: Nick, Senthil, Chris > +0: ... > -0: Martin, Brett > -1: Naoki, Berker Since we don't get clickable links any way about it, -1 on rewriting commit messages. Too easy to accidentally mess things up for no real benefit. -- Zach From ncoghlan at gmail.com Thu Feb 9 12:52:05 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 9 Feb 2017 18:52:05 +0100 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On 9 February 2017 at 18:42, Zachary Ware wrote: > On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote: >> +1: Nick, Senthil, Chris >> +0: ... >> -0: Martin, Brett >> -1: Naoki, Berker > > Since we don't get clickable links any way about it, -1 on rewriting > commit messages. Too easy to accidentally mess things up for no real > benefit. Rewriting the history means we *do* get clickable links for anyone that wants them, as a distinctive string like "bpo-12345" is amenable to automated conversion into a hyperlink via a client side script in GreaseMonkey or similar. You can't readily do that with "#12345" or even "Issue #12345" because they're too generic. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From zachary.ware+pydev at gmail.com Thu Feb 9 12:59:11 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Thu, 9 Feb 2017 11:59:11 -0600 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan wrote: > On 9 February 2017 at 18:42, Zachary Ware wrote: >> On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote: >>> +1: Nick, Senthil, Chris >>> +0: ... >>> -0: Martin, Brett >>> -1: Naoki, Berker >> >> Since we don't get clickable links any way about it, -1 on rewriting >> commit messages. Too easy to accidentally mess things up for no real >> benefit. > > Rewriting the history means we *do* get clickable links for anyone > that wants them, as a distinctive string like "bpo-12345" is amenable > to automated conversion into a hyperlink via a client side script in > GreaseMonkey or similar. > > You can't readily do that with "#12345" or even "Issue #12345" because > they're too generic. I don't see how we can say they're too generic for a GreaseMonkey script to match, but not for rewriting history. An option that I would be less against would be to, instead of rewriting the actual message, tack '\n\n[bpo-12345]' onto the end of the message. At least that way any misfires would be non-destructive. -- Zach From senthil at uthcode.com Thu Feb 9 13:03:30 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 9 Feb 2017 10:03:30 -0800 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 9:42 AM, Zachary Ware wrote: > Too easy to accidentally mess things up for no real > benefit. Not to sway Zachary's vote. To address the above concern for everyone, the change is restricted only to commit messages and should not effect anything else: https://bitbucket.org/orsenthil/hg-git/commits/75408e7efdbc73a4da435080f23fb0f1194e23b6 * The worst you can get is few false positives. * There are advantages in rewriting the commit message content to suit our new VCS, and that's reason for this discussion. * Finally, we have already tested this once and gathered feedback. We should be testing our final plan one more time before we go for real. From mal at egenix.com Thu Feb 9 13:09:08 2017 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 9 Feb 2017 19:09:08 +0100 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On 09.02.2017 18:42, Zachary Ware wrote: > On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote: >> +1: Nick, Senthil, Chris >> +0: ... >> -0: Martin, Brett >> -1: Naoki, Berker > > Since we don't get clickable links any way about it, -1 on rewriting > commit messages. Too easy to accidentally mess things up for no real > benefit. Agreed. -1 as well. Github may support configuring link REs at some point, so we may then configure things to suit our needs as necessary in the future. Without working links, the rewrite isn't all that useful. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 09 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/ From alexander.belopolsky at gmail.com Thu Feb 9 13:14:22 2017 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 9 Feb 2017 13:14:22 -0500 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 12:37 PM, Brett Cannon wrote: > +1: Nick, Senthil, Chris > +0: ... > -0: Martin, Brett > -1: Naoki, Berker > +1 BTW, not directly related to the issue at hand, but # is a really bad choice for the issue markup because messages with lines that start with # cannot be edited by the standard git tools that remove such lines. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Thu Feb 9 13:14:55 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 9 Feb 2017 19:14:55 +0100 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On 9 February 2017 at 18:59, Zachary Ware wrote: > On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan wrote: >> You can't readily do that with "#12345" or even "Issue #12345" because >> they're too generic. > > I don't see how we can say they're too generic for a GreaseMonkey > script to match, but not for rewriting history. Rewriting the history has a lot more context: Senthil *knows* that his script is reading CPython commit messages. Without the more specific prefix, a GreasemonkeyScript would need to be configured to only run on relevant URLs, which is definitely possible, but would be pretty annoying to set up. > An option that I would be less against would be to, instead of > rewriting the actual message, tack '\n\n[bpo-12345]' onto the end of > the message. At least that way any misfires would be non-destructive. That's actually the way hg.python.org injects the links now: https://hg.python.org/cpython/rev/b07d454e45a2 So +1 from me for appending the references to the old messages rather than modifying them in place. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From alexander.belopolsky at gmail.com Thu Feb 9 13:19:08 2017 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Thu, 9 Feb 2017 13:19:08 -0500 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 12:42 PM, Zachary Ware wrote: > Since we don't get clickable links any way about it, -1 on rewriting > commit messages. > While the default github web interface will not give you clickable links right away, there are plenty of tools that that will. For example, PyCharm allows one to specify an arbitrary regular expression to transform issue labels to tracker links. I would not be surprised that given enough demand github will implement a similar feature. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Thu Feb 9 13:35:18 2017 From: brett at python.org (Brett Cannon) Date: Thu, 09 Feb 2017 18:35:18 +0000 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, 9 Feb 2017 at 10:15 Nick Coghlan wrote: > On 9 February 2017 at 18:59, Zachary Ware > wrote: > > On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan > wrote: > >> You can't readily do that with "#12345" or even "Issue #12345" because > >> they're too generic. > > > > I don't see how we can say they're too generic for a GreaseMonkey > > script to match, but not for rewriting history. > > Rewriting the history has a lot more context: Senthil *knows* that his > script is reading CPython commit messages. > > Without the more specific prefix, a GreasemonkeyScript would need to > be configured to only run on relevant URLs, which is definitely > possible, but would be pretty annoying to set up. > > > An option that I would be less against would be to, instead of > > rewriting the actual message, tack '\n\n[bpo-12345]' onto the end of > > the message. At least that way any misfires would be non-destructive. > > That's actually the way hg.python.org injects the links now: > https://hg.python.org/cpython/rev/b07d454e45a2 > > So +1 from me for appending the references to the old messages rather > than modifying them in place. What if we only did it for the beginning of the first line of the commit message and not the whole body? Senthil had a list in one of his emails of all the possible formats and if they were all anchored with "^" in the regex then the chance of a false-positive is essentially 0. That would give us the equivalent of what we have on hg.python.org but in-place and alleviates any worry of GitHub changing how they do things in the future (at least in terms of the line you see in log output). If people don't like that idea the appending works for me if it isn't difficult for Senthil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Thu Feb 9 13:43:51 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 9 Feb 2017 19:43:51 +0100 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On 9 February 2017 at 19:35, Brett Cannon wrote: > On Thu, 9 Feb 2017 at 10:15 Nick Coghlan wrote: >> That's actually the way hg.python.org injects the links now: >> https://hg.python.org/cpython/rev/b07d454e45a2 >> >> So +1 from me for appending the references to the old messages rather >> than modifying them in place. > > What if we only did it for the beginning of the first line of the commit > message and not the whole body? Senthil had a list in one of his emails of > all the possible formats and if they were all anchored with "^" in the regex > then the chance of a false-positive is essentially 0. That would give us the > equivalent of what we have on hg.python.org but in-place and alleviates any > worry of GitHub changing how they do things in the future (at least in terms > of the line you see in log output). Oh, nice idea. +1 for that approach from me, since it gives the hyperlinkable version even in the commit summary > If people don't like that idea the appending works for me if it isn't > difficult for Senthil. but I'd still prefer this to not having the modified version at all. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From senthil at uthcode.com Thu Feb 9 14:51:42 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 9 Feb 2017 11:51:42 -0800 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan wrote: >> If people don't like that idea the appending works for me if it isn't >> difficult for Senthil. > > but I'd still prefer this to not having the modified version at all. It's not difficult and I am open to these suggestions. I hope we can settle upon something that will serve us well in utility value. If many folks are still apprehensive, not changing is fine with me. It's will be a slight inconvenience with historical commit messages. -- Senthil From brett at python.org Thu Feb 9 15:12:52 2017 From: brett at python.org (Brett Cannon) Date: Thu, 09 Feb 2017 20:12:52 +0000 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, 9 Feb 2017 at 11:51 Senthil Kumaran wrote: > On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan wrote: > >> If people don't like that idea the appending works for me if it isn't > >> difficult for Senthil. > > > > but I'd still prefer this to not having the modified version at all. > > It's not difficult and I am open to these suggestions. I hope we can > settle upon something that will serve us well in utility value. > > If many folks are still apprehensive, not changing is fine with me. > It's will be a slight inconvenience with historical commit messages. > OK, executive decision: let's test a rewrite but only for things that match the regex at the beginning of the commit message (using Senthil's long list of possible formats so we get "bpo-NNNN" and not "Issue bpo-NNNN"). That won't have any false-positives and still gets us consistent issue naming for the whole repo (at least in the commit summary line, but that will also act as a scope to the commit that any ambiguous "#NNNN" numbers apply to bpo). If this test doesn't lead to people being happy we will abandon the idea of any history rewriting for tomorrow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Thu Feb 9 16:12:07 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Thu, 9 Feb 2017 23:12:07 +0200 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 10:12 PM, Brett Cannon wrote: > > > On Thu, 9 Feb 2017 at 11:51 Senthil Kumaran wrote: >> >> On Thu, Feb 9, 2017 at 10:43 AM, Nick Coghlan wrote: >> >> If people don't like that idea the appending works for me if it isn't >> >> difficult for Senthil. >> > >> > but I'd still prefer this to not having the modified version at all. >> >> It's not difficult and I am open to these suggestions. I hope we can >> settle upon something that will serve us well in utility value. >> >> If many folks are still apprehensive, not changing is fine with me. >> It's will be a slight inconvenience with historical commit messages. > > > OK, executive decision: let's test a rewrite but only for things that match > the regex at the beginning of the commit message (using Senthil's long list > of possible formats so we get "bpo-NNNN" and not "Issue bpo-NNNN"). If you only match at the beginning, the regex should also includes keywords like "(fix|clos)(e[sd]). FWIW the bpo issues are currently in range 1000-29515 (the upper bound changes as new issues are created) and the old SF issues are in range 207608-1779871. Both ranges are inclusive, meaning that anything with id <1000 or 29515 < id < 207608 or id > 1779871 is not a valid bpo-issue, anything within those ranges /should/ be a valid bpo issue (there are a few holes in the bpo range and several in the SF range). It probably doesn't matter, but the link added at end of HG commits on hg.p.o was there due to technical problems (trying to linkify the issue id directly was breaking the HTML formatting in some cases). I'm +1 on rewriting (in place or at the end are both fine). @Senthil Ping me on IRC if you need help putting together a regex that includes as many cases as possible without including false positives. > That > won't have any false-positives and still gets us consistent issue naming for > the whole repo (at least in the commit summary line, but that will also act > as a scope to the commit that any ambiguous "#NNNN" numbers apply to bpo). > If this test doesn't lead to people being happy we will abandon the idea of > any history rewriting for tomorrow. > From ericsnowcurrently at gmail.com Thu Feb 9 16:29:15 2017 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Thu, 9 Feb 2017 14:29:15 -0700 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 1:12 PM, Brett Cannon wrote: > OK, executive decision: let's test a rewrite but only for things that match > the regex at the beginning of the commit message (using Senthil's long list > of possible formats so we get "bpo-NNNN" and not "Issue bpo-NNNN"). I'm +1 to this approach. The key thing for me is that we can't go back and do this later, so it's better to play it safe and do the rewrite to bpo-##### as described. I can *imagine* scenarios where we would wish we had re-written the commit messages, but at the point where we will be confident it's a good idea it will already be too later. -eric From zachary.ware+pydev at gmail.com Thu Feb 9 17:20:26 2017 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Thu, 9 Feb 2017 16:20:26 -0600 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 2:12 PM, Brett Cannon wrote: > OK, executive decision: let's test a rewrite but only for things that match > the regex at the beginning of the commit message (using Senthil's long list > of possible formats so we get "bpo-NNNN" and not "Issue bpo-NNNN"). That > won't have any false-positives and still gets us consistent issue naming for > the whole repo (at least in the commit summary line, but that will also act > as a scope to the commit that any ambiguous "#NNNN" numbers apply to bpo). > If this test doesn't lead to people being happy we will abandon the idea of > any history rewriting for tomorrow. Note that matching only the beginning of the message will miss several recent commits like: https://hg.python.org/cpython/rev/7b8df4a5d81d https://hg.python.org/cpython/rev/31342913fb1e https://hg.python.org/cpython/rev/37705f89c72b There is also the issue of multiple issue numbers in a message: https://hg.python.org/cpython/rev/a5538734cc87 https://hg.python.org/cpython/rev/ffc0840762e4 -- Zach From brett at python.org Thu Feb 9 17:45:24 2017 From: brett at python.org (Brett Cannon) Date: Thu, 09 Feb 2017 22:45:24 +0000 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, 9 Feb 2017 at 14:20 Zachary Ware wrote: > On Thu, Feb 9, 2017 at 2:12 PM, Brett Cannon wrote: > > OK, executive decision: let's test a rewrite but only for things that > match > > the regex at the beginning of the commit message (using Senthil's long > list > > of possible formats so we get "bpo-NNNN" and not "Issue bpo-NNNN"). That > > won't have any false-positives and still gets us consistent issue naming > for > > the whole repo (at least in the commit summary line, but that will also > act > > as a scope to the commit that any ambiguous "#NNNN" numbers apply to > bpo). > > If this test doesn't lead to people being happy we will abandon the idea > of > > any history rewriting for tomorrow. > > Note that matching only the beginning of the message will miss several > recent commits like: > > https://hg.python.org/cpython/rev/7b8df4a5d81d > https://hg.python.org/cpython/rev/31342913fb1e > https://hg.python.org/cpython/rev/37705f89c72b Beginning of line would catch these, so using re.MULTILINE would cover those. > > > There is also the issue of multiple issue numbers in a message: > > https://hg.python.org/cpython/rev/a5538734cc87 > https://hg.python.org/cpython/rev/ffc0840762e4 Yep, this will never be perfect, hence it's either best-effort or we simply don't do it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Thu Feb 9 17:49:32 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 10 Feb 2017 00:49:32 +0200 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Fri, Feb 10, 2017 at 12:45 AM, Brett Cannon wrote: > > > On Thu, 9 Feb 2017 at 14:20 Zachary Ware > wrote: >> >> On Thu, Feb 9, 2017 at 2:12 PM, Brett Cannon wrote: >> > OK, executive decision: let's test a rewrite but only for things that >> > match >> > the regex at the beginning of the commit message (using Senthil's long >> > list >> > of possible formats so we get "bpo-NNNN" and not "Issue bpo-NNNN"). That >> > won't have any false-positives and still gets us consistent issue naming >> > for >> > the whole repo (at least in the commit summary line, but that will also >> > act >> > as a scope to the commit that any ambiguous "#NNNN" numbers apply to >> > bpo). >> > If this test doesn't lead to people being happy we will abandon the idea >> > of >> > any history rewriting for tomorrow. >> >> Note that matching only the beginning of the message will miss several >> recent commits like: >> >> https://hg.python.org/cpython/rev/7b8df4a5d81d >> https://hg.python.org/cpython/rev/31342913fb1e >> https://hg.python.org/cpython/rev/37705f89c72b > > > Beginning of line would catch these, so using re.MULTILINE would cover > those. > >> >> >> >> There is also the issue of multiple issue numbers in a message: >> >> https://hg.python.org/cpython/rev/a5538734cc87 >> https://hg.python.org/cpython/rev/ffc0840762e4 > > > Yep, this will never be perfect, hence it's either best-effort or we simply > don't do it. > I'm working with Senthil on it. We don't think it's necessary to limit it to the beginning of the line. Thanks for test cases Zach! From yselivanov.ml at gmail.com Thu Feb 9 17:53:57 2017 From: yselivanov.ml at gmail.com (Yury Selivanov) Date: Thu, 9 Feb 2017 17:53:57 -0500 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: If it's not too late my opinion is `-1`. I agree with MAL. Yury On 2017-02-09 12:37 PM, Brett Cannon wrote: > +1: Nick, Senthil, Chris > +0: ... > -0: Martin, Brett > -1: Naoki, Berker > > (Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't > a valid vote, so I rounded up for him; I'm personally on the fence so > voting conservatively now but can switch that view) > > If you have an opinion please express them now so Senthil has a chance to > test this today before we do the official move tomorrow. Otherwise Senthil > and I will make the final decision ourselves. > > > > _______________________________________________ > core-workflow mailing list > core-workflow at 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 From brett at python.org Thu Feb 9 18:46:07 2017 From: brett at python.org (Brett Cannon) Date: Thu, 09 Feb 2017 23:46:07 +0000 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: As of right now Senthil is (I'm assuming) generating another test repo right now to see the results. If we're happy with the output then we will go with it, else we will skip the rewrite. So you're not too late as in a final decision has been made, but then you could argue you're too early based on how this test goes. :) On Thu, 9 Feb 2017 at 15:00 Yury Selivanov wrote: > If it's not too late my opinion is `-1`. I agree with MAL. > > Yury > > On 2017-02-09 12:37 PM, Brett Cannon wrote: > > +1: Nick, Senthil, Chris > > +0: ... > > -0: Martin, Brett > > -1: Naoki, Berker > > > > (Maciej was positive but didn't say +1 or +0; Martin said -0.5 which > isn't > > a valid vote, so I rounded up for him; I'm personally on the fence so > > voting conservatively now but can switch that view) > > > > If you have an opinion please express them now so Senthil has a chance to > > test this today before we do the official move tomorrow. Otherwise > Senthil > > and I will make the final decision ourselves. > > > > > > > > _______________________________________________ > > core-workflow mailing list > > core-workflow at 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Thu Feb 9 18:51:31 2017 From: barry at python.org (Barry Warsaw) Date: Thu, 9 Feb 2017 18:51:31 -0500 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s References: Message-ID: <20170209185131.4eda4836@subdivisions.wooz.org> I'm generally -1 on rewriting history, but I guess in this case practicality beats purity. If it provides a better user experience, then I'm +0. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From songofacandy at gmail.com Thu Feb 9 19:04:24 2017 From: songofacandy at gmail.com (INADA Naoki) Date: Fri, 10 Feb 2017 09:04:24 +0900 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Fri, Feb 10, 2017 at 2:59 AM, Zachary Ware wrote: > On Thu, Feb 9, 2017 at 11:52 AM, Nick Coghlan wrote: >> On 9 February 2017 at 18:42, Zachary Ware wrote: >>> On Thu, Feb 9, 2017 at 11:37 AM, Brett Cannon wrote: >>>> +1: Nick, Senthil, Chris >>>> +0: ... >>>> -0: Martin, Brett >>>> -1: Naoki, Berker >>> ... > An option that I would be less against would be to, instead of > rewriting the actual message, tack '\n\n[bpo-12345]' onto the end of > the message. At least that way any misfires would be non-destructive. > While I was -1 on rewriting, -0 for this approach. From ezio.melotti at gmail.com Thu Feb 9 19:28:48 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 10 Feb 2017 02:28:48 +0200 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Fri, Feb 10, 2017 at 1:46 AM, Brett Cannon wrote: > As of right now Senthil is (I'm assuming) generating another test repo right > now to see the results. If we're happy with the output then we will go with > it, else we will skip the rewrite. So you're not too late as in a final > decision has been made, but then you could argue you're too early based on > how this test goes. :) > No need to wait, I put together a script that shows the result of the rewriting :) The script checks against roundup, so invalid ids are not converted. I'm currently tweaking it as I find issues, so it's still a bit messy, but this should give you a good idea. Drop the attached script in the root of your cpython clone and run it with: python convcm.py (to see 100 random converted commit messages) python convcm.py csid1 csid2 (to see the specified changeset ids) The script will create an output.html file that shows the before/after. It will also cache the valid ids in a valid_ids.json files. There are still a few ambiguous cases, in particular: * I left "SF", so "SF issue #12345" becomes "SF bpo-12345"; * I left "patch", so "Apply patch #12345" becomes "Apply patch bpo-12345"; Senthil is also testing the conversion using this regex. Best Regards, Ezio Melotti -------------- next part -------------- A non-text attachment was scrubbed... Name: convcm.py Type: text/x-python Size: 1942 bytes Desc: not available URL: From senthil at uthcode.com Thu Feb 9 20:36:53 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 9 Feb 2017 17:36:53 -0800 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 4:28 PM, Ezio Melotti wrote: > No need to wait, I put together a script that shows the result of the > rewriting :) Thank you, Ezio! I and Ezio were working on this today afternoon and agreed that if we do rewrite of various formats issue NNNN to bpo-NNNN then doing it over entire commit message gives much better experience than doing it over the first line. We can judge this by looking at the actual output (from the script that Ezio shared). http://orsenthil.github.io/cpython-hg-to-git/ This picked up 1000 random revisions and added some tricky corner cases that we identified and did the re-write. Please view the output of commit logs converted here http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks better than the status quo. The final decision on this should be Brett's to take. Thank you, Senthil From berker.peksag at gmail.com Fri Feb 10 00:41:18 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Fri, 10 Feb 2017 08:41:18 +0300 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Fri, Feb 10, 2017 at 4:36 AM, Senthil Kumaran wrote: > On Thu, Feb 9, 2017 at 4:28 PM, Ezio Melotti wrote: >> No need to wait, I put together a script that shows the result of the >> rewriting :) > > Thank you, Ezio! > > I and Ezio were working on this today afternoon and agreed that if we > do rewrite of various formats issue NNNN to bpo-NNNN then doing it > over entire commit message gives much better experience than doing it > over the first line. > > > We can judge this by looking at the actual output (from the script > that Ezio shared). > > http://orsenthil.github.io/cpython-hg-to-git/ > > This picked up 1000 random revisions and added some tricky corner > cases that we identified and did the re-write. > > Please view the output of commit logs converted here > http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks > better than the status quo. Thanks, Senthil and Ezio! Looks pretty good to me. I noticed some edge cases: * -46692:46918 merged from branch aimacintyre-sf1454481 +46692:46918 merged from branch aimacintyre-bpo-1454481 * -SF bug #1012315: weakref.WeakValueDictionary should override .has_key() +SF bpo-1012315: weakref.WeakValueDictionary should override .has_key() -Backport checkin: Fix typo (from SF bug #1086127). +Backport checkin: Fix typo (from SF bpo-1086127). - used on BTree databases. [SF bug id 788421] + used on BTree databases. [SF bpo-788421] Is it possible to replace 'SF bug #NNNN' with 'bpo-NNNN'? * -SF 798269: bug fix for doctest (sf bug id: 798254 +bpo-798269: bug fix for doctest (sf bug id: 798254 'bug id NNNN' matches but not 'bug id: NNNN'. * -Resolves SF bugs 697989, 697988, 697986. +Resolves SF bpo-697989, 697988, 697986. This doesn't look like a common case and we can just ignore it :) --Berker From mariatta.wijaya at gmail.com Fri Feb 10 00:55:08 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Thu, 9 Feb 2017 21:55:08 -0800 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: Overall looks good :) Thanks, Senthil and Ezio. This seems like another edge case: [*4bcfb9dc57e0*]: bug #133283, #477728, #483789, #490573 [*4bcfb9dc57e0*]: bug #133283, *bpo-477728*, *bpo-483789*, *bpo-490573* Mariatta Wijaya -------------- next part -------------- An HTML attachment was scrubbed... URL: From senthil at uthcode.com Fri Feb 10 01:12:14 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Thu, 9 Feb 2017 22:12:14 -0800 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 9:55 PM, Mariatta Wijaya wrote: > This seems like another edge case: > > [4bcfb9dc57e0]: bug #133283, #477728, #483789, #490573 > > [4bcfb9dc57e0]: bug #133283, bpo-477728, bpo-483789, bpo-490573 It did! The first one is not a valid b.p.o id. From ezio.melotti at gmail.com Fri Feb 10 01:37:45 2017 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Fri, 10 Feb 2017 08:37:45 +0200 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: Attached an updated version of the script with inline unified diffs, and update regex. If you run the script and find other problems, send me the cs id and I'll look into it before the conversion. On Fri, Feb 10, 2017 at 7:41 AM, Berker Peksa? wrote: > On Fri, Feb 10, 2017 at 4:36 AM, Senthil Kumaran wrote: >> On Thu, Feb 9, 2017 at 4:28 PM, Ezio Melotti wrote: >>> No need to wait, I put together a script that shows the result of the >>> rewriting :) >> >> Thank you, Ezio! >> >> I and Ezio were working on this today afternoon and agreed that if we >> do rewrite of various formats issue NNNN to bpo-NNNN then doing it >> over entire commit message gives much better experience than doing it >> over the first line. >> >> >> We can judge this by looking at the actual output (from the script >> that Ezio shared). >> >> http://orsenthil.github.io/cpython-hg-to-git/ >> >> This picked up 1000 random revisions and added some tricky corner >> cases that we identified and did the re-write. >> >> Please view the output of commit logs converted here >> http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks >> better than the status quo. > > Thanks, Senthil and Ezio! Looks pretty good to me. I noticed some edge cases: > > * -46692:46918 merged from branch aimacintyre-sf1454481 > +46692:46918 merged from branch aimacintyre-bpo-1454481 > It's a branch name, so it shouldn't be changed, but it actually refers to a valid issue id. This is now fixed. > * -SF bug #1012315: weakref.WeakValueDictionary should override .has_key() > +SF bpo-1012315: weakref.WeakValueDictionary should override .has_key() > > -Backport checkin: Fix typo (from SF bug #1086127). > +Backport checkin: Fix typo (from SF bpo-1086127). > > - used on BTree databases. [SF bug id 788421] > + used on BTree databases. [SF bpo-788421] > > Is it possible to replace 'SF bug #NNNN' with 'bpo-NNNN'? > I had intentionally left it for these cases, but thinking about it, removing SF might actually be a good idea, since it might be confusing and it's already possible to distinguish them from the id. This is now fixed. > * -SF 798269: bug fix for doctest (sf bug id: 798254 > +bpo-798269: bug fix for doctest (sf bug id: 798254 > > 'bug id NNNN' matches but not 'bug id: NNNN'. > There are a few commit messages with this structure. I thought the id was the same but at least in this case they are different (and both valid). Regardless, it was an easy fix, so I updated the regex. > * -Resolves SF bugs 697989, 697988, 697986. > +Resolves SF bpo-697989, 697988, 697986. > > This doesn't look like a common case and we can just ignore it :) > Yes, I didn't bother fixing this, also because it's not as trivial as the other fixes. > --Berker -------------- next part -------------- A non-text attachment was scrubbed... Name: convcm.py Type: text/x-python Size: 2409 bytes Desc: not available URL: From senthil at uthcode.com Fri Feb 10 09:00:08 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 10 Feb 2017 06:00:08 -0800 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 5:36 PM, Senthil Kumaran wrote: > Please view the output of commit logs converted here > http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks > better than the status quo. In addition to the random sampling of the commit logs, here is the complete repo converted while the commit message re-write: https://github.com/orsenthil/cpython-migration-test3 Both commit log samples and the repo conversion looks good to me And I am in favor of going ahead with this approach. +1 as it was previously too. Since seeing the commit log conversion yesterday, I suspect more people would be +1 one. If any of you were -1 yesterday and you changed your mind after seeing the results, please take chance to explicitly toggle your vote. -- Senthil From berker.peksag at gmail.com Fri Feb 10 09:12:39 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Fri, 10 Feb 2017 17:12:39 +0300 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Fri, Feb 10, 2017 at 5:00 PM, Senthil Kumaran wrote: > If any of you were -1 yesterday and you changed your mind after seeing > the results, please take chance to explicitly toggle your vote. Count me as +1. --Berker From mariatta.wijaya at gmail.com Fri Feb 10 10:07:38 2017 From: mariatta.wijaya at gmail.com (Mariatta Wijaya) Date: Fri, 10 Feb 2017 07:07:38 -0800 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: +1 On Feb 10, 2017 6:00 AM, "Senthil Kumaran" wrote: > On Thu, Feb 9, 2017 at 5:36 PM, Senthil Kumaran > wrote: > > Please view the output of commit logs converted here > > http://orsenthil.github.io/cpython-hg-to-git/ and see if it looks > > better than the status quo. > > In addition to the random sampling of the commit logs, here is the > complete repo converted > while the commit message re-write: > > https://github.com/orsenthil/cpython-migration-test3 > > Both commit log samples and the repo conversion looks good to me > And I am in favor of going ahead with this approach. +1 as it was > previously too. > > Since seeing the commit log conversion yesterday, I suspect more > people would be +1 one. > > If any of you were -1 yesterday and you changed your mind after seeing > the results, please take chance to explicitly toggle your vote. > -- > Senthil > _______________________________________________ > core-workflow mailing list > core-workflow at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From songofacandy at gmail.com Fri Feb 10 10:08:39 2017 From: songofacandy at gmail.com (INADA Naoki) Date: Sat, 11 Feb 2017 00:08:39 +0900 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: > > If any of you were -1 yesterday and you changed your mind after seeing > the results, please take chance to explicitly toggle your vote. +1 for go ahead, not stop migration. From stephane at wirtel.be Fri Feb 10 10:11:31 2017 From: stephane at wirtel.be (Stephane Wirtel) Date: Fri, 10 Feb 2017 16:11:31 +0100 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: <56503AD6-A564-4560-8C66-90B53485C789@wirtel.be> +1 On 10 Feb 2017, at 16:08, INADA Naoki wrote: >> >> If any of you were -1 yesterday and you changed your mind after seeing >> the results, please take chance to explicitly toggle your vote. > > +1 for go ahead, not stop migration. > _______________________________________________ > core-workflow mailing list > core-workflow at 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 From soltysh at gmail.com Fri Feb 10 11:05:39 2017 From: soltysh at gmail.com (Maciej Szulik) Date: Fri, 10 Feb 2017 17:05:39 +0100 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Thu, Feb 9, 2017 at 6:37 PM, Brett Cannon wrote: > (Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't > a valid vote, so I rounded up for him; I'm personally on the fence so > voting conservatively now but can switch that view) > Count me as +1 on this one, I'll be more explicit next time :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Feb 10 12:51:22 2017 From: brett at python.org (Brett Cannon) Date: Fri, 10 Feb 2017 17:51:22 +0000 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: In the end I decided *NOT* to do the history mutation/rewrite basically because I didn't discuss this with python-committers ahead of time (so it's entirely my fault this didn't go forward). The history of this repo -- along with the code -- is collectively owned by all of the people who have contributed to it. The idea of mutating the history like this was not discussed with the stakeholders/contributors of that history ahead of time and thus I don't feel it is my place to unilaterally muck with it without having a proper discussion ahead of time (I unfortunately didn't have this thought until this morning). While I realize I have been given the rights to change our workflow, none of these changes are permanent (as our regular changes to it show :) . But changing the history is permanent and thus a much heftier thing to do with the dictatorial powers I have for this migration. Had I thought to reach out ahead of time then it's possible I could have gotten the permission necessary. But since leaving this as-is doesn't hurt anything (thanks to GH doing the linking eagerly and thus not picking up any of the issue numbers that pre-exist), I felt it was better to err on the side of caution and not upset people by springing this on them. Obviously a huge thanks to Senthil and Ezio for giving this a go. The regex will be useful for anyone who wants to write a browser plug-in to add the automatic linking so I don't view the work as wasted. On Fri, 10 Feb 2017 at 08:06 Maciej Szulik wrote: > On Thu, Feb 9, 2017 at 6:37 PM, Brett Cannon wrote: > > (Maciej was positive but didn't say +1 or +0; Martin said -0.5 which isn't > a valid vote, so I rounded up for him; I'm personally on the fence so > voting conservatively now but can switch that view) > > > Count me as +1 on this one, I'll be more explicit next time :) > > > _______________________________________________ > core-workflow mailing list > core-workflow at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Feb 10 12:52:14 2017 From: brett at python.org (Brett Cannon) Date: Fri, 10 Feb 2017 17:52:14 +0000 Subject: [core-workflow] The migration has started Message-ID: We are hanging out in #python-dev on Freenode if you care to swing by while we work on things. I also created https://trello.com/b/S5WbJfjP/github-migration to track things that I would like to see happen today. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane at wirtel.be Fri Feb 10 12:53:57 2017 From: stephane at wirtel.be (Stephane Wirtel) Date: Fri, 10 Feb 2017 18:53:57 +0100 Subject: [core-workflow] The migration has started In-Reply-To: References: Message-ID: <4A20B2E5-4919-4925-9286-069A4005BCC9@wirtel.be> Good job, could I offer you a beer at PyconUS ? > On 10 Feb 2017, at 18:52, Brett Cannon wrote: > > We are hanging out in #python-dev on Freenode if you care to swing by while we work on things. I also created https://trello.com/b/S5WbJfjP/github-migration to track things that I would like to see happen today. > _______________________________________________ > core-workflow mailing list > core-workflow at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berker.peksag at gmail.com Fri Feb 10 13:08:51 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Fri, 10 Feb 2017 21:08:51 +0300 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Fri, Feb 10, 2017 at 8:51 PM, Brett Cannon wrote: > In the end I decided NOT to do the history mutation/rewrite basically > because I didn't discuss this with python-committers ahead of time (so it's > entirely my fault this didn't go forward). The history of this repo -- along > with the code -- is collectively owned by all of the people who have > contributed to it. The idea of mutating the history like this was not > discussed with the stakeholders/contributors of that history ahead of time > and thus I don't feel it is my place to unilaterally muck with it without > having a proper discussion ahead of time (I unfortunately didn't have this > thought until this morning). While I realize I have been given the rights to > change our workflow, none of these changes are permanent (as our regular > changes to it show :) . But changing the history is permanent and thus a > much heftier thing to do with the dictatorial powers I have for this > migration. > > Had I thought to reach out ahead of time then it's possible I could have > gotten the permission necessary. But since leaving this as-is doesn't hurt > anything (thanks to GH doing the linking eagerly and thus not picking up any > of the issue numbers that pre-exist), I felt it was better to err on the > side of caution and not upset people by springing this on them. > > Obviously a huge thanks to Senthil and Ezio for giving this a go. The regex > will be useful for anyone who wants to write a browser plug-in to add the > automatic linking so I don't view the work as wasted. +1, I've already started to write an extension and I'm converting the regex to JS flavor now so thanks again Senthil and Ezio! --Berker From brett at python.org Fri Feb 10 13:21:02 2017 From: brett at python.org (Brett Cannon) Date: Fri, 10 Feb 2017 18:21:02 +0000 Subject: [core-workflow] The migration has started In-Reply-To: <4A20B2E5-4919-4925-9286-069A4005BCC9@wirtel.be> References: <4A20B2E5-4919-4925-9286-069A4005BCC9@wirtel.be> Message-ID: On Fri, 10 Feb 2017 at 09:54 Stephane Wirtel wrote: > Good job, could I offer you a beer at PyconUS ? > Hold the thanks until this has actually finished and worked. :) And thanks for the offer of a beer but I don't drink. I'll accept orange juice, root beer, or Canada Dry, though. :) -Brett > > On 10 Feb 2017, at 18:52, Brett Cannon wrote: > > We are hanging out in #python-dev on Freenode if you care to swing by > while we work on things. I also created > https://trello.com/b/S5WbJfjP/github-migration to track things that I > would like to see happen today. > > _______________________________________________ > core-workflow mailing list > core-workflow at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Feb 10 18:25:42 2017 From: brett at python.org (Brett Cannon) Date: Fri, 10 Feb 2017 23:25:42 +0000 Subject: [core-workflow] Migration is done! Message-ID: A massive thank you to everyone who helped with this. It has been a long road but we finally reached the end of it! As for what's next, I think getting Misc/NEWS straightened out and then getting cherry-picking PRs automated are the next important items. As always https://github.com/python/core-workflow/issues has the current ideas on how to improve our workflow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sat Feb 11 04:19:10 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 11 Feb 2017 10:19:10 +0100 Subject: [core-workflow] Migration is done! In-Reply-To: References: Message-ID: On 11 February 2017 at 00:25, Brett Cannon wrote: > A massive thank you to everyone who helped with this. It has been a long > road but we finally reached the end of it! Thanks once again to you and everyone else involved! Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From berker.peksag at gmail.com Sat Feb 11 07:03:33 2017 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Sat, 11 Feb 2017 15:03:33 +0300 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On Fri, Feb 10, 2017 at 9:08 PM, Berker Peksa? wrote: > +1, I've already started to write an extension and I'm converting the > regex to JS flavor now so thanks again Senthil and Ezio! Just an FYI, first version of the extension can be found at https://github.com/berkerpeksag/cpython-bpo-linkify It's not perfect, but it does its job for now :) Feel free send bug reports, suggestions and pull requests. --Berker From ncoghlan at gmail.com Sat Feb 11 07:39:32 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 11 Feb 2017 13:39:32 +0100 Subject: [core-workflow] Final chance to express opinion on history rewrite for issue #s In-Reply-To: References: Message-ID: On 11 February 2017 at 13:03, Berker Peksa? wrote: > On Fri, Feb 10, 2017 at 9:08 PM, Berker Peksa? wrote: >> +1, I've already started to write an extension and I'm converting the >> regex to JS flavor now so thanks again Senthil and Ezio! > > Just an FYI, first version of the extension can be found at > https://github.com/berkerpeksag/cpython-bpo-linkify It's not perfect, > but it does its job for now :) Feel free send bug reports, suggestions > and pull requests. Nice! Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From mal at egenix.com Sat Feb 11 08:15:52 2017 From: mal at egenix.com (M.-A. Lemburg) Date: Sat, 11 Feb 2017 14:15:52 +0100 Subject: [core-workflow] Migration is done! In-Reply-To: References: Message-ID: <908965ce-3fb5-a530-52be-d3929ba7c4fc@egenix.com> On 11.02.2017 10:19, Nick Coghlan wrote: > On 11 February 2017 at 00:25, Brett Cannon wrote: >> A massive thank you to everyone who helped with this. It has been a long >> road but we finally reached the end of it! > > Thanks once again to you and everyone else involved! A big thank you from me as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 11 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/ From stephane at wirtel.be Sun Feb 12 13:10:23 2017 From: stephane at wirtel.be (Stephane Wirtel) Date: Sun, 12 Feb 2017 19:10:23 +0100 Subject: [core-workflow] The migration has started In-Reply-To: References: <4A20B2E5-4919-4925-9286-069A4005BCC9@wirtel.be> Message-ID: <20170212181023.nfsqredjofzpka2q@sg1> On 02/10, Brett Cannon wrote: >On Fri, 10 Feb 2017 at 09:54 Stephane Wirtel wrote: > >> Good job, could I offer you a beer at PyconUS ? >> > >Hold the thanks until this has actually finished and worked. :) Finished and works fine ;-) > >And thanks for the offer of a beer but I don't drink. I'll accept orange >juice, root beer, or Canada Dry, though. :) Noted, Thanks for your job, now we can play with GitHub. Stephane > >-Brett > > >> >> On 10 Feb 2017, at 18:52, Brett Cannon wrote: >> >> We are hanging out in #python-dev on Freenode if you care to swing by >> while we work on things. I also created >> https://trello.com/b/S5WbJfjP/github-migration to track things that I >> would like to see happen today. >> >> _______________________________________________ >> core-workflow mailing list >> core-workflow at 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 >> >> -- St?phane Wirtel - http://wirtel.be - @matrixise From barry at python.org Thu Feb 16 12:35:20 2017 From: barry at python.org (Barry Warsaw) Date: Thu, 16 Feb 2017 12:35:20 -0500 Subject: [core-workflow] codecov.io on PRs feedback Message-ID: <20170216123520.7cd66bc4@subdivisions.wooz.org> Hey cool, I've just submitted my first PR against GH, and it's *so* nice to be able to use git, I might have to do this more often . https://github.com/python/cpython/pull/138 But I have questions about the coverage reports. In bbdef4c, coverage failed because my diff wasn't 100% covered, and the module itself was missing some coverage in code I didn't touch. If you click on the red X next to that commit, you can see the codecov/patch report 94.73% of diff hit. It's expected that some lines may be missed, due to underlying platform support, so the natural thing would be to say so in the code. I.e. suppress some misses so coverage doesn't false positive. This leads to questions: * How is codecov.io actually performing coverage? It seems difficult to find out exactly based on their documentation, and python/cpython's .codecov.yml doesn't reveal any details. Over in #python-dev, nedbat guessed it would be coverage.py (big surprise! :), and that would both make sense and be great, since it's a well-known and well-loved tool. * On that guess, I figured I'd add a few #pragmas for lines which are okay not to be covered. I pushed the new commit and didn't see a codecov.io failure so I thought that did the trick, but I'm actually not so sure. If you look at the above PR, you can see that commit bbdef4c has a red X, clicking on which gives you details that codecov/patch failed but travis-ci/pr succeeded. However, if you hover over the green check next to ccefb3a, all you see is that the travis-ci/pr check succeeded. There's no indication that coverage actually ran at all on ccefb3a. That doesn't make sense to me. * How can you run the same coverage tests locally? It's hard to know, given the apparent dearth of details from codecov.io. The top-level Makefile does have a `coverage` target, but that's a different thing. It would be nice if you didn't have to push a new commit just to see if you've fixed your coverage issues. There needs to be a local way to run the same tests. As I'm writing this, suddenly ccefb3a gained another check! So it seems like codecov.io is quite delayed in reporting its coverage, and the PR results can be misleading in the meantime, because it only reports that there is 1 check until codecov.io completes. I would prefer to see a yellow dot (i.e. the test is still running). Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From bussonniermatthias at gmail.com Thu Feb 16 13:09:32 2017 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Thu, 16 Feb 2017 10:09:32 -0800 Subject: [core-workflow] codecov.io on PRs feedback In-Reply-To: <20170216123520.7cd66bc4@subdivisions.wooz.org> References: <20170216123520.7cd66bc4@subdivisions.wooz.org> Message-ID: On Thu, Feb 16, 2017 at 9:35 AM, Barry Warsaw wrote: > Hey cool, I've just submitted my first PR against GH, and it's *so* nice to be > able to use git, I might have to do this more often . > > https://github.com/python/cpython/pull/138 > > But I have questions about the coverage reports. In bbdef4c, coverage failed > because my diff wasn't 100% covered, and the module itself was missing some > coverage in code I didn't touch. If you click on the red X next to that > commit, you can see the codecov/patch report 94.73% of diff hit. > > It's expected that some lines may be missed, due to underlying platform > support, so the natural thing would be to say so in the code. I.e. suppress > some misses so coverage doesn't false positive. This leads to questions: > > * How is codecov.io actually performing coverage? It seems difficult to find > out exactly based on their documentation, and python/cpython's .codecov.yml > doesn't reveal any details. Over in #python-dev, nedbat guessed it would be > coverage.py (big surprise! :), and that would both make sense and be great, > since it's a well-known and well-loved tool. Travis CI is doing coverage, and it pushes coverage.xml to codecov.io. Codecov will "just" aggregate coverage report from different travis-ci matrix entries to get the complete coverage. You can push coverage to codecov.io from your local machine, but that's painful. > * On that guess, I figured I'd add a few #pragmas for lines which are okay not > to be covered. I pushed the new commit and didn't see a codecov.io failure > so I thought that did the trick, but I'm actually not so sure. If you look > at the above PR, you can see that commit bbdef4c has a red X, clicking on > which gives you details that codecov/patch failed but travis-ci/pr > succeeded. > > However, if you hover over the green check next to ccefb3a, all you see is > that the travis-ci/pr check succeeded. There's no indication that coverage > actually ran at all on ccefb3a. That doesn't make sense to me. that's because Codecov is triggered and set the pending/failed/success status only once travis push the first coverage report. GitHub does not trigger codecov. But I think you figured it out with your bottom comment. I agree I got confused as well. I think that might be due to coverage being only ran on "Allow failure" of travis, so the travis green check appears before travis is actually done computing coverage. > > * How can you run the same coverage tests locally? It's hard to know, given > the apparent dearth of details from codecov.io. The top-level Makefile does > have a `coverage` target, but that's a different thing. It would be nice if > you didn't have to push a new commit just to see if you've fixed your > coverage issues. There needs to be a local way to run the same tests. That I'm usure. I would just strongly recommend codecov browser extension: https://github.com/codecov/support/wiki/Browser-Extension They add an overlay in the github UI that color the line numbers red/green depending on coverage. (PR diff and file browser) so you basically never have to go to the codecov website. [1] > > As I'm writing this, suddenly ccefb3a gained another check! So it seems like > codecov.io is quite delayed in reporting its coverage, and the PR results can > be misleading in the meantime, because it only reports that there is 1 check > until codecov.io completes. >I would prefer to see a yellow dot (i.e. the test > is still running). Agreed, I think we have to figure out how to have tests working with COVERAGE=True. One possibility might be to push an empty coverage report on a fast branch. Docs ? Cheers, -- M [1]: I'd love a similar plugin for vim if one of you know one. From barry at python.org Thu Feb 16 14:36:56 2017 From: barry at python.org (Barry Warsaw) Date: Thu, 16 Feb 2017 14:36:56 -0500 Subject: [core-workflow] codecov.io on PRs feedback References: <20170216123520.7cd66bc4@subdivisions.wooz.org> Message-ID: <20170216143656.5003b9d0@subdivisions.wooz.org> On Feb 16, 2017, at 10:09 AM, Matthias Bussonnier wrote: >Travis CI is doing coverage, and it pushes coverage.xml to codecov.io. >Codecov will "just" aggregate coverage report from different travis-ci matrix >entries to get the complete coverage. You can push coverage to codecov.io >from your local machine, but that's painful. Thanks! This was the missing ingredient. The .travis.hml encapsulates exactly how the coverage integration works. It probably wouldn't be too hard to throw the appropriate before_script/script commands in a script or Makefile target so folks could locally just do "make codecov" or some such (there's already a "make coverage" but it doesn't do what you think it does). >that's because Codecov is triggered and set the pending/failed/success status >only once travis push the first coverage report. GitHub does not trigger >codecov. But I think you figured it out with your bottom comment. Yep. As it turns out, the Developers Guide does talk about coverage: https://docs.python.org/devguide/coverage.html but the .travis.yml gets around some of the problems by using a venv. >That I'm usure. I would just strongly recommend codecov browser extension: >https://github.com/codecov/support/wiki/Browser-Extension > >They add an overlay in the github UI that color the line numbers red/green >depending on coverage. (PR diff and file browser) so you basically never >have to go to the codecov website. [1] That's fine. What I really want is to be able to run coverage locally to see what the results would be once I push my branch so I can fix anything obvious beforehand. I'm okay with going to codecov.io if there are any unexpected coverage regressions. One of the packages that I've grown very fond of is diff_cover. It provides a very nice way to see coverage of just your delta. In my projects, I fail CI if diff_cover reports < 100% even if the overall project isn't at 100% yet. That way, I know all new code is covered, and I can implement a ratchet for existing code. codecov.io does something diff_cover like. >>I would prefer to see a yellow dot (i.e. the test is still running). > >Agreed, I think we have to figure out how to have tests working with >COVERAGE=True. One possibility might be to push an empty coverage report on >a fast branch. Docs ? It would be worth experimenting with. Thanks for the useful information! Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From barry at python.org Fri Feb 17 17:39:15 2017 From: barry at python.org (Barry Warsaw) Date: Fri, 17 Feb 2017 17:39:15 -0500 Subject: [core-workflow] self-approving pull requests Message-ID: <20170217173915.2c9f3fdd@subdivisions.wooz.org> I submitted PR#138 on bpo-22807. I got a nice review from a community member and made a small change. All checks have passed. But now I'm stuck and I'm impatient. ;) The change is small enough and I'm happy with it, and I could patiently wait for another core dev to approve it, but in the likely case that no one else is interested in the bug, I'd like to be able to self-approve and accept it. This of course is described as my right in the devguide, along with the responsibility to watch the buildbots and revert the change if there are any problems with it. But it seems like I cannot do that through the GH UI. Right now I'm seeing (X) Review required (?) All checks have passed (X) Merge is blocked There seems to be no way to self-approve the PR. If I go to 'Files changed' tab and click on 'Review changes', both Approve and Request changes is dimmed. I can only comment on my own PR. I can understand why we might want to prohibit self-approvals, but that's also a regression in the permissions and rights of core developers. I also think it's counterproductive since without that I might have to go begging for a review approval before the branch can land. Is this intentional or an oversight? (As an owner of the project, I took a quick look at the project settings and couldn't find a control for this, but I know other GH projects I contribute to support self-approval.) Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From donald at stufft.io Fri Feb 17 18:24:54 2017 From: donald at stufft.io (Donald Stufft) Date: Fri, 17 Feb 2017 18:24:54 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <20170217173915.2c9f3fdd@subdivisions.wooz.org> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> Message-ID: <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> We turned on require code review for the PR, though at the time I *thought* it still allowed you to approve your own PR. Apparently that was wrong. Brett was the one to actually make the decision to do it and turned it on, so I don?t know if he knew that it didn?t allow people to self-approve or not. The impetus to do this was to make sure that all changes went through the PR process and folks didn?t directly push to `master`. So our choices at this time are: 1) Leave it requiring a review from someone else with write or admin permissions on the repository, which will continue to require a PR. 2) Turn it off, but turn on requiring status checks which will still effectively require a PR (there is one way around this, but it is so convoluted nobody would be able to do it by accident, and things still get tested anyways). 3) Turn them both off, and just tell people not to push to `master` directly and always go through the PR process. Personally I think that (2) is a good option if our test suite is stable on Travis now. We *want* to make core contributors to generally go through the same process as non-core contributors in order to better expose pain points introduced by our process so we can find them and fix them. Although arguably reviewer bandwidth is a pain point in our process I think that it might be special enough to just switch to the required status check instead. > On Feb 17, 2017, at 5:39 PM, Barry Warsaw wrote: > > I submitted PR#138 on bpo-22807. I got a nice review from a community member > and made a small change. All checks have passed. > > But now I'm stuck and I'm impatient. ;) > > The change is small enough and I'm happy with it, and I could patiently wait > for another core dev to approve it, but in the likely case that no one else is > interested in the bug, I'd like to be able to self-approve and accept it. > This of course is described as my right in the devguide, along with the > responsibility to watch the buildbots and revert the change if there are any > problems with it. > > But it seems like I cannot do that through the GH UI. Right now I'm seeing > > (X) Review required > (?) All checks have passed > (X) Merge is blocked > > There seems to be no way to self-approve the PR. If I go to 'Files changed' > tab and click on 'Review changes', both Approve and Request changes is > dimmed. I can only comment on my own PR. > > I can understand why we might want to prohibit self-approvals, but that's also > a regression in the permissions and rights of core developers. I also think > it's counterproductive since without that I might have to go begging for a > review approval before the branch can land. > > Is this intentional or an oversight? > > (As an owner of the project, I took a quick look at the project settings and > couldn't find a control for this, but I know other GH projects I contribute to > support self-approval.) > > Cheers, > -Barry > > _______________________________________________ > core-workflow mailing list > core-workflow at 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 ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Fri Feb 17 18:32:37 2017 From: barry at python.org (Barry Warsaw) Date: Fri, 17 Feb 2017 18:32:37 -0500 Subject: [core-workflow] self-approving pull requests References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> Message-ID: <20170217183237.79e621c9@subdivisions.wooz.org> On Feb 17, 2017, at 06:24 PM, Donald Stufft wrote: >2) Turn it off, but turn on requiring status checks which will still >effectively require a PR (there is one way around this, but it is so >convoluted nobody would be able to do it by accident, and things still get >tested anyways). I do like requiring PRs, prohibiting direct pushes to master, feeling non-core contributor pain points, and getting reviews. :) And sometimes it makes sense to actually get an ack from another core contributor in order to land a change, but I think we need to mostly leave that to the discretion of the core contributor. As you say, reviewer bandwidth is a bottleneck (something that I'm personally going to try to help with now that we're on GH), so at least for now, I agree that #2 makes for a good choice. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From senthil at uthcode.com Fri Feb 17 18:42:33 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 17 Feb 2017 15:42:33 -0800 Subject: [core-workflow] self-approving pull requests In-Reply-To: <20170217183237.79e621c9@subdivisions.wooz.org> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <20170217183237.79e621c9@subdivisions.wooz.org> Message-ID: On Fri, Feb 17, 2017 at 3:32 PM, Barry Warsaw wrote: > As you say, reviewer bandwidth is a bottleneck Would anyone consider "Requiring a review from another core-developer" is actually a helpful thing? The positives I see are: 1) Forcing other developers with commit rights to act soon and review each other's code more often. 2) As a result of 1, the developers are incentivized to stay involved either in reviews, by reading code and subsequently will be fast in contributing code. For me, I am +1 in staying this way and I don't mind if we think that 'review bottleneck' needs to be tackled by allowing core-dev to commit his own code without another view. -- Senthil From senthil at uthcode.com Fri Feb 17 18:45:06 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 17 Feb 2017 15:45:06 -0800 Subject: [core-workflow] self-approving pull requests In-Reply-To: <20170217173915.2c9f3fdd@subdivisions.wooz.org> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> Message-ID: On Fri, Feb 17, 2017 at 2:39 PM, Barry Warsaw wrote: > > But now I'm stuck and I'm impatient. ;) No more. :) I spent time reading the bug, understanding the comments, reviewing the code, and then toggled my approval. The later action was a helpful thing for "me", in addition to being helpful to you to commit the code. If you had already committed, perhaps I might not have taken those steps until I had a need to. -- Senthil From senthil at uthcode.com Fri Feb 17 18:45:06 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Fri, 17 Feb 2017 15:45:06 -0800 Subject: [core-workflow] self-approving pull requests In-Reply-To: <20170217173915.2c9f3fdd@subdivisions.wooz.org> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> Message-ID: On Fri, Feb 17, 2017 at 2:39 PM, Barry Warsaw wrote: > > But now I'm stuck and I'm impatient. ;) No more. :) I spent time reading the bug, understanding the comments, reviewing the code, and then toggled my approval. The later action was a helpful thing for "me", in addition to being helpful to you to commit the code. If you had already committed, perhaps I might not have taken those steps until I had a need to. -- Senthil From donald at stufft.io Fri Feb 17 18:50:10 2017 From: donald at stufft.io (Donald Stufft) Date: Fri, 17 Feb 2017 18:50:10 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <20170217183237.79e621c9@subdivisions.wooz.org> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <20170217183237.79e621c9@subdivisions.wooz.org> Message-ID: <76033B71-0B21-41D9-85A2-3861BCAA8331@stufft.io> https://github.com/python/core-workflow/issues/32 might help as well. Sent from my iPhone > On Feb 17, 2017, at 6:32 PM, Barry Warsaw wrote: > > As you say, reviewer bandwidth is a bottleneck (something that I'm personally > going to try to help with now that we're on GH), so at least for now, I agree > that #2 makes for a good choice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Sat Feb 18 15:26:12 2017 From: barry at python.org (Barry Warsaw) Date: Sat, 18 Feb 2017 15:26:12 -0500 Subject: [core-workflow] self-approving pull requests References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> Message-ID: <20170218152612.4789491e@subdivisions.wooz.org> On Feb 17, 2017, at 03:45 PM, Senthil Kumaran wrote: >On Fri, Feb 17, 2017 at 2:39 PM, Barry Warsaw wrote: >> >> But now I'm stuck and I'm impatient. ;) > >No more. :) Thanks Senthil! And thanks Berker who also reviewed the branch. >I spent time reading the bug, understanding the comments, reviewing >the code, and then toggled my approval. > >The later action was a helpful thing for "me", in addition to being >helpful to you to commit the code. > >If you had already committed, perhaps I might not have taken those >steps until I had a need to. It's a fair point. Maybe we shouldn't change the setting just yet. (As I said, I was being impatient. :) Brett's argued for leaving the current workflow alone for a month to see how things shake out, and it wouldn't be unreasonable to do that here too. Maybe having things on GH will eventually improve the review bottleneck, but if we're too eager to turn off that requirement, we may not find out. Maybe we should bring back MvL's 5-for-1 offer. :) Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From steve.dower at python.org Sat Feb 18 16:38:23 2017 From: steve.dower at python.org (Steve Dower) Date: Sat, 18 Feb 2017 13:38:23 -0800 Subject: [core-workflow] Can core developers bypass PR checks? Message-ID: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> (I'm not subscribed to this list, so please keep me on CC) Was there any discussion about allowing core developers to bypass any of the PR checks? Or was there an assumption that we'd just push directly to the main repo? For example, most of my contributions are to do with the Windows installer. Due to the nature of installers, virtually nobody else is confident to review anything complex, or even simple ones (such as https://github.com/python/cpython/pull/160) due to not being able to predict the flow on effects. As a result, I make many small changes that would take a long time to get reviewed. Similarly, many of my changes are not touched by the automated builds. Particularly anything to do with the installer is certainly not going to be built on a Linux box, and most (probably all) Windows buildbots don't build the installer right now. I've seen some systems where tags can be applied to a PR to skip build validation - I would certainly find that valuable. But essentially, I believe it should be within the power of core developers to bypass the checkin requirements (review + builds) and force a merge. Currently this is not possible - could it be enabled? Obviously it's placing trust in our core dev team, but that's the way it has always been, and we don't lose any traceability from this (unlike allowing people to delete branches from the repo, which can permanently lose code). Cheers, Steve From donald at stufft.io Sun Feb 19 13:35:29 2017 From: donald at stufft.io (Donald Stufft) Date: Sun, 19 Feb 2017 13:35:29 -0500 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> Message-ID: <0E471D97-B187-4289-AFB2-DF3396A92562@stufft.io> > > On Feb 18, 2017, at 4:38 PM, Steve Dower wrote: > > (I'm not subscribed to this list, so please keep me on CC) > > Was there any discussion about allowing core developers to bypass any of the PR checks? Or was there an assumption that we'd just push directly to the main repo? See: https://mail.python.org/pipermail/core-workflow/2017-February/000884.html > > For example, most of my contributions are to do with the Windows installer. Due to the nature of installers, virtually nobody else is confident to review anything complex, or even simple ones (such as https://github.com/python/cpython/pull/160) due to not being able to predict the flow on effects. As a result, I make many small changes that would take a long time to get reviewed. So as I said to Barry in the linked thread, part of the goal here is to force the process between committers and non-committers to be as similar as possible which will solve the real very real problem (that the GH migration?s goal was to help with) that when you have two processes, a stream lined one for those in power and a bulky slow one for those not, that it is hard to get the bulky slow once fixed because nobody in power ever experiences it. By aligning the two processes as much as possible, we identify pain points are forced to solve them or deal with them. This sounds like one such problem. If you?re the only person capable (for skill or confidence) of reviewing these changes, what happens if you?re unavailable for some reason? (Burnout, illness, whatever). Is there any effort to mentor or attract additional contributors who are able to review these changes? I?m guessing there is not, and the risk to allowing bypassing the requirement is that there never *is* a plan to fix it. On the other hand, much like I said with Barry, it?s also possible that these problems are special enough that we can or should just relax restrictions in order to allow forward movement to still happen. > > Similarly, many of my changes are not touched by the automated builds. Particularly anything to do with the installer is certainly not going to be built on a Linux box, and most (probably all) Windows buildbots don't build the installer right now. I've seen some systems where tags can be applied to a PR to skip build validation - I would certainly find that valuable. This also sounds like a problem to me :) Obviously not the Linux part (but then, burning some CPU on running the test suite on Linux isn?t really that big of a deal is it?), but probably the installer should be getting tested in some way? > > But essentially, I believe it should be within the power of core developers to bypass the checkin requirements (review + builds) and force a merge. Currently this is not possible - could it be enabled? Obviously it's placing trust in our core dev team, but that's the way it has always been, and we don't lose any traceability from this (unlike allowing people to delete branches from the repo, which can permanently lose code). I mentioned it above, but to my mind (and this is just a personal opinion) it?s not really anything about *trust*. If we have two different processes, we are going to make the one that we, the people in power, use be as streamlined as possible and the other process for non committers will *likely* end up slowly bitrotting and not keeping up with no tooling, changes, and ideas that can make it better. Forcing everyone onto the same process means that as we figure out and continuously improve the process for us, it also improves it for other people who do not have a commit bit. ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Sun Feb 19 18:41:00 2017 From: barry at python.org (Barry Warsaw) Date: Sun, 19 Feb 2017 18:41:00 -0500 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> Message-ID: <20170219184100.12d1b902@subdivisions.wooz.org> On Feb 18, 2017, at 01:38 PM, Steve Dower wrote: >Was there any discussion about allowing core developers to bypass any of the >PR checks? Or was there an assumption that we'd just push directly to the >main repo? I echo Donald's comments. And while this may be something we want to change, it's good to identify it as a workflow pain point, and perhaps relax the constraint as we get more experience with it. Another option is to implement some kind of "rubber stamp" mechanism, either automated or manual. So you would still go through the PR workflow, but if you can't (or don't reasonably expect) to get a review in a timely manner, then we rubber stamp the PR so that it can land. We could add a rubber-stamp-requested tag which could be a good way for PR gardeners to find those kinds of issues. We'd have to be careful not to abuse those, so add a justification to the PR comment and let another core dev at least review the reasons for the rubber stamp request. Then a cursory "this at least doesn't look insane" review and a rubber stamp approval would unstick the process. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From donald at stufft.io Sun Feb 19 18:54:01 2017 From: donald at stufft.io (Donald Stufft) Date: Sun, 19 Feb 2017 18:54:01 -0500 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <3cf3ef6b-dc29-c69c-0978-5f4c748e2c89@python.org> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> <0E471D97-B187-4289-AFB2-DF3396A92562@stufft.io> <3cf3ef6b-dc29-c69c-0978-5f4c748e2c89@python.org> Message-ID: <0CB12202-57BF-4D44-BB93-886F8368CE7D@stufft.io> > On Feb 19, 2017, at 6:29 PM, Steve Dower wrote: > > On 19Feb2017 1035, Donald Stufft wrote: >>> >>> On Feb 18, 2017, at 4:38 PM, Steve Dower >> > wrote: >>> >>> (I'm not subscribed to this list, so please keep me on CC) >>> >>> Was there any discussion about allowing core developers to bypass any >>> of the PR checks? Or was there an assumption that we'd just push >>> directly to the main repo? >> >> See: https://mail.python.org/pipermail/core-workflow/2017-February/000884.html > > Thanks. The outcome of that thread (let's wait for a month) is the right one. Like Barry, I was just impatient. > >>> For example, most of my contributions are to do with the Windows >>> installer. Due to the nature of installers, virtually nobody else is >>> confident to review anything complex, or even simple ones (such as >>> https://github.com/python/cpython/pull/160) due to not being able to >>> predict the flow on effects. As a result, I make many small changes >>> that would take a long time to get reviewed. >> >> >> So as I said to Barry in the linked thread, part of the goal here is to >> force the process between committers and non-committers to be as similar >> as possible which will solve the real very real problem (that the GH >> migration?s goal was to help with) that when you have two processes, a >> stream lined one for those in power and a bulky slow one for those not, >> that it is hard to get the bulky slow once fixed because nobody in >> power ever experiences it. By aligning the two processes as much as >> possible, we identify pain points are forced to solve them or deal with >> them. > > I have absolutely no problem with requiring core devs to send PRs - I am 100% against *anyone* directly pushing to the main repo - it's just the PR approval process that is the problem. Yea, Github doesn?t give us a mechanism to require PRs to be sent other than either requiring reviews or requiring status checks. I?m not personally ideologically opposed to letting people merge their own patches (and in fact, when it was decided to turn on required merges I thought it allowed people to self approve, dunno if Brett did or not) it was primarily I *think* because we were worried that the status checks weren?t going to be stable enough to turn them on required. Of course we can always just say it?s ?required?, as a policy without any technical enforcement. > >> This sounds like one such problem. If you?re the only person capable >> (for skill or confidence) of reviewing these changes, what happens if >> you?re unavailable for some reason? (Burnout, illness, whatever). Is >> there any effort to mentor or attract additional contributors who are >> able to review these changes? I?m guessing there is not, and the risk to >> allowing bypassing the requirement is that there never *is* a plan to >> fix it. > > I'd love to attract additional contributors for this. Unfortunately, working on installers on Windows is even less popular than working on OpenSSL :) Yea I can feel that pain, since packaging is not something a ton of people are generally enthused to work on either. It?s possible that it?s just really hard to find someone to do this and it?s just something we have to live with. Hopefully not though :) > >> On the other hand, much like I said with Barry, it?s also possible that >> these problems are special enough that we can or should just relax >> restrictions in order to allow forward movement to still happen. >> >> >>> >>> Similarly, many of my changes are not touched by the automated builds. >>> Particularly anything to do with the installer is certainly not going >>> to be built on a Linux box, and most (probably all) Windows buildbots >>> don't build the installer right now. I've seen some systems where tags >>> can be applied to a PR to skip build validation - I would certainly >>> find that valuable. >> >> This also sounds like a problem to me :) Obviously not the Linux part >> (but then, burning some CPU on running the test suite on Linux isn?t >> really that big of a deal is it?), but probably the installer should be >> getting tested in some way? > > It's manually tested, and typically on the build machine where it will be actually built. Getting it into a build somewhere may be useful, but adding 5-10 minutes to *every* checkin for something that basically only I ever change seems like a waste. > > And you never regret burning some CPU on tests until you have more tests running than available machines. Previously we would batch test commits - I'm not sure if that's still happening or not, but that indicates some value in not spending the full time on each individual commit. > > But maybe there's an easy way to only trigger tests when certain files are modified? It may not make sense to set that up for each individual module, but it might be worthwhile to trigger certain extra builds when PCBuild/* or tools/msi/* are modified. We don?t actually have Windows tests being run at all on pull requests (largely because AppVeyor took too long to run), though we obviously still have the buildbot fleet running post commit. This is something we should ideally rectify though! On the Travis builders, we skip running the unit tests all together if the PR was for something that couldn?t possibly change the outcome. I?m not familiar enough with the capabilities of the Python test runner to know if it can mark tests somehow to be excluded by default and only run if a certain flag is ran, if so it shouldn?t be very hard to make something that only runs those tests on changes to PCBuilder/* or tools/msi/*. Otherwise it might need a separate set of tests for it that can be independently ran. > >>> But essentially, I believe it should be within the power of core >>> developers to bypass the checkin requirements (review + builds) and >>> force a merge. Currently this is not possible - could it be enabled? >>> Obviously it's placing trust in our core dev team, but that's the way >>> it has always been, and we don't lose any traceability from this >>> (unlike allowing people to delete branches from the repo, which can >>> permanently lose code). >> >> >> I mentioned it above, but to my mind (and this is just a personal >> opinion) it?s not really anything about *trust*. If we have two >> different processes, we are going to make the one that we, the people in >> power, use be as streamlined as possible and the other process for non >> committers will *likely* end up slowly bitrotting and not keeping up >> with no tooling, changes, and ideas that can make it better. Forcing >> everyone onto the same process means that as we figure out and >> continuously improve the process for us, it also improves it for other >> people who do not have a commit bit. > > And as I said above, I don't think this is a different process. It's an escape hatch for the single process that's only available to certain trusted people (i.e. those who we trust to say whether code is good enough to be committed). But I'm happy to wait out the month and see if it's an issue. > > (Was about to write "we can all complain at the PyCon US language summit", which made me worry that if that's *all* we complain about it may be useless. For those of us who will be there, should we organise a separate workflow summit? Preferably somewhere that serves strong drinks? ;) ) > ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Sun Feb 19 19:12:23 2017 From: donald at stufft.io (Donald Stufft) Date: Sun, 19 Feb 2017 19:12:23 -0500 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <7a557bb0-36b9-0694-0965-c45487709060@python.org> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> <0E471D97-B187-4289-AFB2-DF3396A92562@stufft.io> <3cf3ef6b-dc29-c69c-0978-5f4c748e2c89@python.org> <0CB12202-57BF-4D44-BB93-886F8368CE7D@stufft.io> <7a557bb0-36b9-0694-0965-c45487709060@python.org> Message-ID: <7AD9D477-7F16-450D-92A8-EA59B1EF258F@stufft.io> > On Feb 19, 2017, at 7:01 PM, Steve Dower wrote: > > On 19Feb2017 1554, Donald Stufft wrote: >> We don?t actually have Windows tests being run at all on pull requests >> (largely because AppVeyor took too long to run), though we obviously >> still have the buildbot fleet running post commit. This is something we >> should ideally rectify though! >> >> On the Travis builders, we skip running the unit tests all together if >> the PR was for something that couldn?t possibly change the outcome. I?m >> not familiar enough with the capabilities of the Python test runner to >> know if it can mark tests somehow to be excluded by default and only run >> if a certain flag is ran, if so it shouldn?t be very hard to make >> something that only runs those tests on changes to PCBuilder/* or >> tools/msi/*. Otherwise it might need a separate set of tests for it that >> can be independently ran. > > I can easily get some VSTS (*.visualstudio.com) test runners going with VMs on Azure. I'm just not quite sure how to feed the results back into the github status checks right now, or how to make them publicly maintainable (that is, they'd be very much owned and only accessible by me, and likely only as long as I'm employed by Microsoft, which isn't great for sustainability - though of course anyone else can also set up the build definition and their own pool of VMs). > > No promises on dates, but this is something that I'll likely do regardless. I want the Windows tests as badly as anyone :) > > Cheers, > Steve Getting compute power is part of the problem, the other problem is something to control those compute nodes and interact with GitHub. The main piece of software I know in this space is buildbot and Jenkins. We obviously have a buildbot fleet already (and re-using that would mean less maintenance in general) I don?t know what the pre-merge workflow for buildbot looks like though. I do know that Jenkins is an option, they have a plugin for handling it (although it?s not as nice as travis). It requires whitelisting people whose PRs are allowed to be tested or for a committer to come along and say that a particular PR is OK to test. It does this because the Jenkins model does not have any isolation in the builders so you have to have someone review the code PR to Jenkins running it or a malicious PR person gets the ability to do some nasty stuff. Another alternative is https://concourse.ci/ , which doesn?t have a defined story for isolating pull request builds, but there are some sketches for how it should be done (https://github.com/concourse/concourse/issues/366 ) but I don?t know how well that works on Windows since It uses containers to run builds in (I think it has a no-op-ish thing on Windows, but that might mean that the security properties don?t exist then, I dunno). Securely running untrusted code is hard :| ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at timgolden.me.uk Mon Feb 20 05:35:21 2017 From: mail at timgolden.me.uk (Tim Golden) Date: Mon, 20 Feb 2017 10:35:21 +0000 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> Message-ID: <5461c96e-316f-467c-8b73-9e0c8bef4d3a@timgolden.me.uk> On 18/02/2017 21:38, Steve Dower wrote: > For example, most of my contributions are to do with the Windows > installer. Due to the nature of installers, virtually nobody else is > confident to review anything complex, or even simple ones (such as > https://github.com/python/cpython/pull/160) due to not being able to > predict the flow on effects. As a result, I make many small changes that > would take a long time to get reviewed. Steve, tangential to the issue of self-approved PRs, can I pick up the ball I dropped a year or so ago and propose again the idea of an online session where you outline the elements of the Installer for, at least, the other Windows-oriented devs and anyone else who's interested? The more people who can at least be aware of the what's involved the better, I think. TJG From xdegaye at gmail.com Mon Feb 20 08:30:35 2017 From: xdegaye at gmail.com (Xavier de Gaye) Date: Mon, 20 Feb 2017 14:30:35 +0100 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <0CB12202-57BF-4D44-BB93-886F8368CE7D@stufft.io> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> <0E471D97-B187-4289-AFB2-DF3396A92562@stufft.io> <3cf3ef6b-dc29-c69c-0978-5f4c748e2c89@python.org> <0CB12202-57BF-4D44-BB93-886F8368CE7D@stufft.io> Message-ID: <5ba44c97-6ee3-7c5a-4703-52fc2f8879b5@gmail.com> On 02/20/2017 12:54 AM, Donald Stufft wrote: > Yea I can feel that pain, since packaging is not something a ton of people are generally enthused to work on either. It?s possible that it?s just really hard to find someone to do this and it?s just > something we have to live with. Hopefully not though :) There are other parts of Python where it is difficult to find interested core developers, for example the pdb module. It does not seem right that with that enforced policy, an external contributor to pdb has a chance to have its PR merged (by me - Georg has removed himself from the list of pdb experts) while for me, who has tried to contribute to pdb for a few years before I became a core dev, the chances I have now to get my own straightforward pdb PRs merged are quite weak. This is only an example, I am not currently working on pdb so there is no problem now. Another point is that small teams of 2-3 core devs may naturally and quite rightly emerge to work a I-review-your-PR-you-review-mine dance, possibly to the detriment of external contributions BTW, while other core devs may lose their motivation not finding anyone to review PRs that are obvious changes. Xavier From ncoghlan at gmail.com Wed Feb 22 02:51:18 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 22 Feb 2017 13:21:18 +0530 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <20170217183237.79e621c9@subdivisions.wooz.org> Message-ID: On 22 February 2017 at 13:12, Nick Coghlan wrote: > I'm +1 for turning on required status checks though - giving us a > strong incentive to get the test suite stable and keep it that way is > an unequivocally good thing, and I do want to keep the "PR required, > even for core developers" experiment going for at least another few > weeks. To be clear: my preference would be to have the setup be "Review required, but self-review is permitted", as that lets us decided whether or not it makes sense to wait for the CI to run. But if GitHub doesn't allow that, then I think "Successful CI run required" would be a better near term gate than preventing developers from merging our own changes (even when we're importing someone else's patch from bugs.python.org or just fixing a typo in the docs) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Wed Feb 22 02:42:16 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 22 Feb 2017 13:12:16 +0530 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <20170217183237.79e621c9@subdivisions.wooz.org> Message-ID: On 18 February 2017 at 05:12, Senthil Kumaran wrote: > On Fri, Feb 17, 2017 at 3:32 PM, Barry Warsaw wrote: >> As you say, reviewer bandwidth is a bottleneck > > Would anyone consider "Requiring a review from another > core-developer" is actually a helpful thing? No, because we don't have anything close to the reviewer bandwidth needed to keep the previous "single review needed" process running smoothly, let alone a "double review needed (even on backports)" process. > The positives I see are: > > 1) Forcing other developers with commit rights to act soon and review > each other's code more often. Are you offering to pay everyone for the time spent on these additional reviews? Remember, disallowing self-review will come close to doubling the aggregate review bandwidth required for the core development process (especially with backports requiring a PR-per-branch). > 2) As a result of 1, the developers are incentivized to stay involved > either in reviews, by reading code and subsequently will be fast in > contributing code. What incentive? I'm *less* inclined to contribute right now, and less inclined to mentor people, since I can get very little done on my own, and instead even the simplest of tasks can drag on for 24 or 48 hours (There are relatively few other core developers in my time zone, so folks in the US and Europe saying "I don't have any trouble finding extra reviewers" doesn't carry a lot of weight with me on this point). I'm +1 for turning on required status checks though - giving us a strong incentive to get the test suite stable and keep it that way is an unequivocally good thing, and I do want to keep the "PR required, even for core developers" experiment going for at least another few weeks. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From soltysh at gmail.com Wed Feb 22 07:24:18 2017 From: soltysh at gmail.com (Maciej Szulik) Date: Wed, 22 Feb 2017 13:24:18 +0100 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <20170217183237.79e621c9@subdivisions.wooz.org> Message-ID: On Wed, Feb 22, 2017 at 8:51 AM, Nick Coghlan wrote: > On 22 February 2017 at 13:12, Nick Coghlan wrote: > > I'm +1 for turning on required status checks though - giving us a > > strong incentive to get the test suite stable and keep it that way is > > an unequivocally good thing, and I do want to keep the "PR required, > > even for core developers" experiment going for at least another few > > weeks. > > To be clear: my preference would be to have the setup be "Review > required, but self-review is permitted", as that lets us decided > whether or not it makes sense to wait for the CI to run. > If I'm correct, gh will grey-out (but completly block) merge when all the checks are not green. Green CI should be helpful here. Eventually we could add some additional checks for self-approval awareness in our bot. > > But if GitHub doesn't allow that, then I think "Successful CI run > required" would be a better near term gate than preventing developers > from merging our own changes (even when we're importing someone else's > patch from bugs.python.org or just fixing a typo in the docs) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Wed Feb 22 10:22:00 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 23 Feb 2017 01:22:00 +1000 Subject: [core-workflow] self-approving pull requests In-Reply-To: <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> Message-ID: On 18 February 2017 at 09:24, Donald Stufft wrote: > We turned on require code review for the PR, though at the time I *thought* > it still allowed you to approve your own PR. Apparently that was wrong. > Brett was the one to actually make the decision to do it and turned it on, > so I don?t know if he knew that it didn?t allow people to self-approve or > not. The impetus to do this was to make sure that all changes went through > the PR process and folks didn?t directly push to `master`. While this is a good ideal to strive for, I'm starting to think it isn't practical with our current development set up. The trigger for this change in my thinking was going to merge https://github.com/python/cpython/pull/171 which is basically fine, but needs a few clean-ups prior to committing: - Misc/ACKS update - Misc/NEWS entry - What's New entry - (and probably a rebase due to Misc/NEWS) It's generally easier to just add those myself rather than asking the contributor to do it, and then the contributor can look at the final commit to see what these additional bookkeeping entries look like. However, without the ability to commit locally and then push to GitHub from there, you end up with one of two options: - attempt to amend the original PR (see https://github.com/python/devguide/issues/129 ). That may not work depending on how the contributor has set up their fork and PR branch. - create a new PR and close the original one (with the corresponding subpar experience for the original contributor) So as much as I'd like to keep it, it probably makes sense to turn off branch protection for now and instead start making a list of the things that would be needed to turn it back on, starting with: - a way of reliably editing PRs that doesn't require closing them and creating new ones - conflict-free NEWS entry definition - a way for core developers to handle minor changes autonomously rather than always needing someone else to be online and responsive Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From soltysh at gmail.com Wed Feb 22 10:59:06 2017 From: soltysh at gmail.com (Maciej Szulik) Date: Wed, 22 Feb 2017 16:59:06 +0100 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> Message-ID: On Wed, Feb 22, 2017 at 4:22 PM, Nick Coghlan wrote: > On 18 February 2017 at 09:24, Donald Stufft wrote: > > We turned on require code review for the PR, though at the time I > *thought* > > it still allowed you to approve your own PR. Apparently that was wrong. > > Brett was the one to actually make the decision to do it and turned it > on, > > so I don?t know if he knew that it didn?t allow people to self-approve or > > not. The impetus to do this was to make sure that all changes went > through > > the PR process and folks didn?t directly push to `master`. > > While this is a good ideal to strive for, I'm starting to think it > isn't practical with our current development set up. > > The trigger for this change in my thinking was going to merge > https://github.com/python/cpython/pull/171 which is basically fine, > but needs a few clean-ups prior to committing: > > - Misc/ACKS update > - Misc/NEWS entry > - What's New entry > - (and probably a rebase due to Misc/NEWS) > > It's generally easier to just add those myself rather than asking the > contributor to do it, and then the contributor can look at the final > commit to see what these additional bookkeeping entries look like. > > However, without the ability to commit locally and then push to GitHub > from there, you end up with one of two options: > > - attempt to amend the original PR (see > https://github.com/python/devguide/issues/129 ). That may not work > depending on how the contributor has set up their fork and PR branch. > - create a new PR and close the original one (with the corresponding > subpar experience for the original contributor) > You should be able to cherry-pick his commit. For that it's worth setting your repo to be able to checkout any PR submitted to a repo: https://gist.github.com/piscisaureus/3342247 with that you can basically do git checkout pr/XXX and from that you can easily get the commit id and be able to cherry-pick it, amend it or add new thing on top of it. In the end submitting a new PR, replacing the original one. > > So as much as I'd like to keep it, it probably makes sense to turn off > branch protection for now and instead start making a list of the > things that would be needed to turn it back on, starting with: > > - a way of reliably editing PRs that doesn't require closing them and > creating new ones > - conflict-free NEWS entry definition > - a way for core developers to handle minor changes autonomously > rather than always needing someone else to be online and responsive > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > core-workflow mailing list > core-workflow at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Wed Feb 22 11:10:15 2017 From: donald at stufft.io (Donald Stufft) Date: Wed, 22 Feb 2017 11:10:15 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> Message-ID: <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> > On Feb 22, 2017, at 10:22 AM, Nick Coghlan wrote: > > - attempt to amend the original PR (see > https://github.com/python/devguide/issues/129 ). That may not work > depending on how the contributor has set up their fork and PR branch. > - create a new PR and close the original one (with the corresponding > subpar experience for the original contributor) FWIW, I don?t think that creating a new PR and closing the original one is a subpar experience for contributors, particularly if we turn off the bit that requires reviews and just turn on the thing that requires passing tests. Having been in that situation it has never once bothered me to have someone cherry pick my change and amend it. ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From donald at stufft.io Wed Feb 22 11:12:03 2017 From: donald at stufft.io (Donald Stufft) Date: Wed, 22 Feb 2017 11:12:03 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <20170217183237.79e621c9@subdivisions.wooz.org> Message-ID: <4C25ACE7-F0A1-4D18-98EC-31A893FB7644@stufft.io> > On Feb 22, 2017, at 2:42 AM, Nick Coghlan wrote: > > I'm +1 for turning on required status checks though - giving us a > strong incentive to get the test suite stable and keep it that way is > an unequivocally good thing, and I do want to keep the "PR required, > even for core developers" experiment going for at least another few > weeks. I?m happy to switch this around, but I don?t know whose call it is. Does Brett need to make this call? I dunno. ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From barry at python.org Wed Feb 22 11:25:13 2017 From: barry at python.org (Barry Warsaw) Date: Wed, 22 Feb 2017 11:25:13 -0500 Subject: [core-workflow] self-approving pull requests References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> Message-ID: <20170222112513.16b74ff2@subdivisions.wooz.org> On Feb 22, 2017, at 11:10 AM, Donald Stufft wrote: >FWIW, I don?t think that creating a new PR and closing the original one is a >subpar experience for contributors, particularly if we turn off the bit that >requires reviews and just turn on the thing that requires passing >tests. Having been in that situation it has never once bothered me to have >someone cherry pick my change and amend it. Since we're squashing commits wouldn't that obliterate the original author's credit for the work? Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From barry at python.org Wed Feb 22 11:26:44 2017 From: barry at python.org (Barry Warsaw) Date: Wed, 22 Feb 2017 11:26:44 -0500 Subject: [core-workflow] self-approving pull requests References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <20170217183237.79e621c9@subdivisions.wooz.org> <4C25ACE7-F0A1-4D18-98EC-31A893FB7644@stufft.io> Message-ID: <20170222112644.571cd71c@subdivisions.wooz.org> On Feb 22, 2017, at 11:12 AM, Donald Stufft wrote: >I?m happy to switch this around, but I don?t know whose call it is. Does >Brett need to make this call? I dunno. Brett should at least get a chance to weigh in, so let's wait for him to return. -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From senthil at uthcode.com Wed Feb 22 11:35:35 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 22 Feb 2017 08:35:35 -0800 Subject: [core-workflow] self-approving pull requests In-Reply-To: <4C25ACE7-F0A1-4D18-98EC-31A893FB7644@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <20170217183237.79e621c9@subdivisions.wooz.org> <4C25ACE7-F0A1-4D18-98EC-31A893FB7644@stufft.io> Message-ID: On Wed, Feb 22, 2017 at 8:12 AM, Donald Stufft wrote: > I?m happy to switch this around, but I don?t know whose call it is. Does > Brett need to make this call? I dunno. I am +1 on turning on the required status check before the merge is enabled. It was briefly discussed here: https://mail.python.org/pipermail/python-committers/2017-February/004255.html We can use that thread to bring it to a closure. I understand Nick's point of view in this thread. It might be that given my time zone or chance, I could get reviewers easily. And, I could pull myself to review small patches. With our previous VCS, we have trusted core-developers to take appropriate actions. So, for any significant changes, I assume, developers will involve another developer for the review. And for non-controversial, straightforward improvements, they would be free to commit stuff (as it was the case with hg). Github allows such a provision, if we decide to go for it, we should know that no extra/special tooling should be required. Thanks, Senthil From donald at stufft.io Wed Feb 22 11:39:07 2017 From: donald at stufft.io (Donald Stufft) Date: Wed, 22 Feb 2017 11:39:07 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <20170222112513.16b74ff2@subdivisions.wooz.org> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> <20170222112513.16b74ff2@subdivisions.wooz.org> Message-ID: <88EF9F9D-24F9-46D0-807D-C8539D6BA0BD@stufft.io> > On Feb 22, 2017, at 11:25 AM, Barry Warsaw wrote: > > Since we're squashing commits wouldn't that obliterate the original author's > credit for the work? Yes, github will credit the person who opened the PR, but the person who made the person who made the PR can check the box (which I *believe* is checked by default) to allow maintainers to edit their PR. If that is checked, then maintainers can edit their branch on their fork directly, in which case no credit gets lost. So just make your changes directly in their branch, and things will continue to work. ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at stoneleaf.us Wed Feb 22 14:16:04 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 22 Feb 2017 11:16:04 -0800 Subject: [core-workflow] self-approving pull requests In-Reply-To: <88EF9F9D-24F9-46D0-807D-C8539D6BA0BD@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> <20170222112513.16b74ff2@subdivisions.wooz.org> <88EF9F9D-24F9-46D0-807D-C8539D6BA0BD@stufft.io> Message-ID: <58ADE374.9030400@stoneleaf.us> On 02/22/2017 08:39 AM, Donald Stufft wrote: >> On Feb 22, 2017, at 11:25 AM, Barry Warsaw wrote: >> Since we're squashing commits wouldn't that obliterate the original author's >> credit for the work? > > Yes, github will credit the person who opened the PR, but the person who made > the person who made the PR can check the box (which I *believe* is checked by > default) to allow maintainers to edit their PR. If that is checked, then > maintainers can edit their branch on their fork directly, in which case no > credit gets lost. > > So just make your changes directly in their branch, and things will continue > to work. Is there a list of instructions somewhere on how to do all that? -- ~Ethan~ From donald at stufft.io Wed Feb 22 14:26:28 2017 From: donald at stufft.io (Donald Stufft) Date: Wed, 22 Feb 2017 14:26:28 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: <58ADE374.9030400@stoneleaf.us> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> <20170222112513.16b74ff2@subdivisions.wooz.org> <88EF9F9D-24F9-46D0-807D-C8539D6BA0BD@stufft.io> <58ADE374.9030400@stoneleaf.us> Message-ID: <87E2CEFE-47A3-4721-8C58-D08E57E82199@stufft.io> You can clone their repository and make changes directly to their branch and push to it I believe, assuming they allowed that when they made the PR. You should also be able to add their fork as a remote on your current branch using 'git remote add foobar githuburl' then checkout the got branch from them. Sent from my iPhone > On Feb 22, 2017, at 2:16 PM, Ethan Furman wrote: > > On 02/22/2017 08:39 AM, Donald Stufft wrote: >>> On Feb 22, 2017, at 11:25 AM, Barry Warsaw wrote: > >>> Since we're squashing commits wouldn't that obliterate the original author's >>> credit for the work? >> >> Yes, github will credit the person who opened the PR, but the person who made >> the person who made the PR can check the box (which I *believe* is checked by >> default) to allow maintainers to edit their PR. If that is checked, then >> maintainers can edit their branch on their fork directly, in which case no >> credit gets lost. >> >> So just make your changes directly in their branch, and things will continue >> to work. > > Is there a list of instructions somewhere on how to do all that? > > -- > ~Ethan~ > _______________________________________________ > core-workflow mailing list > core-workflow at 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 From ethan at stoneleaf.us Wed Feb 22 15:31:57 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 22 Feb 2017 12:31:57 -0800 Subject: [core-workflow] git notifications Message-ID: <58ADF53D.7040309@stoneleaf.us> One thing that seems to be lacking: names of commenters. In the recent thread about [Provide guidance on editing PRs prior to merge (#129)] there are several entries, from at least two people, and I have no idea who they are or exactly which one said what because their names are not showing up anywhere that I can see. Granted I could go and look on GitHub directly, but this feels like a regression from our previous work flow. -- ~Ethan~ From senthil at uthcode.com Wed Feb 22 15:35:53 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 22 Feb 2017 12:35:53 -0800 Subject: [core-workflow] git notifications In-Reply-To: <58ADF53D.7040309@stoneleaf.us> References: <58ADF53D.7040309@stoneleaf.us> Message-ID: On Wed, Feb 22, 2017 at 12:31 PM, Ethan Furman wrote: > In the recent thread about [Provide guidance on editing PRs prior to merge > (#129)] Could you provide a link to this? PR # is not enough to find it. From ethan at stoneleaf.us Wed Feb 22 15:46:05 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 22 Feb 2017 12:46:05 -0800 Subject: [core-workflow] git notifications In-Reply-To: <58ADF53D.7040309@stoneleaf.us> References: <58ADF53D.7040309@stoneleaf.us> Message-ID: <58ADF88D.6020201@stoneleaf.us> The issue link: https://github.com/python/devguide/issues/129 -- ~Ethan~ From senthil at uthcode.com Wed Feb 22 16:32:43 2017 From: senthil at uthcode.com (Senthil Kumaran) Date: Wed, 22 Feb 2017 13:32:43 -0800 Subject: [core-workflow] git notifications In-Reply-To: <58ADF88D.6020201@stoneleaf.us> References: <58ADF53D.7040309@stoneleaf.us> <58ADF88D.6020201@stoneleaf.us> Message-ID: On Wed, Feb 22, 2017 at 12:46 PM, Ethan Furman wrote: > The issue link: > > https://github.com/python/devguide/issues/129 Well, at least I could not understand the original problem properly. Here is my screenshot of the discuss as it appears in my email https://www.dropbox.com/s/gdl5ke0ffzirt85/Screenshot%202017-02-22%2012.50.44.png?dl=0 And I see the authors name in the discussion, their FROM email id's are masked by github. -- Senthil From ethan at stoneleaf.us Wed Feb 22 20:37:32 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Wed, 22 Feb 2017 17:37:32 -0800 Subject: [core-workflow] git notifications In-Reply-To: References: <58ADF53D.7040309@stoneleaf.us> <58ADF88D.6020201@stoneleaf.us> Message-ID: <58AE3CDC.6030103@stoneleaf.us> On 02/22/2017 01:32 PM, Senthil Kumaran wrote: > On Wed, Feb 22, 2017 at 12:46 PM, Ethan Furman wrote: >> The issue link: >> >> https://github.com/python/devguide/issues/129 > > Well, at least I could not understand the original problem properly. > > Here is my screenshot of the discuss as it appears in my email > > https://www.dropbox.com/s/gdl5ke0ffzirt85/Screenshot%202017-02-22%2012.50.44.png?dl=0 > > And I see the authors name in the discussion, their FROM email id's > are masked by github. Interesting. This is what I see in Thunderbird: https://www.dropbox.com/s/b6lgtyyn4yspnu4/git-no_names_with_notifications.png?dl=0 -- ~Ethan~ From ncoghlan at gmail.com Wed Feb 22 23:17:42 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 23 Feb 2017 14:17:42 +1000 Subject: [core-workflow] self-approving pull requests In-Reply-To: <20170222112513.16b74ff2@subdivisions.wooz.org> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> <20170222112513.16b74ff2@subdivisions.wooz.org> Message-ID: On 23 February 2017 at 02:25, Barry Warsaw wrote: > On Feb 22, 2017, at 11:10 AM, Donald Stufft wrote: > >>FWIW, I don?t think that creating a new PR and closing the original one is a >>subpar experience for contributors, particularly if we turn off the bit that >>requires reviews and just turn on the thing that requires passing >>tests. Having been in that situation it has never once bothered me to have >>someone cherry pick my change and amend it. > > Since we're squashing commits wouldn't that obliterate the original author's > credit for the work? You can set "--author" when making the new squash commit (we should document that somewhere, since it's also useful when importing patches from bugs.python.org). Although looking at https://github.com/python/cpython/pull/169 (where I set the author to Serhiy, since I was importing a patch he wrote), it seems GitHub doesn't actually *show* the Author information anywhere that I can find. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From donald at stufft.io Wed Feb 22 23:18:44 2017 From: donald at stufft.io (Donald Stufft) Date: Wed, 22 Feb 2017 23:18:44 -0500 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> <20170222112513.16b74ff2@subdivisions.wooz.org> Message-ID: <453D099B-E8E6-474C-ACF4-531E5A823BA8@stufft.io> > On Feb 22, 2017, at 11:17 PM, Nick Coghlan wrote: > > On 23 February 2017 at 02:25, Barry Warsaw wrote: >> On Feb 22, 2017, at 11:10 AM, Donald Stufft wrote: >> >>> FWIW, I don?t think that creating a new PR and closing the original one is a >>> subpar experience for contributors, particularly if we turn off the bit that >>> requires reviews and just turn on the thing that requires passing >>> tests. Having been in that situation it has never once bothered me to have >>> someone cherry pick my change and amend it. >> >> Since we're squashing commits wouldn't that obliterate the original author's >> credit for the work? > > You can set "--author" when making the new squash commit (we should > document that somewhere, since it's also useful when importing patches > from bugs.python.org). > > Although looking at https://github.com/python/cpython/pull/169 (where > I set the author to Serhiy, since I was importing a patch he wrote), > it seems GitHub doesn't actually *show* the Author information > anywhere that I can find. > Github automatically sets author of the squash commit based on who opened the PR. ? Donald Stufft -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Wed Feb 22 23:29:59 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 23 Feb 2017 14:29:59 +1000 Subject: [core-workflow] self-approving pull requests In-Reply-To: <87E2CEFE-47A3-4721-8C58-D08E57E82199@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> <20170222112513.16b74ff2@subdivisions.wooz.org> <88EF9F9D-24F9-46D0-807D-C8539D6BA0BD@stufft.io> <58ADE374.9030400@stoneleaf.us> <87E2CEFE-47A3-4721-8C58-D08E57E82199@stufft.io> Message-ID: On 23 February 2017 at 05:26, Donald Stufft wrote: > You can clone their repository and make changes directly to their branch and push to it I believe, assuming they allowed that when they made the PR. This is the part that GitHub hasn't documented very well from the maintainer side yet, but I think I just worked out the appropriate incantation: https://github.com/python/devguide/issues/129#issuecomment-281891204 The trick is that you have to use the "git at github.com:contributor_name/cpython.git" spelling when defining the remote or GitHub won't allow SSH-based pushes back to their repo, even if they've granted maintainer access to their PR branch. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ethan at stoneleaf.us Thu Feb 23 03:09:58 2017 From: ethan at stoneleaf.us (Ethan Furman) Date: Thu, 23 Feb 2017 00:09:58 -0800 Subject: [core-workflow] git notifications In-Reply-To: <58AE3CDC.6030103@stoneleaf.us> References: <58ADF53D.7040309@stoneleaf.us> <58ADF88D.6020201@stoneleaf.us> <58AE3CDC.6030103@stoneleaf.us> Message-ID: <58AE98D6.1040004@stoneleaf.us> Huh. I created a new profile as I was having other issues with Thunderbird, and now I see the names on the git notifications. May have been an address book issue. Problem solved, thanks for the help everyone. -- ~Ethan~ From brett at python.org Fri Feb 24 19:17:45 2017 From: brett at python.org (Brett Cannon) Date: Sat, 25 Feb 2017 00:17:45 +0000 Subject: [core-workflow] self-approving pull requests In-Reply-To: <453D099B-E8E6-474C-ACF4-531E5A823BA8@stufft.io> References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> <20170222112513.16b74ff2@subdivisions.wooz.org> <453D099B-E8E6-474C-ACF4-531E5A823BA8@stufft.io> Message-ID: Two things. One, has someone verified that if a core dev edits a PR that the squash commit still gives the PR creator the author credit in the git metadata? I remember doing an edit like this once and GitHub didn't show any author credit in the web UI because I assume GitHub refused to guess who the author credit should go to. So if someone could test this in a checkout that would be great as that means https://github.com/python/core-workflow/issues/7 can be easily solved and we can automate Misc/ACKS. Two, we are going to review the new workflow in two weeks after having been using it for a month (I can't believe it's only been two weeks since the migration!). Since the sign-off requirement has generated the most discussion, what I will do is swap the requirement for PR merging to be no required review but to require all-green status checks (in a previous email Donald alluded to the fact that I thought self-approval would be possible in "emergencies" but that obviously doesn't hold). This will give us basically 2 weeks with both approaches when we review the process so we can make an informed decision. On Wed, 22 Feb 2017 at 20:19 Donald Stufft wrote: > > On Feb 22, 2017, at 11:17 PM, Nick Coghlan wrote: > > On 23 February 2017 at 02:25, Barry Warsaw wrote: > > On Feb 22, 2017, at 11:10 AM, Donald Stufft wrote: > > FWIW, I don?t think that creating a new PR and closing the original one is > a > subpar experience for contributors, particularly if we turn off the bit > that > requires reviews and just turn on the thing that requires passing > tests. Having been in that situation it has never once bothered me to have > someone cherry pick my change and amend it. > > > Since we're squashing commits wouldn't that obliterate the original > author's > credit for the work? > > > You can set "--author" when making the new squash commit (we should > document that somewhere, since it's also useful when importing patches > from bugs.python.org). > > Although looking at https://github.com/python/cpython/pull/169 (where > I set the author to Serhiy, since I was importing a patch he wrote), > it seems GitHub doesn't actually *show* the Author information > anywhere that I can find. > > > > Github automatically sets author of the squash commit based on who opened > the PR. > > > ? > > Donald Stufft > _______________________________________________ > core-workflow mailing list > core-workflow at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Fri Feb 24 19:31:33 2017 From: brett at python.org (Brett Cannon) Date: Sat, 25 Feb 2017 00:31:33 +0000 Subject: [core-workflow] Travis is now required to be passing, reviews are not Message-ID: I didn't turn on Codecov requirements for the patch because we seem to still have variance in them where some module that are inconsistently being tested (there is a test for the whole project but I left that off as well). I think we should definitely work towards fixing the coverage variance as I would like to require no drop in code coverage at some point, but as of right now it's wonky enough to be too much of a showstopper to flip on. I have opened https://github.com/python/core-workflow/issues/38 to track this and any modules whose coverage is inconsistent so we can eventually fix this and require coverage doesn't decrease. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Sat Feb 25 00:21:43 2017 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sat, 25 Feb 2017 15:21:43 +1000 Subject: [core-workflow] self-approving pull requests In-Reply-To: References: <20170217173915.2c9f3fdd@subdivisions.wooz.org> <7BE9180C-0652-4F2C-ACE9-6EA6589C0177@stufft.io> <72CE8D81-1C64-4E2B-883E-FE40E0E40EFB@stufft.io> <20170222112513.16b74ff2@subdivisions.wooz.org> <453D099B-E8E6-474C-ACF4-531E5A823BA8@stufft.io> Message-ID: On 25 February 2017 at 10:17, Brett Cannon wrote: > Two things. One, has someone verified that if a core dev edits a PR that > the squash commit still gives the PR creator the author credit in the git > metadata? I remember doing an edit like this once and GitHub didn't show > any author credit in the web UI because I assume GitHub refused to guess > who the author credit should go to. So if someone could test this in a > checkout that would be great as that means https://github.com/ > python/core-workflow/issues/7 can be easily solved and we can automate > Misc/ACKS. > > Two, we are going to review the new workflow in two weeks after having > been using it for a month (I can't believe it's only been two weeks since > the migration!). Since the sign-off requirement has generated the most > discussion, what I will do is swap the requirement for PR merging to be no > required review but to require all-green status checks (in a previous email > Donald alluded to the fact that I thought self-approval would be possible > in "emergencies" but that obviously doesn't hold). This will give us > basically 2 weeks with both approaches when we review the process so we can > make an informed decision. > Thanks, the new setup where Travis is required and codecov is advisory is looking pretty good to me so far (I just accepted a PR with bad codecov stats as the branches it was complaining lacked coverage will only trigger on Mac OS X). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.dower at python.org Sun Feb 19 18:29:22 2017 From: steve.dower at python.org (Steve Dower) Date: Sun, 19 Feb 2017 15:29:22 -0800 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <0E471D97-B187-4289-AFB2-DF3396A92562@stufft.io> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> <0E471D97-B187-4289-AFB2-DF3396A92562@stufft.io> Message-ID: <3cf3ef6b-dc29-c69c-0978-5f4c748e2c89@python.org> On 19Feb2017 1035, Donald Stufft wrote: >> >> On Feb 18, 2017, at 4:38 PM, Steve Dower > > wrote: >> >> (I'm not subscribed to this list, so please keep me on CC) >> >> Was there any discussion about allowing core developers to bypass any >> of the PR checks? Or was there an assumption that we'd just push >> directly to the main repo? > > See: https://mail.python.org/pipermail/core-workflow/2017-February/000884.html Thanks. The outcome of that thread (let's wait for a month) is the right one. Like Barry, I was just impatient. >> For example, most of my contributions are to do with the Windows >> installer. Due to the nature of installers, virtually nobody else is >> confident to review anything complex, or even simple ones (such as >> https://github.com/python/cpython/pull/160) due to not being able to >> predict the flow on effects. As a result, I make many small changes >> that would take a long time to get reviewed. > > > So as I said to Barry in the linked thread, part of the goal here is to > force the process between committers and non-committers to be as similar > as possible which will solve the real very real problem (that the GH > migration?s goal was to help with) that when you have two processes, a > stream lined one for those in power and a bulky slow one for those not, > that it is hard to get the bulky slow once fixed because nobody in > power ever experiences it. By aligning the two processes as much as > possible, we identify pain points are forced to solve them or deal with > them. I have absolutely no problem with requiring core devs to send PRs - I am 100% against *anyone* directly pushing to the main repo - it's just the PR approval process that is the problem. > This sounds like one such problem. If you?re the only person capable > (for skill or confidence) of reviewing these changes, what happens if > you?re unavailable for some reason? (Burnout, illness, whatever). Is > there any effort to mentor or attract additional contributors who are > able to review these changes? I?m guessing there is not, and the risk to > allowing bypassing the requirement is that there never *is* a plan to > fix it. I'd love to attract additional contributors for this. Unfortunately, working on installers on Windows is even less popular than working on OpenSSL :) > On the other hand, much like I said with Barry, it?s also possible that > these problems are special enough that we can or should just relax > restrictions in order to allow forward movement to still happen. > > >> >> Similarly, many of my changes are not touched by the automated builds. >> Particularly anything to do with the installer is certainly not going >> to be built on a Linux box, and most (probably all) Windows buildbots >> don't build the installer right now. I've seen some systems where tags >> can be applied to a PR to skip build validation - I would certainly >> find that valuable. > > This also sounds like a problem to me :) Obviously not the Linux part > (but then, burning some CPU on running the test suite on Linux isn?t > really that big of a deal is it?), but probably the installer should be > getting tested in some way? It's manually tested, and typically on the build machine where it will be actually built. Getting it into a build somewhere may be useful, but adding 5-10 minutes to *every* checkin for something that basically only I ever change seems like a waste. And you never regret burning some CPU on tests until you have more tests running than available machines. Previously we would batch test commits - I'm not sure if that's still happening or not, but that indicates some value in not spending the full time on each individual commit. But maybe there's an easy way to only trigger tests when certain files are modified? It may not make sense to set that up for each individual module, but it might be worthwhile to trigger certain extra builds when PCBuild/* or tools/msi/* are modified. >> But essentially, I believe it should be within the power of core >> developers to bypass the checkin requirements (review + builds) and >> force a merge. Currently this is not possible - could it be enabled? >> Obviously it's placing trust in our core dev team, but that's the way >> it has always been, and we don't lose any traceability from this >> (unlike allowing people to delete branches from the repo, which can >> permanently lose code). > > > I mentioned it above, but to my mind (and this is just a personal > opinion) it?s not really anything about *trust*. If we have two > different processes, we are going to make the one that we, the people in > power, use be as streamlined as possible and the other process for non > committers will *likely* end up slowly bitrotting and not keeping up > with no tooling, changes, and ideas that can make it better. Forcing > everyone onto the same process means that as we figure out and > continuously improve the process for us, it also improves it for other > people who do not have a commit bit. And as I said above, I don't think this is a different process. It's an escape hatch for the single process that's only available to certain trusted people (i.e. those who we trust to say whether code is good enough to be committed). But I'm happy to wait out the month and see if it's an issue. (Was about to write "we can all complain at the PyCon US language summit", which made me worry that if that's *all* we complain about it may be useless. For those of us who will be there, should we organise a separate workflow summit? Preferably somewhere that serves strong drinks? ;) ) Cheers, Steve From steve.dower at python.org Sun Feb 19 19:01:21 2017 From: steve.dower at python.org (Steve Dower) Date: Sun, 19 Feb 2017 16:01:21 -0800 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <0CB12202-57BF-4D44-BB93-886F8368CE7D@stufft.io> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> <0E471D97-B187-4289-AFB2-DF3396A92562@stufft.io> <3cf3ef6b-dc29-c69c-0978-5f4c748e2c89@python.org> <0CB12202-57BF-4D44-BB93-886F8368CE7D@stufft.io> Message-ID: <7a557bb0-36b9-0694-0965-c45487709060@python.org> On 19Feb2017 1554, Donald Stufft wrote: > We don?t actually have Windows tests being run at all on pull requests > (largely because AppVeyor took too long to run), though we obviously > still have the buildbot fleet running post commit. This is something we > should ideally rectify though! > > On the Travis builders, we skip running the unit tests all together if > the PR was for something that couldn?t possibly change the outcome. I?m > not familiar enough with the capabilities of the Python test runner to > know if it can mark tests somehow to be excluded by default and only run > if a certain flag is ran, if so it shouldn?t be very hard to make > something that only runs those tests on changes to PCBuilder/* or > tools/msi/*. Otherwise it might need a separate set of tests for it that > can be independently ran. I can easily get some VSTS (*.visualstudio.com) test runners going with VMs on Azure. I'm just not quite sure how to feed the results back into the github status checks right now, or how to make them publicly maintainable (that is, they'd be very much owned and only accessible by me, and likely only as long as I'm employed by Microsoft, which isn't great for sustainability - though of course anyone else can also set up the build definition and their own pool of VMs). No promises on dates, but this is something that I'll likely do regardless. I want the Windows tests as badly as anyone :) Cheers, Steve From steve.dower at python.org Tue Feb 21 16:07:57 2017 From: steve.dower at python.org (Steve Dower) Date: Tue, 21 Feb 2017 13:07:57 -0800 Subject: [core-workflow] Can core developers bypass PR checks? In-Reply-To: <5461c96e-316f-467c-8b73-9e0c8bef4d3a@timgolden.me.uk> References: <7239a228-7e1a-9cfe-8cda-958e2edc7732@python.org> <5461c96e-316f-467c-8b73-9e0c8bef4d3a@timgolden.me.uk> Message-ID: On 20Feb2017 0235, Tim Golden wrote: > On 18/02/2017 21:38, Steve Dower wrote: >> For example, most of my contributions are to do with the Windows >> installer. Due to the nature of installers, virtually nobody else is >> confident to review anything complex, or even simple ones (such as >> https://github.com/python/cpython/pull/160) due to not being able to >> predict the flow on effects. As a result, I make many small changes that >> would take a long time to get reviewed. > > Steve, tangential to the issue of self-approved PRs, can I pick up the > ball I dropped a year or so ago and propose again the idea of an online > session where you outline the elements of the Installer for, at least, > the other Windows-oriented devs and anyone else who's interested? > > The more people who can at least be aware of the what's involved the > better, I think. I agree. I am ridiculously pressed for time right now, but I would like to do a session on this. I'll try and set it up like a live talk and get some studio time here to record it and get it online somewhere. Cheers, Steve