Roundup to GitHub Issues migration

As you might know, PEP 581 (Using GitHub Issues for CPython) has been approved. I've been working with Ewa, Ee, the Working Group, the Steering Council, and the GitHub folks to make this happen, and the SC encouraged me to give you all a quick update. This effort is being tracked at <https://github.com/psf/gh-migration/projects/1>: this board reflects the current status of the project. The PEPs (including PEP 588 -- GitHub Issues Migration Plan) haven't been updated yet and might contain outdated information, so please refer to the psf/gh-migration repo for the latest updates. During the next phase I will work with the WG to sort out all the major issues that we might encounter, and then I will once again reach out to you to gather feedback from the wider audience that follows these mailing lists. Best Regards, Ezio Melotti

Hi, Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
since 2019, I've been waiting for proposed solutions to PEP 588's first open issue ("A GitHub account should not be a requirement"). Now would be the time to think about it, but I see no such reflection mentioned in the repo. Cheers, Baptiste

Hi, As a bug triager, it's very frustrating when I ask for more information about a bug, and I get no reply. Usually, such bug is closed as "out of date" (lack enough information to be debugged). The requirement for a GitHub account was well known when PEP 581 was accepted. The PEP was approved. It's now time to move on! The creation of bugs.python.org account and bugs.python.org authentication is often broken. It was common that OpenID authentication was broken for 1 month or longer. Moreover, bugs.python.org doesn't support 2FA currently, whereas GitHub does. GitHub looks more reliable *and* more secure. Also, please don't forget an important point: bugs.python.org is barely maintained. See the list of open issues: https://github.com/python/bugs.python.org/issues For example, "Not receiving email from the bug tracker" was reported 25 days ago and got no answer :-( It's all about trade-offs. Don't under estimate the cost of operating our own bug tracker. System administration is not free. Victor On Mon, Jun 21, 2021 at 11:46 AM Baptiste Carvello <devel2021@baptiste-carvello.net> wrote:
-- Night gathers, and now my watch begins. It shall not end until my death.

Hi, Le 21/06/2021 à 13:48, Victor Stinner a écrit :
There seems to be an untold assumption that non-github-users are more likely to not reply to their own bugs. Not sure why, I may lack context.
The requirement for a GitHub account was well known when PEP 581 was accepted. The PEP was approved. It's now time to move on!
PEP 588 has been saying the exact opposite for 2 years (maybe they did not really mean it, but that's what's written).
[...]
It's all about trade-offs. Don't under estimate the cost of operating our own bug tracker. System administration is not free.
Note, however, that requiring a github account for reporting bugs is a whole different trade-off than requiring it for development. The second makes python an unwelcoming project for privacy-conscious people, but I understand that such is the price to pay for more efficient freeware tools. And it's an already made choice anyway. By contrast, requiring a github account for reporting bugs also makes python an unwelcoming place for non-developers in general. Github is a developers' social network, "mere" users are much less likely to want to be part of it. Many will just silently abandon their bug report. Cheers, Baptiste

Baptiste Carvello <devel2021@baptiste-carvello.net> writes:
On Gitlab there is a "create-issue-by-email" feature, but a quick search didn't reveal an equivalent [builtin] way for Github. However, I found a few addons that implement that, for example https://fire.fundersclub.com/. Maybe that could be an acceptable compromise? ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.

But you don’t need to be “part of it” in any meaningful way. One only needs to create an account, which could be quite anonymous, and even temporary. And is no harder, and probably easier, than creating an account on a Python-specific site. Also: cPython is a large, complex, and mature project. I don't think many non-developers can even identify a true bug, much less write a helpful big report. There are many other ways to be involved in and contribute to the Python community that don't require a gitHub (or any) account. I understand the issue here — I feel that way about businesses that use Facebook for their website. But in that case, I can’t even read it without a Facebook account. I don’t mind needing an account to contribute to a conversation. And while GitHub has become the dominant player in Open Source development— it has not (yet?) reached out to control much else. -CHB

