Github Mirrors - Should Disallow Pull Request / Issue Creation Until the migration
I noticed two issues wherein the reporters were confused with the github mirrors of cpython. 1. http://bugs.python.org/issue25435#msg253159 A pull request was raised against the github mirror. 2. http://bugs.python.org/issue27466 Issue was raised against a github mirror: https://github.com/python-git/python/issues/6 This project, https://github.com/python-git should either redirect to github.com/python or shutdown. And the github.com/python project should disallow Pull Request / Issue Creation. Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread. Thank you, Senthil
I know you can disable issues for a repo on GitHub, but I don't think you can disable PRs, unfortunately.
Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread.
You might be able to nicely ask GitHub support. There are some github feature that can be activated only by them for some good reasons, for example detaching a fork. If it's still not possible, the-knights-who-says-ni[1] could help with auto responding/closing. -- M [1]: https://github.com/python/the-knights-who-say-ni
The problem with the python-tutor org is we don't control it and we don't know whose it is. As for turning off the PRs for Python/cpython, GH doesn't provide a way to do that. Best we can do is reply to the PRs to say the repo is just a mirror and PRs are not accepted and get the transition done sooner rather than later (hoping to get the devguide moved this month; need to schedule it with the PDF infra team). On Fri, Jul 8, 2016, 18:30 Senthil Kumaran <senthil@uthcode.com> wrote:
I noticed two issues wherein the reporters were confused with the github mirrors of cpython.
1. http://bugs.python.org/issue25435#msg253159
A pull request was raised against the github mirror.
2. http://bugs.python.org/issue27466
Issue was raised against a github mirror: https://github.com/python-git/python/issues/6
This project, https://github.com/python-git should either redirect to github.com/python or shutdown. And the github.com/python project should disallow Pull Request / Issue Creation.
Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread.
Thank you, Senthil
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
python-tutor => python-git (-: On Sat, Jul 09, 2016 at 03:59:04PM +0000, Brett Cannon <brett@python.org> wrote:
The problem with the python-tutor org is we don't control it and we don't know whose it is.
Issue was raised against a github mirror: https://github.com/python-git/python/issues/6
This project, https://github.com/python-git should either redirect to github.com/python or shutdown.
Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
Hi Brett, One thing that could be done is to use a pull request template to notify users BEFORE they make a PR that the CPython mirror is not the correct place to submit contributions. See https://github.com/python/cpython/pull/41 as an example of the template. Carol \--- Carol Willing Research Software Engineer Project Jupyter @ Cal Poly SLO Director, Python Software Foundation _Signature strengths_ _Empathy - Relator - Ideation - Strategic - Learner_  On Jul 9 2016, at 8:59 am, Brett Cannon <brett@python.org> wrote:
The problem with the python-tutor org is we don't control it and we don't know whose it is.
As for turning off the PRs for Python/cpython, GH doesn't provide a way to do that. Best we can do is reply to the PRs to say the repo is just a mirror and PRs are not accepted and get the transition done sooner rather than later (hoping to get the devguide moved this month; need to schedule it with the PDF infra team).
On Fri, Jul 8, 2016, 18:30 Senthil Kumaran <[senthil@uthcode.com](mailto:senthil@uthcode.com)> wrote:
I noticed two issues wherein the reporters were confused with the github mirrors of cpython.
A pull request was raised against the github mirror.
Issue was raised against a github mirror: [https://github.com/python- git/python/issues/6](https://github.com/python- git/python/issues/6&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn)
This project, [https://github.com/python-git](https://github.com/python- git&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) should either redirect to [github.com/python](http://github.com/python&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) or shutdown.
And the [github.com/python](http://github.com/python&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) project should disallow Pull Request / Issue Creation.
Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread.
Thank you,
Senthil
_______________________________________________ core-workflow mailing list [core-workflow@python.org](mailto:core-workflow@python.org) [https://mail.python.org/mailman/listinfo/core- workflow](https://mail.python.org/mailman/listinfo/core- workflow&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) This list is governed by the PSF Code of Conduct: [https://www.python.org/psf/codeofconduct](https://www.python.org/psf/codeofconduct&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn)
On Sat, 9 Jul 2016 at 13:01 Carol Willing <willingc@willingconsulting.com> wrote:
Hi Brett,
One thing that could be done is to use a pull request template to notify users BEFORE they make a PR that the CPython mirror is not the correct place to submit contributions.
See https://github.com/python/cpython/pull/41 as an example of the template.
The problem with a template is it has to be checked into the cpython repository which will make sense once we migrate, but I don't know if it does while we are not moved over yet. -Brett
Carol
--- Carol Willing
Research Software Engineer Project Jupyter @ Cal Poly SLO
Director, Python Software Foundation
*Signature strengths* *Empathy - Relator - Ideation - Strategic - Learner*
On Jul 9 2016, at 8:59 am, Brett Cannon <brett@python.org> wrote:
The problem with the python-tutor org is we don't control it and we don't know whose it is.
As for turning off the PRs for Python/cpython, GH doesn't provide a way to do that. Best we can do is reply to the PRs to say the repo is just a mirror and PRs are not accepted and get the transition done sooner rather than later (hoping to get the devguide moved this month; need to schedule it with the PDF infra team).
On Fri, Jul 8, 2016, 18:30 Senthil Kumaran <senthil@uthcode.com> wrote:
I noticed two issues wherein the reporters were confused with the github mirrors of cpython.
1. http://bugs.python.org/issue25435#msg253159 <http://bugs.python.org/issue25435#msg253159&r=YnJldHRAcHl0aG9uLm9yZw==>
A pull request was raised against the github mirror.
2. http://bugs.python.org/issue27466 <http://bugs.python.org/issue27466&r=YnJldHRAcHl0aG9uLm9yZw==>
Issue was raised against a github mirror: https://github.com/python-git/python/issues/6 <https://github.com/python-git/python/issues/6&r=YnJldHRAcHl0aG9uLm9yZw==>
This project, https://github.com/python-git <https://github.com/python-git&r=YnJldHRAcHl0aG9uLm9yZw==> should either redirect to github.com/python <http://github.com/python&r=YnJldHRAcHl0aG9uLm9yZw==> or shutdown. And the github.com/python <http://github.com/python&r=YnJldHRAcHl0aG9uLm9yZw==> project should disallow Pull Request / Issue Creation.
Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread.
Thank you, Senthil
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow <https://mail.python.org/mailman/listinfo/core-workflow&r=YnJldHRAcHl0aG9uLm9yZw==> This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct <https://www.python.org/psf/codeofconduct&r=YnJldHRAcHl0aG9uLm9yZw==>
 On Jul 9 2016, at 6:12 pm, Brett Cannon <brett@python.org> wrote:
On Sat, 9 Jul 2016 at 13:01 Carol Willing <[willingc@willingconsulting.com](mailto:willingc@willingconsulting.com)> wrote:
Hi Brett,
One thing that could be done is to use a pull request template to notify users BEFORE they make a PR that the CPython mirror is not the correct place to submit contributions.
See [https://github.com/python/cpython/pull/41](https://github.com/python/cpython/pull/41&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) as an example of the template.
The problem with a template is it has to be checked into the cpython repository which will make sense once we migrate, but I don't know if it does while we are not moved over yet.
I was thinking that you could check-in to the GitHub mirror in a .git directory unless mirroring would blow it away each update. I wasn't thinking it would need to be in the hg hosting of CPython code. Removing it once the migration happens.
-Brett
Carol
\---
Carol Willing
Research Software Engineer
Project Jupyter @ Cal Poly SLO
Director, Python Software Foundation
_Signature strengths_
_Empathy - Relator - Ideation - Strategic - Learner_
On Jul 9 2016, at 8:59 am, Brett Cannon <[brett@python.org](mailto:brett@python.org)> wrote:
The problem with the python-tutor org is we don't control it and we don't know whose it is.
As for turning off the PRs for Python/cpython, GH doesn't provide a way to do that. Best we can do is reply to the PRs to say the repo is just a mirror and PRs are not accepted and get the transition done sooner rather than later (hoping to get the devguide moved this month; need to schedule it with the PDF infra team).
On Fri, Jul 8, 2016, 18:30 Senthil Kumaran <[senthil@uthcode.com](mailto:senthil@uthcode.com)> wrote:
I noticed two issues wherein the reporters were confused with the github mirrors of cpython.
A pull request was raised against the github mirror.
Issue was raised against a github mirror: [https://github.com/python- git/python/issues/6](https://github.com/python- git/python/issues/6&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn)
This project, [https://github.com/python-git](https://github.com/python- git&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) should either redirect to [github.com/python](http://github.com/python&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) or shutdown.
And the [github.com/python](http://github.com/python&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) project should disallow Pull Request / Issue Creation.
Who can I work with (in the python infra team) to accomplish these things? Also if anyone else has suggestions please share it in this email thread.
Thank you,
Senthil
_______________________________________________ core-workflow mailing list [core-workflow@python.org](mailto:core-workflow@python.org) [https://mail.python.org/mailman/listinfo/core- workflow](https://mail.python.org/mailman/listinfo/core- workflow&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) This list is governed by the PSF Code of Conduct: [https://www.python.org/psf/codeofconduct](https://www.python.org/psf/codeofconduct&r=YnJldHRAcHl0aG9uLm9yZw==&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn)
On 10 July 2016 at 11:12, Brett Cannon <brett@python.org> wrote:
On Sat, 9 Jul 2016 at 13:01 Carol Willing <willingc@willingconsulting.com> wrote:
Hi Brett,
One thing that could be done is to use a pull request template to notify users BEFORE they make a PR that the CPython mirror is not the correct place to submit contributions.
See https://github.com/python/cpython/pull/41 as an example of the template.
The problem with a template is it has to be checked into the cpython repository which will make sense once we migrate, but I don't know if it does while we are not moved over yet.
I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sun, Jul 10, 2016 at 12:15 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it?
I am in favor of introducing this before the migration. It seems like an easy thing to setup without any clutter to the existing setup. For e.g, for the pull request template, We can have the PULL_REQUEST_TEMPLATE.md as suggested by Carol inside a .github directory in hg repo and communicate our intention. That should address one of the points in this thread. Thanks, Senthil
On Sun, Jul 10, 2016 at 4:33 PM, Senthil Kumaran <senthil@uthcode.com> wrote:
On Sun, Jul 10, 2016 at 12:15 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it?
I am in favor of introducing this before the migration. It seems like an easy thing to setup without any clutter to the existing setup. For e.g, for the pull request template, We can have the PULL_REQUEST_TEMPLATE.md as suggested by Carol inside a .github directory in hg repo and communicate our intention. That should address one of the points in this thread.
I'm not sure how that would solve the main problem: People do not like to read project descriptions and contribution guides :) python/cpython description already states that it's a read-only mirror of the Mercurial repository and it took me a second to realize that python-git/python is a way outdated mirror of the old SVN repository. I'd propose to set a webhook that will close all pull requests automatically (with a short informative message) on python/cpython. I'm planning to finish my merge bot this month so I can write a simple webhook quickly if needed. --Berker
 On Jul 10 2016, at 7:20 am, Berker Peksağ <berker.peksag@gmail.com> wrote:
On Sun, Jul 10, 2016 at 4:33 PM, Senthil Kumaran <senthil@uthcode.com> wrote: > On Sun, Jul 10, 2016 at 12:15 AM, Nick Coghlan <ncoghlan@gmail.com> wrote: >> >> I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it? > > > I am in favor of introducing this before the migration. It seems like > an easy thing to setup without any clutter to the existing setup. > For e.g, for the pull request template, We can have the > PULL_REQUEST_TEMPLATE.md as suggested by Carol inside a .github > directory in hg repo and communicate our intention. That should > address one of the points in this thread.
I'm not sure how that would solve the main problem: People do not like to read project descriptions and contribution guides :)
The template is a simple courtesy to alert those opening a PR on the repo that it's not the right place. Of course, people might still not read it ;-)
python/cpython description already states that it's a read-only mirror of the Mercurial repository and it took me a second to realize that python-git/python is a way outdated mirror of the old SVN repository.
I'd propose to set a webhook that will close all pull requests automatically (with a short informative message) on python/cpython. I'm planning to finish my merge bot this month so I can write a simple webhook quickly if needed.
Sure, that's helpful for the maintainers too. The template saves a potential contributor the embarassment/frustration of opening a PR just to have it closed moments later.
\--Berker
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
On Sun, 10 Jul 2016 at 00:15 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 10 July 2016 at 11:12, Brett Cannon <brett@python.org> wrote:
On Sat, 9 Jul 2016 at 13:01 Carol Willing <willingc@willingconsulting.com> wrote:
Hi Brett,
One thing that could be done is to use a pull request template to notify users BEFORE they make a PR that the CPython mirror is not the correct place to submit contributions.
See https://github.com/python/cpython/pull/41 as an example of the template.
The problem with a template is it has to be checked into the cpython repository which will make sense once we migrate, but I don't know if it does while we are not moved over yet.
I don't see any problem with doing that early - we already carry a .gitignore file for the benefit of folks using hg-git bridges, so if we wanted to start experimenting with GitHub workflows (including things like Travis CI), why gate that on actually doing the migration first if we can use the existing mirrors for it?
OK, then feel free to commit it to hg.python.org/cpython (I doubt it can be committed to the git repo since the mirroring either does a push which will fail do to the difference or it does a `push --force` which will just overwrite the change). I'm personally busy with other stuff right now and this is low-priority for me personally as we get at most two accidental PRs a month ATM so I'm going to pass on putting this ahead of other stuff I need to get done for 3.6 or the devguide (this isn't meant to sound frustrated or anything, BTW).
On Sun, Jul 10, 2016 at 9:33 AM, Brett Cannon <brett@python.org> wrote:
OK, then feel free to commit it to hg.python.org/cpython
Let's try this one. I adopted Carol's patch to here: http://bugs.python.org/issue27476 If someone reviews this, I will go ahead with pushing this and see if this helps. Thanks, Senthil
Senthil pushed Carol's PR template. I just went through and quickly closed all the open PRs w/ the same message saying thanks for the PR, but please use bugs.python.org. On Sun, 10 Jul 2016 at 12:02 Senthil Kumaran <senthil@uthcode.com> wrote:
On Sun, Jul 10, 2016 at 9:33 AM, Brett Cannon <brett@python.org> wrote:
OK, then feel free to commit it to hg.python.org/cpython
Let's try this one. I adopted Carol's patch to here: http://bugs.python.org/issue27476 If someone reviews this, I will go ahead with pushing this and see if this helps.
Thanks, Senthil _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
Thanks Senthil and Brett. \--- Carol Willing Research Software Engineer Project Jupyter @ Cal Poly SLO Director, Python Software Foundation _Signature strengths_ _Empathy - Relator - Ideation - Strategic - Learner_  On Jul 11 2016, at 1:10 pm, Brett Cannon <brett@python.org> wrote:
Senthil pushed Carol's PR template. I just went through and quickly closed all the open PRs w/ the same message saying thanks for the PR, but please use [bugs.python.org](http://bugs.python.org&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn).
On Sun, 10 Jul 2016 at 12:02 Senthil Kumaran <[senthil@uthcode.com](mailto:senthil@uthcode.com)> wrote:
On Sun, Jul 10, 2016 at 9:33 AM, Brett Cannon <[brett@python.org](mailto:brett@python.org)> wrote:
> OK, then feel free to commit it to [hg.python.org/cpython](http://hg.python.org/cpython&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn)
Let's try this one. I adopted Carol's patch to here:
If someone reviews this, I will go ahead with pushing this and see if this helps.
Thanks, Senthil _______________________________________________ core-workflow mailing list [core-workflow@python.org](mailto:core-workflow@python.org) [https://mail.python.org/mailman/listinfo/core- workflow](https://mail.python.org/mailman/listinfo/core- workflow&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn) This list is governed by the PSF Code of Conduct: [https://www.python.org/psf/codeofconduct](https://www.python.org/psf/codeofconduct&r=Y29yZS13b3JrZmxvd0BweXRob24ub3Jn)
participants (8)
-
Berker Peksağ -
Brett Cannon -
Carol Willing -
Matthias Bussonnier -
Nicholas Chammas -
Nick Coghlan -
Oleg Broytman -
Senthil Kumaran