On 6/21/2021 2:31 PM, Christopher Barker wrote:
With all due respect to Microsoft, who has contributed significantly to Python development, and continues to do, some people don't care for some of Microsoft's policy and actions, and Microsoft owns GitHub, so your last paragraph is somewhat naive, at best. So what is the difference between a GitHub account, and Microsoft account? Skype used to have its own accounts... then they were converted to be Microsoft accounts... Glenn

On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman <v+python@g.nevcal.com> wrote:
They are entirely different and separate; there's no relation there at all. One thing I will remind people is I personally have led the work to move this project from: 1. SourceForge to our own infrastructure 2. Mercurial to git 3. Our own infrastructure to GitHub for code management So if GitHub were to do something we don't like we can always move platforms again.

On Tue., Jun. 22, 2021, 14:50 Glenn Linderman, <v+python@g.nevcal.com> wrote:
You can choose to view that as a one-off or indicative of a pattern. I'm choosing the former (you can use the LinkedIn acquisition as support for my view).
Sure, but I don't think anyone is about to argue we should have stayed on SF. Nor are there plans to switch off of GitHub. Regardless, there are no plans to halt what was decided when we accepted PEP 581. Most of the concerns which have been brought up in this thread were already expressed back then (the account merge one I didn't remember, hence why I replied).

On Wed, 23 Jun 2021 at 01:21, Brett Cannon <brett@python.org> wrote:
Regardless, there are no plans to halt what was decided when we accepted PEP 581. Most of the concerns which have been brought up in this thread were already expressed back then (the account merge one I didn't remember, hence why I replied).
I don't have a strong opinion regarding the use of github accounts, but just to note, this thread was about the open issue in PEP 588, not about PEP 581 - https://www.python.org/dev/peps/pep-0588/#a-github-account-should-not-be-a-r.... PEP 588 has not been accepted, so it's not necessarily relevant to the actual migration plan here, but I do think it's reasonable to ask for some clarification. Either PEP 588 should be rejectected, noting that the actual implementation plan is being maintained differently, or it should be updated as an ongoing document as the planning process goes ahead. I suspect the update on this particular open question might well be "the problem was considered, and ultimately it was concluded that requiring a github account was not a showstopper". That may not please some people (I don't personally care) but that's fine - not everything has to be unanimous, as long as the SC approves. Paul

On Jun 23, 2021, at 03:21, Paul Moore <p.f.moore@gmail.com> wrote:
Mariatta is the author of PEP 588 and I’m the delegate. Given how old that PEP is and the fact that Ezio is managing the project elsewhere, I think rejection is appropriate. However if we do that I think the PEP should at least be updated with references to Ezio’s project, with some verbiage added as to why these changes are being made. What do you think, Mariatta? -Barry

My understanding is that Ezio is/will be working on updating PEP 588. Last I heard from Ezio is that he would be co-author of PEP 588 and he would be updating it/rewrite it to better match the current migration plan. I will check with Ezio and the gh-migration group on the status. Thanks. On Wed, Jun 23, 2021 at 10:33 AM Barry Warsaw <barry@python.org> wrote:

On 6/22/2021 3:52 PM, Brett Cannon wrote:
At this point, I (once a skeptic) agree that the migration is an overall improvement, with CI being the roughest. As for issue migration: github PRs are much 'richer' in info than Rietveld reviews, and there is now duplication of information with bpo issues. (Where synchonization is not automated, this can be a nuisance.) This means to me that the github issue metadata can be simplified. After making the migration easier, this will mean less bad metadata to be corrected by triagers. With 2.x gone and a backport flow, essentially all issues are for main, so leave version tags off the issue (and eliminate the need to update them!). [3.x] in PR titles and backport labels are enough. Backport labels imply 'behavior' versus 'enhancement. Stage info is also on the PR. -- Terry Jan Reedy

On Tue, Jun 22, 2021 at 11:22 PM Terry Reedy <tjreedy@udel.edu> wrote:
For enhancement requests I agree we probably don't need to keep updating the version (though it might be useful to know which version the user was looking at when coming up with the suggestion). But I think for a bug report it's useful to know the most recent version on which the bug was reproduced. A large part of triage work is to check whether a bug report is still relevant. If you see "version 3.5" then it makes sense to check on a current version and either update the issue or close it.

On Jun 22, 2021, at 18:35, Irit Katriel via Python-Dev <python-dev@python.org> wrote:
I think this points out a problem with our current bug system and one that it would be good to try to resolve in migrating to a new system: that is, the ambiguity of the "version" metadata in an issue. Today, that list of versions is used in at least three different ways: 1. to document in what Python versions the issue is present; 2. to document in what Python versions the issue should be fixed, 3. to document in what versions the issue was fixed. In many, probably most, cases, the "version" field of a particular issue is used in both ways. When the issue is opened, the version is often set to the versions affected. Then at various stages in its lifecycle, the issue's version field will generally be changed to (possibly) reflect the candidate versions for potential fixes (based on current policy) and later (possibly) to the versions for which a fix was actually merged. The various sets of versions are useful information for different purposes. It would be good to try to find a way to retain both, i.e. something like "affected versions", "targeted versions", and "fixed versions". In any case, resolving the current ambiguity would be good and could also save triage and housekeeping work. -- Ned Deily nad@python.org -- []

On Jun 22, 2021, at 15:52, Brett Cannon <brett@python.org> wrote:
While I personally don’t think it will ever be necessary, one out would be a GitLab instance we stand up ourselves. It doesn’t look to be too hard to migrate from GitHub to GitLab: https://docs.gitlab.com/ee/user/project/import/github.html Of course, that would still be infrastructure we’d have to run (unless we used gitlab.com, but then some people might still object), and that migration would also have to deal with Roundup issues if we don’t complete that migration. -Barry

Hi, Le 21/06/2021 à 23:31, Christopher Barker a écrit :
I don't believe you can actually use temporary accounts. Github only allows one account per physical person, and if I delete my account, then later open a new one from the same IP and/or with a related e-mail address, I would expect them to either blocklist me, or resurrect the old account and copy the data to the new one. If anyone really tried, please correct me.
There is a genuine question here: bluntly said, are bug reports still welcome? In the tradition of the Free Software movement, reporting bugs is considered an act of good citizenship. If the scarcity of developer time makes it no longer be the case for cPython, it'd rather be broadly communicated to users.
[...] I don’t mind needing an account to contribute to a conversation.
I do, if a single company becomes the gatekeeper of most conversations in a whole field of endeavor. Alas, I have to admit being in the minority, so let this part of the discussion rest. Cheers, Baptiste

On 6/22/2021 4:40 AM, Baptiste Carvello wrote:
There is a genuine question here: bluntly said, are bug reports still welcome?
The above is one person's viewpoint. Since he is not a CPython core developer, I am not sure what he means by 'developer'. Anyone who programs in Python 'developes' the programs they write. It is true that students and beginners tend to make less useful reports. But yes, bug reports are still welcome.
What we need is for people to be less shy about helping with *other* people's reports. -- Terry Jan Reedy

Hi, On Mon 21 Jun, 13:48 +0200, Victor Stinner <vstinner@python.org> wrote:
The requirement for a GitHub account was well known when PEP 581 was accepted. The PEP was approved. It's now time to move on!
I think it is important to notice that GitHub actively blocks user registration and activity from countries that are sanctioned by the US government. At least in 2019 GitHub was blocking users from IPs located in Cuba, North Corea, Syria, Crimea, Iran, etc (see for example [1]). They block, of course, users of any nationality, if they happen to be traveling or living in those countries. I could not find any clear official statement from GitHub, but I think this is something to consider nonetheless, especially now that the Python community is making great efforts to become more welcoming and diverse. The fact of excluding a significant part of the potential contributors based on a random list by a random government over which the Python community as a whole has no influence whatsoever seems a move in the wrong direction. My 2c, Tiziano [1] https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/

Am 22.06.21 um 10:00 schrieb Tiziano Zito:
I was overall in favor of moving Python issues over to GitHub, for convenience, easier access, and a more usable interface. But I think the issue above is a showstopper. This problem of course already exists for pull requests, but discriminating against users based on their place of residence is absolutely unacceptable to me. In fact, it is directly in violation to the PSF's mission statement that says in part: "... to support and facilitate the growth of a diverse and international community of Python programmers." This issue hasn't been addresses in PEP 581, so I believe it wasn't considered when accepting the PEP. But it's serious enough that I would like to ask the steering council to reconsider their decision to accept PEP 581. - Sebastian

On Tue, Jun 22, 2021 at 4:42 AM Sebastian Rittau <srittau@rittau.biz> wrote:
As much as we might wish otherwise, the PSF is also a US entity and has to comply with US laws. GitHub's official policy at https://docs.github.com/en/github/site-policy/github-and-trade-controls gives the impression that they're reading the law as narrowly as possible, and allowing access to every person that they legally can. In particular, that policy page claims that there are no restrictions on users from Cuba or Iran, and that users from Syria and Crimea are allowed to participate in OSS projects, just not give GitHub money. (They do disallow use by North Koreans and "Specially Designated Nationals".) It is even possible for the PSF to do better without breaking the law? I'm not an expert in this area at all, so happy to be educated if so... -n -- Nathaniel J. Smith -- https://vorpus.org

On Tue, 22 Jun 2021 05:01:17 -0700 Nathaniel Smith <njs@pobox.com> wrote:
This would be worth checking if possible. If individuals of any country (mostly? except North Korea?) are able to participate as volunteers, then it may be fine, otherwise it is very worrying. But the question is also whether Github might change its policy in the future.
It is even possible for the PSF to do better without breaking the law?
Who knows, the PSF might be breaking the law already (or not). The question is whether authorities would be interested in going after a smallish community of individuals (compared to the Github user base, python-dev is negligible). Also, the python-dev community may always contemplate a move under a different umbrella if necessary. Github won't change its umbrella to just to make things easier for us. Regards Antoine.

(For some weird reason, I didn't get this mail via the list, only the private copy, so I might break threading by replying via my private copy.) Am 22.06.21 um 14:01 schrieb Nathaniel Smith:
I'm not much interested in theory. Are people currently blocked from participating in Python issues due to their country of residence? Will people be blocked after the move to GitHub? If the answer to the second question is "yes", the move would violate one of the core principles of the PSF. If the answer to the first question is "yes", we need to consider transferring the bug tracker to an organization in a country whose laws better align with the goals of the PSF. - Sebastian

This is perhaps a different issue, but perhaps not. PSF grants are also subject to absurd and convoluted (and difficult to interpret) "export control" rules. Also rules subject to change at any moment at the whims of the latest US government grandstanding. USA incorporation definitely has drawbacks, as well as advantages. On Tue, Jun 22, 2021, 7:46 AM Sebastian Rittau <srittau@rittau.biz> wrote:

On 6/22/2021 4:00 AM, Tiziano Zito wrote:
[1] https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/
It says that this applied to private repositories and paid organization repositories but not public, open source repositories. I don't know if the forks of python needed to submit PRs are affected, but I belive these are both free and public. https://docs.github.com/en/github/site-policy/github-and-trade-controls Says that Github has an explicit license to serve Iran and most services are available in Cuba. -- Terry Jan Reedy

FWIW, GitHub announced new powerful Issues today. https://github.com/features/issues It may fill some gap between GitHub Issues and Roundup. Regards, -- Inada Naoki <songofacandy@gmail.com>

FWIW, GitHub announced new powerful Issues today.
I have asked GitHub to enable it for the Python org.

Hi Ezio, What is the status of the migration of Python issues from bugs.python.org (Roundup) to GitHub? Is it still a work-in-progress or is it stalled? Victor On Mon, Jun 21, 2021 at 4:20 AM Ezio Melotti <ezio.melotti@gmail.com> wrote:
-- Night gathers, and now my watch begins. It shall not end until my death.

Hi, Le 21/06/2021 à 04:20, Ezio Melotti a écrit :
since 2019, I've been waiting for proposed solutions to PEP 588's first open issue ("A GitHub account should not be a requirement"). Now would be the time to think about it, but I see no such reflection mentioned in the repo. Cheers, Baptiste

Hi, As a bug triager, it's very frustrating when I ask for more information about a bug, and I get no reply. Usually, such bug is closed as "out of date" (lack enough information to be debugged). The requirement for a GitHub account was well known when PEP 581 was accepted. The PEP was approved. It's now time to move on! The creation of bugs.python.org account and bugs.python.org authentication is often broken. It was common that OpenID authentication was broken for 1 month or longer. Moreover, bugs.python.org doesn't support 2FA currently, whereas GitHub does. GitHub looks more reliable *and* more secure. Also, please don't forget an important point: bugs.python.org is barely maintained. See the list of open issues: https://github.com/python/bugs.python.org/issues For example, "Not receiving email from the bug tracker" was reported 25 days ago and got no answer :-( It's all about trade-offs. Don't under estimate the cost of operating our own bug tracker. System administration is not free. Victor On Mon, Jun 21, 2021 at 11:46 AM Baptiste Carvello <devel2021@baptiste-carvello.net> wrote:
-- Night gathers, and now my watch begins. It shall not end until my death.

Hi, Le 21/06/2021 à 13:48, Victor Stinner a écrit :
There seems to be an untold assumption that non-github-users are more likely to not reply to their own bugs. Not sure why, I may lack context.
The requirement for a GitHub account was well known when PEP 581 was accepted. The PEP was approved. It's now time to move on!
PEP 588 has been saying the exact opposite for 2 years (maybe they did not really mean it, but that's what's written).
[...]
It's all about trade-offs. Don't under estimate the cost of operating our own bug tracker. System administration is not free.
Note, however, that requiring a github account for reporting bugs is a whole different trade-off than requiring it for development. The second makes python an unwelcoming project for privacy-conscious people, but I understand that such is the price to pay for more efficient freeware tools. And it's an already made choice anyway. By contrast, requiring a github account for reporting bugs also makes python an unwelcoming place for non-developers in general. Github is a developers' social network, "mere" users are much less likely to want to be part of it. Many will just silently abandon their bug report. Cheers, Baptiste

Baptiste Carvello <devel2021@baptiste-carvello.net> writes:
On Gitlab there is a "create-issue-by-email" feature, but a quick search didn't reveal an equivalent [builtin] way for Github. However, I found a few addons that implement that, for example https://fire.fundersclub.com/. Maybe that could be an acceptable compromise? ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.

But you don’t need to be “part of it” in any meaningful way. One only needs to create an account, which could be quite anonymous, and even temporary. And is no harder, and probably easier, than creating an account on a Python-specific site. Also: cPython is a large, complex, and mature project. I don't think many non-developers can even identify a true bug, much less write a helpful big report. There are many other ways to be involved in and contribute to the Python community that don't require a gitHub (or any) account. I understand the issue here — I feel that way about businesses that use Facebook for their website. But in that case, I can’t even read it without a Facebook account. I don’t mind needing an account to contribute to a conversation. And while GitHub has become the dominant player in Open Source development— it has not (yet?) reached out to control much else. -CHB

On 6/21/2021 2:31 PM, Christopher Barker wrote:
With all due respect to Microsoft, who has contributed significantly to Python development, and continues to do, some people don't care for some of Microsoft's policy and actions, and Microsoft owns GitHub, so your last paragraph is somewhat naive, at best. So what is the difference between a GitHub account, and Microsoft account? Skype used to have its own accounts... then they were converted to be Microsoft accounts... Glenn

On Mon, Jun 21, 2021 at 4:09 PM Glenn Linderman <v+python@g.nevcal.com> wrote:
They are entirely different and separate; there's no relation there at all. One thing I will remind people is I personally have led the work to move this project from: 1. SourceForge to our own infrastructure 2. Mercurial to git 3. Our own infrastructure to GitHub for code management So if GitHub were to do something we don't like we can always move platforms again.

On Tue., Jun. 22, 2021, 14:50 Glenn Linderman, <v+python@g.nevcal.com> wrote:
You can choose to view that as a one-off or indicative of a pattern. I'm choosing the former (you can use the LinkedIn acquisition as support for my view).
Sure, but I don't think anyone is about to argue we should have stayed on SF. Nor are there plans to switch off of GitHub. Regardless, there are no plans to halt what was decided when we accepted PEP 581. Most of the concerns which have been brought up in this thread were already expressed back then (the account merge one I didn't remember, hence why I replied).

On Wed, 23 Jun 2021 at 01:21, Brett Cannon <brett@python.org> wrote:
Regardless, there are no plans to halt what was decided when we accepted PEP 581. Most of the concerns which have been brought up in this thread were already expressed back then (the account merge one I didn't remember, hence why I replied).
I don't have a strong opinion regarding the use of github accounts, but just to note, this thread was about the open issue in PEP 588, not about PEP 581 - https://www.python.org/dev/peps/pep-0588/#a-github-account-should-not-be-a-r.... PEP 588 has not been accepted, so it's not necessarily relevant to the actual migration plan here, but I do think it's reasonable to ask for some clarification. Either PEP 588 should be rejectected, noting that the actual implementation plan is being maintained differently, or it should be updated as an ongoing document as the planning process goes ahead. I suspect the update on this particular open question might well be "the problem was considered, and ultimately it was concluded that requiring a github account was not a showstopper". That may not please some people (I don't personally care) but that's fine - not everything has to be unanimous, as long as the SC approves. Paul

On Jun 23, 2021, at 03:21, Paul Moore <p.f.moore@gmail.com> wrote:
Mariatta is the author of PEP 588 and I’m the delegate. Given how old that PEP is and the fact that Ezio is managing the project elsewhere, I think rejection is appropriate. However if we do that I think the PEP should at least be updated with references to Ezio’s project, with some verbiage added as to why these changes are being made. What do you think, Mariatta? -Barry

My understanding is that Ezio is/will be working on updating PEP 588. Last I heard from Ezio is that he would be co-author of PEP 588 and he would be updating it/rewrite it to better match the current migration plan. I will check with Ezio and the gh-migration group on the status. Thanks. On Wed, Jun 23, 2021 at 10:33 AM Barry Warsaw <barry@python.org> wrote:

On 6/22/2021 3:52 PM, Brett Cannon wrote:
At this point, I (once a skeptic) agree that the migration is an overall improvement, with CI being the roughest. As for issue migration: github PRs are much 'richer' in info than Rietveld reviews, and there is now duplication of information with bpo issues. (Where synchonization is not automated, this can be a nuisance.) This means to me that the github issue metadata can be simplified. After making the migration easier, this will mean less bad metadata to be corrected by triagers. With 2.x gone and a backport flow, essentially all issues are for main, so leave version tags off the issue (and eliminate the need to update them!). [3.x] in PR titles and backport labels are enough. Backport labels imply 'behavior' versus 'enhancement. Stage info is also on the PR. -- Terry Jan Reedy

On Tue, Jun 22, 2021 at 11:22 PM Terry Reedy <tjreedy@udel.edu> wrote:
For enhancement requests I agree we probably don't need to keep updating the version (though it might be useful to know which version the user was looking at when coming up with the suggestion). But I think for a bug report it's useful to know the most recent version on which the bug was reproduced. A large part of triage work is to check whether a bug report is still relevant. If you see "version 3.5" then it makes sense to check on a current version and either update the issue or close it.

On Jun 22, 2021, at 18:35, Irit Katriel via Python-Dev <python-dev@python.org> wrote:
I think this points out a problem with our current bug system and one that it would be good to try to resolve in migrating to a new system: that is, the ambiguity of the "version" metadata in an issue. Today, that list of versions is used in at least three different ways: 1. to document in what Python versions the issue is present; 2. to document in what Python versions the issue should be fixed, 3. to document in what versions the issue was fixed. In many, probably most, cases, the "version" field of a particular issue is used in both ways. When the issue is opened, the version is often set to the versions affected. Then at various stages in its lifecycle, the issue's version field will generally be changed to (possibly) reflect the candidate versions for potential fixes (based on current policy) and later (possibly) to the versions for which a fix was actually merged. The various sets of versions are useful information for different purposes. It would be good to try to find a way to retain both, i.e. something like "affected versions", "targeted versions", and "fixed versions". In any case, resolving the current ambiguity would be good and could also save triage and housekeeping work. -- Ned Deily nad@python.org -- []

On Jun 22, 2021, at 15:52, Brett Cannon <brett@python.org> wrote:
While I personally don’t think it will ever be necessary, one out would be a GitLab instance we stand up ourselves. It doesn’t look to be too hard to migrate from GitHub to GitLab: https://docs.gitlab.com/ee/user/project/import/github.html Of course, that would still be infrastructure we’d have to run (unless we used gitlab.com, but then some people might still object), and that migration would also have to deal with Roundup issues if we don’t complete that migration. -Barry

Hi, Le 21/06/2021 à 23:31, Christopher Barker a écrit :
I don't believe you can actually use temporary accounts. Github only allows one account per physical person, and if I delete my account, then later open a new one from the same IP and/or with a related e-mail address, I would expect them to either blocklist me, or resurrect the old account and copy the data to the new one. If anyone really tried, please correct me.
There is a genuine question here: bluntly said, are bug reports still welcome? In the tradition of the Free Software movement, reporting bugs is considered an act of good citizenship. If the scarcity of developer time makes it no longer be the case for cPython, it'd rather be broadly communicated to users.
[...] I don’t mind needing an account to contribute to a conversation.
I do, if a single company becomes the gatekeeper of most conversations in a whole field of endeavor. Alas, I have to admit being in the minority, so let this part of the discussion rest. Cheers, Baptiste

On 6/22/2021 4:40 AM, Baptiste Carvello wrote:
There is a genuine question here: bluntly said, are bug reports still welcome?
The above is one person's viewpoint. Since he is not a CPython core developer, I am not sure what he means by 'developer'. Anyone who programs in Python 'developes' the programs they write. It is true that students and beginners tend to make less useful reports. But yes, bug reports are still welcome.
What we need is for people to be less shy about helping with *other* people's reports. -- Terry Jan Reedy

Hi, On Mon 21 Jun, 13:48 +0200, Victor Stinner <vstinner@python.org> wrote:
The requirement for a GitHub account was well known when PEP 581 was accepted. The PEP was approved. It's now time to move on!
I think it is important to notice that GitHub actively blocks user registration and activity from countries that are sanctioned by the US government. At least in 2019 GitHub was blocking users from IPs located in Cuba, North Corea, Syria, Crimea, Iran, etc (see for example [1]). They block, of course, users of any nationality, if they happen to be traveling or living in those countries. I could not find any clear official statement from GitHub, but I think this is something to consider nonetheless, especially now that the Python community is making great efforts to become more welcoming and diverse. The fact of excluding a significant part of the potential contributors based on a random list by a random government over which the Python community as a whole has no influence whatsoever seems a move in the wrong direction. My 2c, Tiziano [1] https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/

Am 22.06.21 um 10:00 schrieb Tiziano Zito:
I was overall in favor of moving Python issues over to GitHub, for convenience, easier access, and a more usable interface. But I think the issue above is a showstopper. This problem of course already exists for pull requests, but discriminating against users based on their place of residence is absolutely unacceptable to me. In fact, it is directly in violation to the PSF's mission statement that says in part: "... to support and facilitate the growth of a diverse and international community of Python programmers." This issue hasn't been addresses in PEP 581, so I believe it wasn't considered when accepting the PEP. But it's serious enough that I would like to ask the steering council to reconsider their decision to accept PEP 581. - Sebastian

On Tue, Jun 22, 2021 at 4:42 AM Sebastian Rittau <srittau@rittau.biz> wrote:
As much as we might wish otherwise, the PSF is also a US entity and has to comply with US laws. GitHub's official policy at https://docs.github.com/en/github/site-policy/github-and-trade-controls gives the impression that they're reading the law as narrowly as possible, and allowing access to every person that they legally can. In particular, that policy page claims that there are no restrictions on users from Cuba or Iran, and that users from Syria and Crimea are allowed to participate in OSS projects, just not give GitHub money. (They do disallow use by North Koreans and "Specially Designated Nationals".) It is even possible for the PSF to do better without breaking the law? I'm not an expert in this area at all, so happy to be educated if so... -n -- Nathaniel J. Smith -- https://vorpus.org

On Tue, 22 Jun 2021 05:01:17 -0700 Nathaniel Smith <njs@pobox.com> wrote:
This would be worth checking if possible. If individuals of any country (mostly? except North Korea?) are able to participate as volunteers, then it may be fine, otherwise it is very worrying. But the question is also whether Github might change its policy in the future.
It is even possible for the PSF to do better without breaking the law?
Who knows, the PSF might be breaking the law already (or not). The question is whether authorities would be interested in going after a smallish community of individuals (compared to the Github user base, python-dev is negligible). Also, the python-dev community may always contemplate a move under a different umbrella if necessary. Github won't change its umbrella to just to make things easier for us. Regards Antoine.

(For some weird reason, I didn't get this mail via the list, only the private copy, so I might break threading by replying via my private copy.) Am 22.06.21 um 14:01 schrieb Nathaniel Smith:
I'm not much interested in theory. Are people currently blocked from participating in Python issues due to their country of residence? Will people be blocked after the move to GitHub? If the answer to the second question is "yes", the move would violate one of the core principles of the PSF. If the answer to the first question is "yes", we need to consider transferring the bug tracker to an organization in a country whose laws better align with the goals of the PSF. - Sebastian

This is perhaps a different issue, but perhaps not. PSF grants are also subject to absurd and convoluted (and difficult to interpret) "export control" rules. Also rules subject to change at any moment at the whims of the latest US government grandstanding. USA incorporation definitely has drawbacks, as well as advantages. On Tue, Jun 22, 2021, 7:46 AM Sebastian Rittau <srittau@rittau.biz> wrote:

On 6/22/2021 4:00 AM, Tiziano Zito wrote:
[1] https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/
It says that this applied to private repositories and paid organization repositories but not public, open source repositories. I don't know if the forks of python needed to submit PRs are affected, but I belive these are both free and public. https://docs.github.com/en/github/site-policy/github-and-trade-controls Says that Github has an explicit license to serve Iran and most services are available in Cuba. -- Terry Jan Reedy

FWIW, GitHub announced new powerful Issues today. https://github.com/features/issues It may fill some gap between GitHub Issues and Roundup. Regards, -- Inada Naoki <songofacandy@gmail.com>

FWIW, GitHub announced new powerful Issues today.
I have asked GitHub to enable it for the Python org.

Hi Ezio, What is the status of the migration of Python issues from bugs.python.org (Roundup) to GitHub? Is it still a work-in-progress or is it stalled? Victor On Mon, Jun 21, 2021 at 4:20 AM Ezio Melotti <ezio.melotti@gmail.com> wrote:
-- Night gathers, and now my watch begins. It shall not end until my death.
participants (19)
-
Antoine Pitrou
-
Baptiste Carvello
-
Barry Warsaw
-
Brett Cannon
-
Christopher Barker
-
David Mertz
-
Ezio Melotti
-
Glenn Linderman
-
Inada Naoki
-
Irit Katriel
-
Lele Gaifax
-
Mariatta
-
Nathaniel Smith
-
Ned Deily
-
Paul Moore
-
Sebastian Rittau
-
Terry Reedy
-
Tiziano Zito
-
Victor Stinner